bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #59750] italic correction sometimes fails when the same glyphs are


From: Dave
Subject: [bug #59750] italic correction sometimes fails when the same glyphs are invoked with different input
Date: Mon, 21 Dec 2020 15:06:58 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

URL:
  <https://savannah.gnu.org/bugs/?59750>

                 Summary: italic correction sometimes fails when the same
glyphs are invoked with different input
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Mon 21 Dec 2020 02:06:56 PM CST
                Category: Core
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

This example input generates PostScript or PDF output of four lines.


.nf
.ps 40
.vs 40
.sp
Should I italicize \(lq\fITitan II\fP\(rq?
Should I italicize \(lq\fITitan II\fP\/\(rq?
Should I italicize \(lq\fITitan \[u2161]\fP\(rq?
Should I italicize \(lq\fITitan \[u2161]\fP\/\(rq?


The first line shows a classic case of a line needing italic correction: the
italic capital letter _I_ butts up against the roman closing quotation mark.

The second line is a repeat of the first but with groff's italic-correction
escape (\/) included to fix this problem.

The third line is a repeat of the first (so, sans italic-correction escape)
but with the input string "II" replaced by the escape for the Unicode
character U+2161 ROMAN NUMERAL TWO.  Lacking the italic correction, it
displays the same aesthetically displeasing overlap.

The fourth line is a repeat of the third but with groff's italic-correction
escape included.  In this instance, however, the escape has no effect.

This is especially curious when one examines the PostScript code.  This
reveals that no character U+2161 appears at all; PostScript contains only
capital letter I's regardless whether the input specified I's or \[u2161]. 
Thus, at some point, groff translates the input "\[u2161]" into the output
"II", yet fails to apply italic correction to this translated "II" even though
it does it correctly when the input is a literal "II".

Font TI (and in fact, all default groff fonts) lacks the character \[u2161],
so the translation is happening elsewhere in groff.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]