Wed 13 Feb 2019
@MQRY and on-the-fly data retrieval
Mon 11 Feb 2019
Thu 7 Feb 2019
Could working with rich text really be RESTful?
From broken to fixed #1
Sat 16 Sep 2017, 02:24 PMTweet
by Ben Langhinrichs
I wanted to demonstrate what our new Defect Detection (and correction) looks like, but the various examples I have are all covered under NDA. So, in this series, I will break some of my own images in the way the customer images are broken. (These are all scaled down from the original width to make them fit on the blog better.)
Original image (scaled down)
1) Image header lists n segments, but there are only m (where m < n)
For my first example (going in the order of this blog post), I take the same image saved as GIF and JPEG (using GIMP) and imported into Notes rich text, then broken using the Midas LSX. In the GIF format there are two "image segments" in rich text, while In the JPEG format there are six "image segments". This simply means that the raw image data is spread out over a few different CD records. When an image "breaks", it is often because some of the trailing image segments are lost, or rather overwritten. Below, I show the same image, first broken by removing the last few image segments (half of them), then fixed by the Defect Detection system in CoexLinks and AppsFidelity.
As you can see, many "fixed" images aren't perfect, but they are often legible enough to read. If the information on that image is critical, wouldn't you rather see of the those rather than the white box below?
Broken images (all look like this in Notes)
Fixed JPEG image (minus half the image segments)
Fixed non-interlaced GIF (minus half the image segments)
Fixed interlaced GIF (minus half the image segments)
Copyright © 2017 Genii Software Ltd.
What has been said: