[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/
- [bug #59750] italic correction sometimes fails when the same glyphs are invoked with different input,
Dave <=