Re: [Gnome-print] First draft of new encoding routines
- From: Lauris Kaplinski <lauris ximian com>
- To: Scott Gifford <sgifford tir com>
- Cc: gnome-print helixcode com
- Subject: Re: [Gnome-print] First draft of new encoding routines
- Date: 15 Jun 2001 02:09:29 +0200
Hello!
Thank you for your work! I'll study it and comment more, if I have
anything to say ;)
Meanwhile, some explanations:
On 14 Jun 2001 04:05:17 -0400, Scott Gifford wrote:
> OK, I have a first draft of some new encoding routines:
> Here's the other comments and notes from the 'gnome-print.notes':
>
> Current Issues:
>
> * Only images are encoded, and only when written to PostScript.
OK. Encoding stream may be interesting, but certainly is not
high priority. And RLE probably does not much there too...
> * Only a RunLengthEncode+ASCII85Encode filter is supported.
>
> * Invalid PostScript LanguageLevel 1 documents are probably produced
> (although it should be straightforward to fix).
We do not support level1 anyways, due to font encoding issues (we have
to support fonts with >= 256 encoding vector) :(
Maybe one day there will be separate driver for level1, but I think at
current stage it is not wort hte effort.
> Comments:
>
> * I don't know enough about the configuration of gnome-print to know
> how to infer what an appropriate set of drivers are. Things I'd
> need to know are:
>
> - Language level supported (1 can only use ASCIIHexEncode,
> 2 supports ASCII85Encode and
> RunLengthEncode,
> 3 supports FlateEncode (not yet
> implemented)
> )
It is hardcoded to Level2 at gnome-1-4-branch.
There will be level specification for HEAD, but I even do not think,
using level3 features matter much at moment.
> - Whether it can handle 8-bit input. GhostScript has no problem
> with 8-bit input, so we're wasting 25% of space by
> ASCII85Encoding binary data.
Well, gnome-print basically just fprintf-s data, so it is completely
format agnostic.
But if switching to 8-bit, you should certainly add a note about
that in DSC headers.
> - Possibly more specific information about what filters are
> supported.
>
> * I've tried to write this library in a way that is easily
> extensible, and that lends itself to external dymanic modules.
> Hopefully those will be implemented someday, by me or by somebody
> else.
>
> * Currently, this library is halfway between a seperate library and
> a part of gnome-print. I could be convinced to go either way ---
> spinning it off into a seperate library that gnome-print can be
> compiled with, or integrating it completely into gnome-print. The
> reason it's somewhat seperate right now is because of the tests
> included, which are quite nice (if I do say so myself), and I'm
> not sure how to incorporate them into the gnome-print build
> process.
Well, having separate library means, that someone has to maintain it,
packagers have to package it etc.
I think it should currently go to gnome-print - but if there is big
enough need for it somewhere else, gnome-print may switch using
separate library at some date. Just keeping it compiled-in saves some
headaches, as long as things are unstable/changing rapidly.
Best wishes,
Lauris Kaplinski
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]