Dia, Pango, Postscript. Argh.

[Cyrille Chepelov <cyrille chepelov org>]

Hello all, 

here's mostly a brain dump as I go through the problem of exporting the now
almost nice i18n'd screen rendering capabilities of dia into Postscript.

I'm looking over libgnomeprint's shoulder with no shame. Actually, I wish it
was called libgtkprint instead.

I noticed this: 
/*
 * These numbers are very loosely adapted from the Univers numbering
 * convention. I've had to insert some to accomodate all the
 * distinctions in the Adobe font catalog.
 * Removed offseting and gaps (Lauris)
 * Multiplied by 100, so it matches with Pango weight (Lauris)
 */
typedef enum {
        GNOME_FONT_LIGHTEST = 100,
[snip]
        GNOME_FONT_REGULAR = 400,
[snip]
        GNOME_FONT_EXTRABLACK = 1100,
        GNOME_FONT_HEAVIEST = 1100
} GnomeFontWeight;

Maybe we should rename DIA_FONT_NORMAL_WEIGHT into DIA_FONT_REGULAR ?

Now, how the hell they do to map from a Pango family/face name into their
Postscript counterpart (I'm not even talking about reencoding):

GFPSObject *
gnome_font_face_pso_new (GnomeFontFace *face, guchar *residentname)
{
        GFPSObject *pso;

[snip]

        if (residentname) pso->residentname = g_strdup (residentname);
        pso->encodedname = g_strdup_printf ("GnomeUni-%s",
face->entry->psname);        pso->bufsize = 0;

[snip]

        return pso;
}

These guys cheat. They don't have the right!

--------

Meanwhile, Matthieu Sozeau pointed me at PAPS,
http://imagic.weizmann.ac.il/~dov/freesw/paps/

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.

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)


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

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

I guess that Win32 printing will be much easier in comparison, probably a
matter of using pango_win32_render_layout on a printing HDC. Bleeh. However,
PS/EPS export for Win32 will either require pangoft2, or require to drill
through the LOGFONT returned by pango_win32_font_logfont() and then extract
the outlines (IIRC, there is some GDI stuff to do that).

Bottom line: there will almost certainly be a need for an 
DiaFontOutlineExtractor, with two implementations (one FT2, one Win32).

        -- Cyrille


Example of one letter:

gsave 71.520000 791.120000 translate 0 0 0 setrgbcolor
start_ol
2432 4288 moveto
2400 4288 lineto
2302 4309 2143 4330 conicto
1985 4352 1864 4352 conicto
1480 4352 1306 4196 conicto
1133 4040 1133 3630 conicto
1133 3520 lineto
2240 3520 lineto
2240 3008 lineto
1152 3008 lineto
1152 0 lineto
576 0 lineto
576 3008 lineto
192 3008 lineto
192 3520 lineto
576 3520 lineto
576 3630 lineto
576 4226 887 4545 conicto
1198 4864 1786 4864 conicto
1983 4864 2141 4846 conicto
2300 4828 2432 4804 conicto
2432 4288 lineto
end_ol grestore 


-- 
Grumpf.