[Xmlgraphics-fop Wiki] Update of "FontSelectionStrategy" by AndreasDelmelle

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by AndreasDelmelle:
http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy

------------------------------------------------------------------------------
  
  http://jeuclid.sourceforge.net/jeuclid-core/xref/net/sourceforge/jeuclid/elements/support/attributes/MathVariant.html#194
  
+ === Alternative Implementation ===
+ 
+ ==== Rationale ====
+ 
+ Given the above noted dependencies, there seems to be a third alternative: create multiple FOText instances in the FOTree, which would lead to two separate TextLMs being instantiated as a part of FOP's "natural" flow. The different, separate TextLMs will, by design, trigger the correct relative alignment, and maybe solve other of the above mentioned complications of implemententing it in the layout-engine.
+ 
+ The FOTexts' characters are already looped over many times, so it does not really matter ''where'' in the process the check for the presence of a glyph in the current font is inserted. The only thing that would really need to change is the point where the fonts are first loaded: much sooner than is the case with the current implementation, but only from the point of view of a ''single'' FOP run. The argument here is that this matters very little in ''multi-session'' contexts where the fonts are handled by the !FopFactory, and as such already loaded in 90% of the cases.
+ 

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org

Re: [Xmlgraphics-fop Wiki] Update of "FontSelectionStrategy" by AndreasDelmelle

[Andreas L Delmelle <a_...@pandora.be>]

On Jun 30, 2007, at 03:38, Manuel Mall wrote:

Hi Manuel,

> have you considered the case of fo:marker elements where the fonts
> available for selection may not be known at fo tree construction time?

Good that you point it out now, since I indeed did not explicitly  
consider markers yet.

OTOH, I don't immediately see it as a blocker, since a great deal of  
what is done for FOs during the tree construction, is in fact  
deferred for markers until they are retrieved, exactly because of the  
fact that inherited property values are not known, and markers could  
be retrieved multiple times in different contexts.

For marker-descendants, this extra treatment of the text/characters  
can be folded into the marker-cloning instead of performing it on the  
original FOs. Just like property resolution and whitespace-handling  
are skipped for the marker-descendants when they are performed for  
all other FOs.


Cheers,

Andreas

Re: [Xmlgraphics-fop Wiki] Update of "FontSelectionStrategy" by AndreasDelmelle

[Manuel Mall <mm...@arcus.com.au>]

On Saturday 30 June 2007 03:00, Apache Wiki wrote:
> + === Alternative Implementation ===
> +
> + ==== Rationale ====
> +
> + Given the above noted dependencies, there seems to be a third
> alternative: create multiple FOText instances in the FOTree, which
> would lead to two separate TextLMs being instantiated as a part of
> FOP's "natural" flow. The different, separate TextLMs will, by
> design, trigger the correct relative alignment, and maybe solve other
> of the above mentioned complications of implemententing it in the
> layout-engine. +

Andreas,

have you considered the case of fo:marker elements where the fonts 
available for selection may not be known at fo tree construction time? 
IIRC we have been 'bitten' before by doing things during the fo tree 
construction phase only to find out later that it is broken when it 
comes to markers. May be its not an issue here as I haven't thought 
this through in detail.

Cheers

Manuel