Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Not a criticism, when I was trying to follow the code I was feeling the same way! Your comment was 
very helpful, and I went from frustrated to amused :-)

Chris

Sent from my iPhone

On 8 Mar 2016, at 10:35 AM, Khaled Hosny <khaledhosny@eglug.org> wrote:

On Tue, Mar 08, 2016 at 10:18:47AM +1100, Chris Sherlock wrote:
On 8 Mar 2016, at 5:38 AM, Khaled Hosny <khaledhosny@eglug.org> wrote:

On Mon, Mar 07, 2016 at 02:04:41PM +0000, Michael Meeks wrote:
Hi Thorsten,

   I missed your mail; please do maintain the CC if you want a prompt
reply =)

On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote:

   Hmm; the dx array as I understand it is just a simplified form of glyph
widths;

The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I
have been told), you basically convert individual glyph advance widths
to absolute (from start of line IIRC) “character widths”; the x position
after the Nth character from the start of line, which is not so horrible
so far, except that when drawing the glyphs you take those absolute
character widths and try to convert them back to glyph
positions (that you already had but thrown away, remember) with all
sorts of bugs and rounding errors left and right (and hundreds of hacks
to work around the rounding errors).

I have to agree with this assessment. The comment in the code for ApplyDXArray (I
think was this from you Khaled? I added some info to it) is interesting:

// To justify a text string, Writer calls OutputDevice::GetTextArray()
// to get an array that maps input characters (not glyphs) to their absolute
// position, GetTextArray() in turn calls SalLayout::FillDXArray() to get an
// array of character widths that it converts to absolute positions.

// Writer would then apply justification adjustments to that array of absolute
// character positions and return to OutputDevice, which eventually calls
// ApplyDXArray(), which needs to extract the individual adjustments for each
// character to apply it to corresponding glyphs, and since that information is
// already lost it tries to do some heuristics to guess it again. Those
// heuristics often fail, and have always been a source of all sorts of weird
// text layout bugs, and instead of fixing the broken design a hack after hack
// have been applied on top of it, making it a complete mess that nobody
// understands.

That sounds like a frustrated me.

Regards,
Khaled

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.