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

[Vadim Plessky]

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/