Re: [Gnome-print] First draft of new encoding routines



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]