Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 22 Dec 2005 14:34:20 +0100
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: fop-dev@xmlgraphics.apache.org
Subject: Doing changes in the font area
Message-Id: <20051222140018.6FF8.DEV@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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