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/ _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts