Windows / font / text futures ...

[Chris Sherlock]

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 at 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 at 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