Re: Dia, Pango, Postscript. Argh.

[Lars Clausen <lrclause cs uiuc edu>]

On Wed, 26 Jun 2002, Cyrille Chepelov wrote:
> Hello all, 
> At first, it seems it embeds bitmaps into Postscript, and calls it
> "rendering Pango text into Postscript". In fact, it does much better (not
> as good as possible, but much better nonetheless): it uses FT to extract
> the font outlines, and generates one (copy of) outline per instance of
> the glyph.  It makes no attempts to compress or commonalise anything;
> still, the resulting postscript is resolution-independent.

Except that it lose all the hinting that goes into a real font and makes it
readable at small sizes.

> Is it feasible to use the glyph information to build a Postscript out of
> that ? If yes, then I think we can avoid ripping our hair out, here's
> how:
>
>       - We keep the general approach of the current PS-Unicoder
> (pre-render all strings to generate 8-bit encoding tables on the fly).
> However: - we also keep track during the pre-render phase of which glyphs
> of each font are going to be used (using a derivative of the technique of
> the patch "looking_into_layouts.diff" attached here)
>
> Then:
>       - as previously, we generate custom encoding tables (as late as
> possible in the data stream, so that interactive rendering in GhostView and
> friends isn't too horrible)
>       - we also generate custom fonts out of the outlines, using the
> Postscript facilities. These fonts will be peculiar:
>       * they will have funny names
>       * they will have holes (only glyphs actually used will be embedded)
>       * they will have a very strange encoding (or suitable concept)

Why should they have other names than what the original fonts have?
This is basically dumping the font into the file, but only with the glyphs
that we need.

> -- Or -- (lazy man's version): - We don't even keep the pre-rendering
> pass. Each time we encounter a new glyph, we create a path out of that
> (at a constant size, subsequently scaled), assign it an entity name
> /dia12345, and then stroke the glyph at the position indicated by Pango
> (scaling it as needed in the process). We of course remember a table
> associating (glyph,font) to (/dia12345) so we don't redefine the same
> glyph each time.
>
> We don't define a font, because that way we don't need to deal with
> defining ligature and kerning tables and all that crap -- we extract from
> the PangoLayout a bunch of "put this glyph -- by the way, here's the
> definition -- at this position this scale; now put this glyph, same
> scale, at this position; now put ...". We get rid of ps-utf8.[ch] (but
> write something faintly similar in the long run).

It seems to me this solution would create a very strange-looking PS file.
In particular, any program trying to look for the text will find nothing.
And again, the fonts would have their hints and stuff.  Also, optimizing
the file with respect to a set of fonts would be impossible.  It's very
un-postscriptlike, and I don't like it.

> I think I can manage this last approach, borrowing a lot of cod^Wideas
> from PAPS and after reading a lot of Postscript docs on how to save an
> path and reuse it afterwards, scaled. This should also solve the problem
> of "my printer doesn't like my font" (in an accidental way).

What happened to the idea of just dumping the font names and let ps2ps
handle any font insertion?

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?