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.