[bug #57524] gpinyin: bad rendering for "ü" and "Ü" with tone marks

[G. Branden Robinson]

Update of bug #57524 (project groff):

                  Status:                    None => In Progress            
             Assigned to:                    None => gbranden               
                 Summary: gpinyin: suboptimal rendering for syllable "lue3" =>
gpinyin: bad rendering for "ü" and "Ü" with tone marks

    _______________________________________________________

Follow-up Comment #2:

Generalized summary.  The problem isn't with any specific syllable, but for
the u-with-dieresis vowel in general.

Further, the problem with the capital U-with-dieresis is worse than
suboptimal--a flat-wrong base glyph is rendered, and even if you correct that
the tone mark and dieresis collide to the point of unreadability.

The good news?

Typographically, I have a solution.  An example document is below.  I used
gpinyin to generate it (after applying the patch in comment #1) and then
hand-tuned it.  Blissfully, a pretty straightforward technique of using
vertical motions to place the tone marks worked fine.  The vertical motions
are different for uppercase and lowercase base glyphs, however. 
Serendipitously, one is half of the other.

A complication arose: groff doesn't allow us to nest a \v vertical motion
escape inside a \o overstriking sequence escape.[1]


troff: <standard input>:16: error: normal or special character expected (got a
node)


However, groff _does_ let us cheat: by defining our own special characters
that embed vertical motions, we can sneak them in anyway.

So that's what I did.  As can be seen, the character definitions are highly
schematic.  I reckon the fix here is to make gpinyin inject these .char
definitions into the troff mode branch of its output, use them where
necessary, and subsequently delete them with .rchar.

Here's the input document.  I'm attaching a screenshot as well.


.ta T 1i
.char \[a-_uc] \v'-0.3v'\[a-]\v'+0.3v'
.char \[a-_lc] \v'-0.15v'\[a-]\v'+0.15v'
.char \[aa_uc] \v'-0.3v'\[aa]\v'+0.3v'
.char \[aa_lc] \v'-0.15v'\[aa]\v'+0.15v'
.char \[ah_uc] \v'-0.3v'\[ah]\v'+0.3v'
.char \[ah_lc] \v'-0.15v'\[ah]\v'+0.15v'
.char \[ga_uc] \v'-0.3v'\[ga]\v'+0.3v'
.char \[ga_lc] \v'-0.15v'\[ga]\v'+0.15v'
GBR     BW
.br
L\o'\[:U]\[a-_uc]' l\o'\[:u]\[a-_lc]'   L\o'\s-2\[:U]\s0\[a-]'
l\o'\s-2\[:u]\s0\[a-]'
.br
L\o'\[:U]\[aa_uc]' l\o'\[:u]\[aa_lc]'   L\o'\s-2\[:U]\s0\[aa]'
l\o'\s-2\[:u]\s0\[aa]'
.br
L\o'\[:U]\[ah_uc]' l\o'\[:u]\[ah_lc]'   L\o'\s-2\[:U]\s0\[ah]'
l\o'\s-2\[:u]\s0\[ah]'
.br
L\o'\[:U]\[ga_uc]' l\o'\[:u]\[ga_lc]'   L\o'\s-2\[:U]\s0\[ga]'
l\o'\s-2\[:u]\s0\[ga]'
.br
.sp
BW:     Zu\['o]ti\o'a\[a-]'n w\o'o\[ah]' b\o'a\[a-]'ng
n\o'\s-2\[:u]\s0\[ah]'\['e]r q\[`u] y\o'\[.i]\[a-]' ji\o'a\[a-]'
cha\o'o\[a-]'sh\[`i] ma\o'\[.i]\[ah]' k\o'e\[ah]'l\[`e],
x\o'\[.i]\[a-]'f\[`a]n,
do\[`u]p\['i].
.br
GBR:    Zu\['o]ti\o'a\[a-]'n w\o'o\[ah]' b\o'a\[a-]'ng
n\o'\[:u]\[ah_lc]'\['e]r q\[`u] y\o'\[.i]\[a-]' ji\o'a\[a-]'
cha\o'o\[a-]'sh\[`i] ma\o'\[.i]\[ah]' k\o'e\[ah]'l\[`e],
x\o'\[.i]\[a-]'f\[`a]n,
do\[`u]p\['i].


[1] I haven't checked if this is a limitation of Heirloom Doctools troff, and
I have no way to check typesetter output on Version 7 Unix (with a mild effort
I can check nroff output on the same platform), but that's utterly
inapplicable here.  AT&T *roff can't be trusted to emit diagnostics.

(file #51407)
    _______________________________________________________

Additional Item Attachment:

File name: pinyin_bernd_vs_branden.png    Size:31 KB
   
<https://file.savannah.gnu.org/file/pinyin_bernd_vs_branden.png?file_id=51407>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57524>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/