bugGNU roff - Bugs: bug #59750, italic correction sometimes fails...


bug #59750: italic correction sometimes fails when the same glyphs are invoked with different input

Submitter:  Dave <barx>
Submitted:  Mon 21 Dec 2020 08:06:56 PM UTC
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Fri 21 Jul 2023 10:17:03 PM UTC, comment #2: 

The manual contains no example usage of the italic-correction escape (\/), so it's unclear whether it should canonically appear before or after the font-change escape.  In practice it seems not to matter.

Dave <barx>
Group Member
Mon 21 Dec 2020 09:26:23 PM UTC, comment #1: 

"Elsewhere" turns out to be tmac/fallbacks.tmac, where \[u2161] and its kin are defined with .fchar, suggesting that the root problem is that .fchar and \/ aren't on speaking terms.

Dave <barx>
Group Member
Mon 21 Dec 2020 08:06:56 PM UTC, original submission:  

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

.ps 40
.vs 40
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.

Dave <barx>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by barx (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.12