Re: Windows / font / text futures ...

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:
> > >   Having looked at this heap; and worse - the two different heaps for
> > > Windows text rendering, and also the big pile of strange cross-platform
> > > issues with stacking diacritics, emojis etc. I'm pretty convinced that
> > > we cannot do a good job of consistent text shaping and/or rendering
> > > cross-platform while using the Windows font rendering infrastructure.
> >  
> > Yeah, I suppose. But that alone won't fix the kind of issues you show
> > in your ascii art
>
>       Sure; the ascii art is the tip of one iceberg ie. not being able to get
> accurate ABC widths and/or metrics for what we're rendering, and hence
> having overlapping glyphs and broken selections in many corner-cases.
>
> >  - as long as so much low-level layouting is still
> > happening in Writer (dx arrays, kashida filling etc).
>
>       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).

Most of time all you need is 1) where to draw the cursor after N
character (VCL has an API specifically for cursor position that is not
used for cursor position) 2) how much the spaces on the line need to
expand for justification 3) where to insert kashidas and how many. All
can be implemented with sane APIs that does not involve throwing
positioning information then second guessing it.

Regards,
Khaled