Hi Caolan,

> Anyone still remember what scenario led to the introduction of
> "SortGlyphItems", should it still be there ?

Some algorithms (e.g. GetCharWidths/ApplyDXArray) in sallayout.cxx depend on
the glyph vector being sorted in visual order from left to right.
SortGlyphItems made this sure.

> I ask because I have a scenario with combining characters under glyph
> fallback with Lohit Bengali and some Assamese text where for some font
> sizes/zoom level the combining glyph (which is of 0 width) has an X
> value slightly higher than that of the previous glyph that it combines
> with, and for some other sizes it is of equal value.

Your specific text+font combination it still seems to trigger the problem
first noticed in issue 17624, though the problem from that issue cannot be
reproduced with a recent build (SRC680_m199, which contains the newer
version of the ICU library).

> So depending on the fontsize the combining glyph gets sorted out of its
> correct position and gets bundled with the next glyph. e.g. the glyphs
> are sometimes of positions 24 width foo, 24.0bar width 0, 24 width foo.
> Chopping SortGlyphItems out "fixes the problem"(tm).

Please make sure the problem is still fixed when text justification is
involved and also check the cursor positions.

I guess the problem you saw when glyph fallback was involved was that the
glyph fallback requests from the sorted glyph vector were not in the
original "logical order". The method ImplLayoutArgs::PrepareFallback()
tries to fix this by replaying the original layout request for just the
fallback runs.

> So I'd like to see if there is still a valid example which needs
> SortGlyphItems

Your Assam text with the Lohit-Bengali font would be interesting to me,
because it would by a valid example for the need of SortGlyphItems.

> http://qa.openoffice.org/issues/show_bug.cgi?id=17624 is apparently the
> introduction of it anyway. Though with or without SortGlyphItems my
> rendering of that bugdoc's issue (with font KacstQuran) doesn't seem to
> be right either way with regard to the circled components.

The upper half of the bugdoc looks fine to me, also with KacstQuran. The
lower line with the many differently colored portions is probably a problem
in the Writer engine. It seems to calculate the portion positions wrongly.
Fixing the lower half of the bugdoc is probably not a top priority though,
as the use case for it seems a bit far fetched...

--
Herbert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to