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 <khaledho...@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 <khaledho...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
