Re: Bidi reordering engine upgraded

[Thien-Thi Nguyen]

() Eli Zaretskii <address@hidden>
() Fri, 17 Oct 2014 09:16:05 +0300

   > Left-most pixel is numbered 0, and "at 0"
   > refers to that pixel.

   But with that model, a 1-pixel line "at 0"
   does NOT "invade" on pixel 1.

Granted (if i take "1-pixel" to mean the length of
the line, and not its "line width" (a measure
orthogonal to the line's orientation), which is
what i normally understand "1-pixel line" to mean),
but a foo-pixel line "from X to X+W"[0] renders X,
X+1, X+2 ... X+W, for a total count of W+1 pixels.
OBOE!  The invading pixel is not X+1, but X+W.

 | 1         2         3
 | 012345678901234567890123456789
 |           ***********
 |                     ^ out out damned dot!

(11 *s; X = 20, W = 10.)  But anyway...

   decide first what we would like to see as the
   hollow cursor for a glyph that is 1-pixel wide.

Perhaps "hollow" in the vertical sense only could be
expressed as two pixels, one at top, one at bottom.
That's almost invisible, though; maybe two or three
at top and two at bottom is better.

___________________________________
[0] (under X Windows semantics)
    In src/xdisp.c ‘get_phys_cursor_geometry’, the
    comment /* Why? */ alludes to (confusion /
    frustration probably felt due to) the differences
    i mentioned previously.  Probably Someone needs
    to define the "Emacs native coordinate and pixel
    reference system" and add a centrally maintained
    abstraction layer for X, NTGUI, NS, and so on.
    This layer is where X-specific -1/+1 futzing
    should live.  Standard slog...

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

signature.asc
Description: PGP signature