On May 13, 2008, at 07:32, Max Berger wrote:
Hi Max
<snip />
+ private Font selectFontForCharacter(Character fobj) {
Now that we have a FontManager, what if we add something to it like:
public Font selectFontForCharacter(FontTriplet[] triplets, char, int)
+1, what would be the int be for?
I just noticed that the font-size is being passed somewhere, but
maybe FontManager does not need it at all. (? to be verified...)
That way the loop in question finally moves to where I think it
actually belongs... and a similar approach could then be applied
to the TextLayoutManager. As an initial step, we could already
make sure that the selected font is always one that can display
the first character.
I don't like a "partial" implementation (the first character version)
All the better ;-)
For the textlayoutmanager: I saw that similar functionality in
there multiple times, for paragraphs, page-references, etc. They
all seem to create the same result, just based on content
(paragraph) or context (page-references). So the first step here
would be to refactor the common functionality out as well.
Now the real question is about the possible font selection
stragety. We'd have to implement "auto" and "characte-by-character"
they are defined as follow:
auto: is vendor-specific, but should use a "broader context"
char-by-char: select first font-match for evey character.
First the question is about line metrics: In a paragraph, we could use
- the line metrics for the font of the first char for the whole
paragraph -> easiest implementation, but the result may look bad
- the line metrics of all fonts used in a line (I have no idea how
that would work) -> best result
- the line metrics maximia for all fonts used in a paragraph
(medium to implement, medium result)
The second would, of course, be the better option. I'm hoping Manuel
chimes in later, as he has already been looking at this, and may have
some ideas to share.
As far as I remember from earlier discussions, the trickiest part
will be to keep track of changes in the alignment context as the font
changes. If we can manage that, the line-layout algorithm should
automatically take care of the rest.
the next question is: what is auto-selection strategy?
would it be:
- select font based on the first character? now that i think about
it, I really like it - it would be really fast, and produce a
correct result IF the symbols are enclosed in their own fo:block
- select a font that can display the whole paragraph (if possible)
- switch for every word? This would probably give good results, but
may not make so much difference to char-by-char.
- make it the same as character-by-character? This would possibly
be slower, and produce some overhead, so its a bad idea for
"default" behavior.
Auto-selection would, as mentioned, use a 'broader context'. The
difference is that, with "character-by-character", each character in
a word could be put in a different font (the first of the specified
families that has a glyph for it). With "auto" we could do something
clever like try to determine whether there is a font-family that can
display whole words (or entire paragraphs), which may lead to much
nicer-looking results (less font-switching -> better overall
alignment). If the first font-family only has a glyph for 2 out of 5
characters in a word, but the second has matching glyphs for all 5,
with a value of "auto" we could decide to use the second.
That said, getting "character-by-character" to work correctly would
already be vast improvement over the current situation, where we
don't look at the characters at all, and just use the first specified
font.
Cheers
Andreas
