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

[David Turner]

Hi Vadim,

Vadim Plessky a écrit :
> 
> 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.

OK, first, I'm planning to work on this since I've made much design but
written very little source for now (and the upcoming 2.0.6 FreeType
release is currently taking most of my time)..


My plan is/was to develop two distinct components:

  - a "unified font & type service for Unix", named "UniType" which
    has been more or less already described in Render mailing list.

    It's purpose is to provide capabilities that are either not
    possible or not implemented yet in something like libXft:

      - identify each installed/available "face" with a _unique_
        and _persistent_ 128-bit signature. Each "face id" is
        independent of the locations and file names used/installed
        in the system but matches exact version of the files
        (and attachments, like *.pfa+*.afm). Sort of MD5 hashes
        in a more sophisticated way..

      - provide an simple but efficient database implementation to
        associate custom keyed data to each "Face ID". This will
        be used by UniType itself, but also available directly to
        applications if they need to build their own "font catalog"

        of course, you're free to use your own DB if you need it..


    this "persistent storage" is the biggest feature in UniType, on
    top of that, many things can be built relatively easily:

      - storage of important font meta-data to avoid re-computing it
        each time one opens a face in FreeType (for example). Like:

          * languages _really_ supported by the face (answering this
            question is hard !!)

          * efficient charmaps that are automatically synthetized
            from the ones included in font files (for Type 1 fonts
            for example)

          * list of X11 encodings supported by each face (for
            backwards compatibility)

          * "embedded" versions of some fonts, to avoid re-generating
            them each time..

      - management of system + user + application font list (through
        pattern matching similar to libXft, or even _directly_ through
        libXft)

      - automatically synthetized OpenType tables for certain faces
        (like GPOS tables to handle the kerning information found in
         Type 1 afm files in a more efficient way). One could also
        imagine being able to automatically create OpenType tables
        for certain 

      - "embedded" versions of fonts, ready to be sub-setted for Postscript
        or PFT printing, for example..


    another feature is the fact that UniType will not require applications
    to use FreeType (even if it will use it, and allow you to convert a
    "Face ID" into an input stream). This in order to be able to migrate
    to FreeType 3 when it comes out (in a _long_ future), or simply another
    font engine..

    (that's a big difference with libXft that insists that you use FT2 for
     now).


then:

  - A text layout engine, based on UniType, supporting all kinds of
    sophisticated features (including OpenType, we haven't really touched
    GX for the lack of fonts to test and interest we ourselves have in the
    technology).

    One of its biggest features is to provide an API similar to ATSUI,
    which uses "styles" instead of "font" attributes. This is actually the
    only way to properly deal with very subtle but sophisticated typographic
    processes without forcing the client application to know too much about
    font technology. The API looks like:

       - provide an array of 32-bit Unicode character codes (not UTF-16),
         called "text"

       - create one or more "style" objects and set their properties to
         features you need

       - "apply" styles to text runs (i.e. intervals to the "text" array)

    this is useful for several reasons, among which:

      - displaying internationalised text using several fonts for each
        script available. If you don't want to force the application to
        manually change the "font" attribute based on text's language
        fragments, you need to provide a "virtual font" capability (i.e.
        one logical font that embeds several different faces depending
        on scripts/languages).

        the problem with "virtual fonts" is that they're not really fonts,
        which makes your API somewhat limited (you cannot provide reliable
        metrics, OpenType tables, names, etc.. for them).


      - ever tried to display the "euro" sign correctly, when using a font
        that doesn't include its glyph ? The best way to do it is find a
        similarly-sized _and_ similarly-styled font that contain it and
        use that during text rendering. You generally don't want your
        applications to do that, so it's best left to the style object.


      - style objects allow you to implement many features (language 
substitution,
        style matching, opentype layout, etc.. ) of very different nature with a
        uniform API, this can strongly reduce the bloat as well as simplify


    and there are countless other details that I won't give here regarding
    wysiwyg rendering and printing, caching, etc..


Of course, since we're all doing it for fun and in our free time at FreeType, 
don't
expect this to come very early.. (don't hesitate to contact me if you wish to 
sponsor
such effort though ;-)


Regarding ST, I have been rather pleased by Sun's announcement, even if I'll 
keep
being skeptical until we see the source code and more importantly the _real_ 
license.
The description doesn't give a lot of details regarding the API or internals, 
but
I'm rather pleased to see it because I think that the association of ATSUI and 
Java2D
is probably going to be a _very_ good thing to use..

(this would also mean that we wouldn't need to write the code to implement 
everything
 described above..)


I didn't find that Brian Stell was harsh in any way.. Announcements are great
things, but Sun has a history of disappointing the Open Source community. I'm
pretty certain that the ST team is good-hearted and talented, I simply fear
Sun's management and the SCSL :o)

But if it really comes with a BSD/X-styled license and has all the features I
envision, this is going to be a _giant_ leap for Open Source and X in general,
and I don't think there should be any good reason to avoid it.. !!

I'm now waiting to see more before making a decision on ST, as anyone else..
In the meantime, I'll continue slowly what I've planned..

Regards,

- David




> [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/