[Devel] Fwd: Re: [Fonts]Another approach to text in X

[Vadim Plessky]

resend, with limited number of addresses :-)
(and special thanks to David Turner for his answer of XFree86 Fonts ML!)

----------  Forwarded Message  ----------

Subject: Re: [Fonts]Another approach to text in X
Date: Sat, 22 Dec 2001 14:26:04 +0000
From: Vadim Plessky <address@hidden>
To: address@hidden, Sergey Babkin <address@hidden>, FT-devel 
<address@hidden>, David Turner <address@hidden>, David Faure 
<address@hidden>
Cc: address@hidden, address@hidden, address@hidden, 
address@hidden, address@hidden, address@hidden, 
address@hidden, address@hidden

On Friday 21 December 2001 01:41, Sergey Babkin wrote:
|   Alexander Gelfenbain wrote:
|   > On Wed, Dec 19, 2001 at 07:20:45PM -0500, Sergey Babkin wrote:
|   > > Alan Coopersmith wrote:
|   > > > applications.  We have designed a display and platform-independent
|   > > > text architecture, the Standard Type Services (ST) framework, which
|   > > > handles not just font rendering, but text layout and font
|   > > > management as well. ST incorporates typographically sophisticated
|   > > > features and ideas from the best regarded existing APIs, including
|   > > > Apple Type Services for Unicode Imaging (ATSUI) and Java2D
|   > > > TextLayouts.  On top of ST, we have layered a new extension to the
|   > > > X protocol, called XST, which incorporates the ST functionality.
|   > > > The ST API will also be exposed to applications independant of the
|   > > > X environment so that it can be used
|   > >
|   > > It would be good if it also could provide the output in PostScript.
|   >
|   > It would be capable of generating outlines. Converting them to
|   > PostScript is trivial.
|
|   I think, not quite trivial. I guess I should first explain that
|   I don't want to sound ungrateful, and the way it is now this
|   architecture looks very interesting and useful. Just it seems to me
|   that it's a great opportunity to fix the historical X's weakness
|   with printing. And seeing it missed once again would be a pity.
|
|   Basically, rendering the general graphics in PostScript is easy
|   and does not require much effort. Rendering of the text is much
|   harder. The major thing making it complicated is the fonts. Of
|   course, transferring the outlines of a rendered page back is a
|   possible thing but it means large size of the resulting file and
|   slow rendering to bitmaps at the printer. Providing a way to convert
|   the used fonts to PostScript fonts, transferring them to the client
|   and then rendering the pages in terms of these fonts looks like a much
|   better thing. And probably provide a protocol to get the kerning
|   information on to the client (unless all the rendering including
|   kerning is done at the server side).
|
|   Such a conversion is "trivial" too in the sense that it's clear
|   how it can be done, the only difficulty is to actually do it
|   and to provide an X protocol extension for such a transfer:

Hello All,

I believe David Turner was working on similar project, or at least was
planning to do this. He was planning to do both basic-text-layout engine
(built on top of FT) and font-conversion module, IIRC.
[hope, David can clarify this]
Most Linux projects use FreeType or technologies "derivied" from FreeType for
font rendering. So it seems quire reasonable to me if we can listen to
opinion of FreeType developers too, as well as developers of front-end,
end-user products (KWord/KDE, in particular)

"Providing a way to convert the used fonts to PostScript fonts" is indeed a
quite important issue.
I was discussing this (already some time ago) with guys from TrollTech
(developers of QT) and KDE developers.
At a moment, when you print from KDE application, data flow is coming in
following way:
KDE -> QT -> PostScript
PostScript is later either converted to PDF (using ps2pdf from GhostScript)
or printed/rasterized via Ghostscript (and its printer drivers)
Font conversion (TrueType -> PostScript) is happening in Qt library.
Latest release of Qt, Qt3, allows either Font Embedding (via font conversion
of TTF fonts or "direct embedding" of PS T1 fonts) or generating PS/PDf "as
is", without any fonts embedded (it's configurable).

Project Alan Coopersmith was speaking about [Standard Type Services (ST)] is
indeed looks quite interesting.
But I am pretty much interested *how* it can be integrated into existing
Linux/UNIX applications.
Alan, do you cooperate in some way with TrollTech to ensure support for ST in
QT library?
I think this is somewhat critical for success of your project.
I don't know wether your project, ST, overlap in some way with QT layouting
capabilities or not. If QT is supported, that most KDE applications will be
able to benefit form this immediately, at no extra cost (just as after RENDER
extension introduction around 1 year ago)

Another quite important question is support for SVG.
You have mentioned that:
" It would be capable of generating outlines. Converting them to
PostScript is trivial."
Does it mean that converting outlines to SVG would also be trivial?
Do you have that module already working?

There is a (unconfirmed) opinion circulating around (off-list, of course...)
that Adobe is going to scratch PostScript in favour of SVG somewhere in
nearest future. Even if it's not the case, PDF is definitly getting higher
priority in Adobe than PostScript, so I would say generating PDF, but not
PostScript, from vector objects should be top prioroty for all projects
related to layouting.
So, what is the position of your project in relation to SVG and PDF?
As you are employed by Sun (and Sun support Batik), do you work, to some
extent, together with Sun's Batik team?

And, last question: how do you want to solve printing issues?
As soon as you got vector drawing (either "drawing" with curves, lines, etc.
or "scaled text" in forms of outlines; it can be either PostScript/PDF or
SVG), you need to make rasterization of this drawing into pixmap.
There are several very important issues come here to mind.
 a) font hinting
 yes, font formats are interchangable, you can convert 2nd order splines to
3rd orfder splines and back (with some losses, but it works), but what about
hints?
Even for 300dpi printer (and for all devices with lower resolution) you need
to apply hinting for rasterized pixmap.
 For screen rendering (of fonts/glyphs), FreeType doing this job together
with X RENDER extension.
 What you suppose to do with this in your module? Will it rely on FreeType
for this task?
 b) anti-aliasing
anti-aliasing (of glyphs) works fine (again, with help of RENDER extension)
in XFree86. Still it doesn't happen with regular vector drawings (at least I
am not aware of this).
Do you have solution for this?

It's interesting that I have recently discussion with several people
concerning libraries suitable to build SVG support on (with anti-aliasing,
fonts scaling, etc.)
Do you have some own library for this task, or rely on some 3rd-party
 library? I have checked and found that Adobe uses [in their Adobe SVG 3.0
 plugin] own cross-platform graphics library. Most likely, it's used not only
 in SVG plugin but in Adobe Illustrator, Pagemaker, and other programs which
 require either PostScriupt or SVG rendering.
I would highly appreciate your comments on this (as you, probably, already
studied these issues internally)

I have to admit here that my questions are not "theoretical" at all.
KWord reached "maturity" level, and more and more users use it for PDF
generation, daily wordprocessing, etc.
On the other hand, Kontour (previously known as KIllustrator, renamed after
Adobe lawsuit) will reach maturity soon.
As it [as part of KOffice] becomes complete desktop replacement for MS Office
products, user's expectations rise as well.
Therefor it's quite important to learn on Microsoft (and others') mistakes
and apply *right* solution in *right* place.
Typical user of word processor expects good layouting of text and graphics,
and excellent printing quality.
Web Designers (and Document Publishers) expect easy web publishing, SVG,
XML+CSS, and PDF seems as quite reasonable formats for those tasks (while
serving different auditories)
As you can see, all of those tasks require flexible (and extensible)
mechanism for font conversions, vector graphics conversion, font embedding,
etc.
Therefor, I am very interested to hear your comments :-)

And Merry Christmas for everybody!

|   - the Type1 fonts can be transferred directly, only with the encoding
|   table changed according to X the server's idea about it and with
|   the large fonts split into multiple 8-bit fonts (and/or possibly
|   then combined into a Type0 composite font)
|
|   - the TrueType fonts can be either converted to Type42 with the
|   algorithm taken from ttf2type42 or converted to Type1 with the
|   algorithm taken from ttf2pt1
|
|   - the other fonts can be rasterized to bitmaps and then converted
|   to the Type1 fonts with the algorithm taken from ttf2pt1
|
|   Actually, one more possibility is to take the outlines produced
|   from any kind of font and feed them into the algorithm from ttf2pt1.

Agreed. ttf2pt1 does very good job of font conversion, and it uses FT2 (when
available) for font format decoding. So, it's quite natural to integrate this
with future font-conversion-module, which I suppose should be built with
FreeType in mind.

|   Basically, what I'm trying to say is that since yet another extension
|   is being added to the X protocol, it would be nice to include this
|   font transfer ability into it.

yes, Sergey, we need to do that.
Otherwise we will again have set of different, incompatible
implementations... :-(

|   -SB

--

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

-------------------------------------------------------

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/