Re: Dia, Pango, Postscript. Argh.

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

      - 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)

      - 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 Clausen (| 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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]