Windows / font / text futures ...

Chris Sherlock chris.sherlock79 at gmail.com
Mon Mar 7 23:18:47 UTC 2016


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.

http://opengrok.libreoffice.org/xref/core/vcl/source/gdi/sallayout.cxx#901 

Regardless of who wrote that comment, this is pretty insane. 


Chris


More information about the LibreOffice mailing list