[Coco] Pdf on coco3
matju at artengine.ca
Wed Mar 22 22:20:13 EDT 2017
A random page from a Rainbow pdf, saved to PNG gives a 797x1089 file in RGBA,
which would take 3390k of RAM if uncompressed the ordinary way, and then it
would have to be copied to video RAM. Using 256-color GIF would unpack to 848k
instead, and using 16-colour GIF would unpack to 424k. There are various tricks
to make it smaller, but IMHO the biggest problem is how annoying it is to read
from a picture larger than the screen, because if it is not zoomed out it won't
be practical to use. At the same time, rescaling is a good way to cut a lot more
bytes, but care must be taken not to make too much text unreadable. It can't fit
in 320 for sure. And then, if your mode has 640 pixels wide (0.8 scale factor =
0.64 times 424k = 272k), it doesn't work in 16 colours, therefore 4-colour GIF
(halve the RAM again, 136k). But then, the pixels' aspect ratio wouldn't be
close to 1, therefore even more rows of pixels would have to be deleted, and I
think it would lose too much readability (even more so if the version targetting
the Coco has to be prepared from the non-antialiased 797x1089 instead of from a
higher-res version...). So it would be an incentive to choose a bad aspect ratio
just for the sake of having the whole width of the page at the same time as
enough vertical res to make it readable. ;-) I'm supposing that vertical
scrolling is not an issue, too.
But the killer is really the fact that if the user has only one CoCo, this has
to be multitasked with whatever the user is trying to read about in Rainbow, and
that thing is rarely multitaskable (nevermind the amount of RAM). This also
holds if one has both a Coco2 and a Coco3 but would need to run a Coco3 app
while viewing Rainbow GIFs on another Coco3... argh.
Le 2017-03-22 à 12:27:00, Aaron Wolfe a écrit :
> It can be easy to forget the massive differences in scale between our
> beloved coco and modern computers in some areas, especially when in
> other areas it seems we haven't gained much ground. But when you're
> talking about "viewing a PDF", especially a scanned PDF of a magazine
> like the Rainbow scans, you're talking about processing literally
> hundreds or thousands of times more bytes than can fit in the address
> space of the 6809 and then displaying it at a resolution and color
> depth that is a fraction of the displays the PDF format targets. I do
> get the nostalgia/wow factor, but even an amazingly well executed
> general purpose pdf viewer seems unlikely to be pleasant to use.
> On the other hand, as Mathieu mentioned, there is a set of the Rainbow
> and other coco magazines that contain ASCII text (OCRed). Exporting
> that to regular old text files would provide a way to read and search
> the articles on a Coco using existing, mature tools.
> I think it was Tim Lindner that had a really cool community project to
> do OCR plus human checking on Rainbow articles. The results of that
> project might be usable on a Coco as well. I'm sorry I can't find the
> link, not sure if they are available.
> Modern PDF processing just comes down to a relatively massive amount
> of work for the coco, but there are still some really interesting
> modern sources of information that the coco could process very well.
> A lot of web services offer JSON or similar based APIs that would be
> easy to process on the coco even in a higher level language like
> BASIC09. News and discussion sites like Reddit are primarily text
> based, I could imagine a very functional reddit client actually.
> There is also the whole Internet of Things world where everything is
> sending small amounts of data at relatively slow speeds. An MQTT
> client for the coco would open the door to all kinds of interesting
> things that fit nicely into the coco's capabilities.
> On Wed, Mar 22, 2017 at 11:26 AM, Mathieu Bouchard <matju at artengine.ca> wrote:
>> Sorry... but actually, scanned pdf files such as those of the Rainbow magazine are a special case, they're just sets of full-page JPEG files plus page numbering (some scanned pdfs also contain the ASCII version using optical recognition, but that's invisible until you select some text). A viewer for just the images could limit itself to displaying the JPEG files that are in a PDF container. The issues with displaying those files are pretty different from those with displaying vector graphics and fonts, though in the end it's all about pixel sizes, aliasing and stuff.
>> The easiest solution for you could be to auto-export each page of a magazine to JPEG format and try to read that on the Coco, if there is a JPEG viewer. But quantizing it and encoding as GIF might be more efficient for Coco.
> Coco mailing list
> Coco at maltedmedia.com
| Mathieu BOUCHARD --- tél: 514.623.3801, 514.383.3801 --- Montréal, QC
More information about the Coco