Re: Re[2]: How to export text to EPS as text (no curves)?

[Cyrille Chepelov <cyrille chepelov org>]

Le Sun, Sep 07, 2003, à 11:48:38AM -0400, Alan G Isaac a écrit:
> On Sun, 07 Sep 2003 08:12:26 -0500 Lars Clausen <lrclause@cs.uiuc.edu> wrote:
> > The problem is that we don't have a text export that preserves the size of
> > the strings, or we'd use that.  If we used regular (E)PS text, strings
> > would overflow their boxes or leave big gaps.
> 
> I do not understand this claim.  PostScript text is entirely
> scalable.  If you can fit a box once, you can fit it at any
> scale.  Or are you saying you have no mechanism for
> computing the width or height of PostScript strings, so you
> cannot even fit a box once?  This is a very standard problem
> and there should be many applicable solutions on hand.
> (I realize I probably just do not understand the problem
> you intend to describe.)

I'm sorry, but I couldn't resist: the contents of your parenthesis block is 
totally obvious.

Indeed, the problem of measuring text is a frequently occurent one, but 
as of now there is no Free, Debian-legal-proof solution to do it while
also respecting I18N requirements and without embedding a complete PS
rasteriser engine right inside dia (let's call this the executive
summary).
If the problem was easy, I guess Netscape 4.X would have good printing;
to date, I'm not yet satisfied with Mozilla Firebird's printing. Only
Apple and Microsoft come close to providing decent printing.

The problem with scaling fonts is that it's not linear. You can't guess
the width of a 18pt text based on the same text's width at 12pt, and at
the same nominal size, you can't guess the width of a text rendered on a
600dpi device based on a 75dpi device's output (because hinting et al.
are all poking fun at us).

The problem is, if you just give a text string to Postscript, sure it
will be very nicely hinted, sure you can also query the interpreter for
the width of that text and exploit that knowledge later in the same .ps
document to position other graphic elements, but you have no way of
extracting that text width and bringing back from the PS interpreter to
the dia rendering code (because the interpreter is not running
synchronously with the rendering code, if it runs on the same CPU at
all). And we routinely need to measure text strings so that the overall
diagram is not ugly.

Another problem with Postscript is that it does not really understand
Unicode, and is totally unable to reconstruct a reasonable complete font out
of a set of broken or partial fonts (it can indeed be told to build a
synthetic font out of several of the interpreter's fonts' individual
glyphs, but it will not do it on its own, it requires help from e.g.
Pango).

For some people, pure US-ASCII is an option, but for the general market
of well-behaving gtk/GNOME applications, it is not. Even sticking to
latin1 is not. Even in a latin9 context, font reconstruction is
routinely done by Pango (to supply a certain monetary symbol to
latin1-only fonts). And good gtk/GNOME citizens mustn't be restricted to
latin1/latin9 either.

At this point, with the current technologies legally at our hands, we
can either have font reconstruction with decent BMP-1 Unicode support OR 
superb hinting done at the PS rasterised stage, and we can't have superb 
hinting in the rasteriser AND accurate measurement of the text blocks' width.

>From the point of view of rendering text, there are three levels in
dia's rendering:
	* the glyph level (where the shape of individual glyphs is important)
	* the string level (where the placement and perhaps subtle sizing 
			  of glyphs relative to its neighbours is important)
	* the diagram level (where the placement and not-so-subtle
				sizing of strings relative to every 
				neighbouring graphic element (strings, lines, 
				etc.)

dia 0.88.1 had perfect string-level rendering (because we delegated to
the Postscript engine, which typically had close scrutinity from
typography experts), a glyph-level rendering which varied from perfect
(English-speaking world) to unusable (the user who wanted to use more
than one non-English language in a single diagram) with various
intermediate levels (latin1 was okay, latin2 often required warts like
ogonkify, Japanese had a good boost Akira TAGOH, but forget about Hindic
scripts, etc.).
The diagram level rendering sucked, as it was basically a lottery
whether you text would be properly aligned with respect to graphic
elements, leave unwanted gaps, or overflow.

When we went to gtk2.0, we needed to improve the glyph level (because
GNOME cares for I18N/L10N/W6R), and sure the diagram-level was itching.

The temporary compromise we did was to sacrifice the string level to
improve the two others. Yes, that's at the expense of typography and
Postscript types, but at least the product starts to be barely usable
for non-Western users.

The real solution would be for either Pango or a complementary
library to be able to execute the hinting stuff at the rendering stage,
and predictably, accurately match what the rasteriser will choose to do, in a 
dependable way (short of mandating that every raster device has a
resolution of exactly 9600dpi, including paper and screen, I don't see
how to do this, but there are a lot of smarter people than I).
With that, we'll be able to take the Pango-or-complementary library's
word for what the width of a given text string is, and assume the
Postscript rasteriser will agree and output a string of "exactly" the same
width, modulo what the human eye is actually able to see.

(Of course, this assumes that said library has access to the same font
outlines and hints as the rasteriser, which is relatively easy if you
decide the fonts are to be downloaded, but requires a certain amount of
faith if you really insist on sending Postscript files over a 1200 bit/s
RS-232 line -- or have a million embedded EPS files in a LaTeX document,
been there, done that).

This "magic library" I just described is clearly out of dia's
responsibility. There are several attempts to do that, PangoPS/PangoPDF
is one, GNOME-Print is another (but I really don't think you like G-P's
text output). I'd think anything GPL-compatible and legally kosher will
do the job if it doesn't bring a boatload of new dependencies. If it's
done to become a standard library (an official Pango component would fit
the role wonderfully), this would be perfect.

 -- Cyrille 

--