Doing changes in the font area

[Jeremias Maerki <de...@jeremias-maerki.ch>]

I feel bad about the font story, especially since Vincent put so much
work into something that I first supported and now had to recommend to
put off. Even worse, I now have to do some changes in the font area
which will certainly create merge conflicts on his working copy. Here's
what I plan to do:

Currently the area tree saves the internal font key (F1, F2, F3 etc.) as
the FONT_NAME trait. This key maps directly to the font that was chosen
during the font lookup. One such F-key can map to several font-triplets
(ex. "Helvetica,oblique,600"). All is fine as long as the area tree is
used as it is now: just a temporary data structure until the renderers
convert it into the target format. Even if single pages are off-loaded
to temporary files by the CachedRenderPagesModel, everything still
happens in one rendering run.

Now, when the intermediate format comes into play, the whole thing gets
a little more complicated. Assume that during the day a company
renderers several documents to the intermediate format and stores them
in a buffer. In the night, all the pending documents are gathered
together by a batch process and a PostScript print stream is generated
from all the documents created during the day. In the morning the print
departments prints all the documents of the previous day. Now, imagine
that one evening the IT people add a new font to the font configuration
and restart the server. The F-keys might not point to the same font as
before anymore. Maybe a special scenario but it shows that this approach
is not stable enough for the intermediate format. It seems much more
stable to store the font triplet in the area tree instead of the F-key.
Directly storing the original font specification would not be such a
good idea because there's font subsitution in the middle and the layout
is done after the font subsitution. It would be bad to rely on the font
substitution to be stable.

A lot of words to describe a relatively simple change I plan to do: I
want to define a simple (Serializable) FontKey class that replaces the
mere String that is built by FontInfo.createFontKey(). FontKey will
contain the same three values as the String. The FontKey class will be
used instead of the String for the FONT_NAME trait (which I'll rename to
"FONT" trait). The requirement for any trait is to be serializable,
something, BTW, that the FontUse object from aXSL isn't. In Vincent's
patch the FontUse object is stored in the FONT_NAME trait instead of the
internal F-key. That is not to make Vincent's patch bad. He probably
couldn't know. This is simply an aspect we neglected a little lately
(see the references on the FO tree I removed, for example).

BTW, I successfully rendered a document using the CachedRenderPagesModel
today where unresolved pages were off-loaded to disk until they were
ready to be resolved and rendered. A little step in the direction of
handling bigger documents as a side-product of my current work.

Jeremias Maerki

Re: Doing changes in the font area

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Oh, we already have that class I was talking about: It's FontTriplet. It
just needs to be used more. :-)

On 22.12.2005 14:34:20 Jeremias Maerki wrote:
> I feel bad about the font story, especially since Vincent put so much
> work into something that I first supported and now had to recommend to
> put off. Even worse, I now have to do some changes in the font area
> which will certainly create merge conflicts on his working copy. Here's
> what I plan to do:
> 
> Currently the area tree saves the internal font key (F1, F2, F3 etc.) as
> the FONT_NAME trait. This key maps directly to the font that was chosen
> during the font lookup. One such F-key can map to several font-triplets
> (ex. "Helvetica,oblique,600"). All is fine as long as the area tree is
> used as it is now: just a temporary data structure until the renderers
> convert it into the target format. Even if single pages are off-loaded
> to temporary files by the CachedRenderPagesModel, everything still
> happens in one rendering run.
> 
> Now, when the intermediate format comes into play, the whole thing gets
> a little more complicated. Assume that during the day a company
> renderers several documents to the intermediate format and stores them
> in a buffer. In the night, all the pending documents are gathered
> together by a batch process and a PostScript print stream is generated
> from all the documents created during the day. In the morning the print
> departments prints all the documents of the previous day. Now, imagine
> that one evening the IT people add a new font to the font configuration
> and restart the server. The F-keys might not point to the same font as
> before anymore. Maybe a special scenario but it shows that this approach
> is not stable enough for the intermediate format. It seems much more
> stable to store the font triplet in the area tree instead of the F-key.
> Directly storing the original font specification would not be such a
> good idea because there's font subsitution in the middle and the layout
> is done after the font subsitution. It would be bad to rely on the font
> substitution to be stable.
> 
> A lot of words to describe a relatively simple change I plan to do: I
> want to define a simple (Serializable) FontKey class that replaces the
> mere String that is built by FontInfo.createFontKey(). FontKey will
> contain the same three values as the String. The FontKey class will be
> used instead of the String for the FONT_NAME trait (which I'll rename to
> "FONT" trait). The requirement for any trait is to be serializable,
> something, BTW, that the FontUse object from aXSL isn't. In Vincent's
> patch the FontUse object is stored in the FONT_NAME trait instead of the
> internal F-key. That is not to make Vincent's patch bad. He probably
> couldn't know. This is simply an aspect we neglected a little lately
> (see the references on the FO tree I removed, for example).
> 
> BTW, I successfully rendered a document using the CachedRenderPagesModel
> today where unresolved pages were off-loaded to disk until they were
> ready to be resolved and rendered. A little step in the direction of
> handling bigger documents as a side-product of my current work.
> 
> Jeremias Maerki



Jeremias Maerki