Windows / font / text futures ...

Khaled Hosny khaledhosny at eglug.org
Mon Mar 7 23:35:33 UTC 2016


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


More information about the LibreOffice mailing list