bugGNU roff - Bugs: bug #64344, support arbitrary ligatures

 
 

bug #64344: support arbitrary ligatures

Submitter:  Dave <barx>
Submitted:  Sun 25 Jun 2023 03:52:14 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 25 Jan 2024 01:47:05 AM UTC, comment #2: 

The thread starting at http://lists.gnu.org/r/groff/2024-01/msg00091.html (continued under a different subject line, so not linked to that one, at http://lists.gnu.org/r/groff/2024-01/msg00100.html) points out a language, Tibetan, where groff's lack of ligature support prevents the language from rendering correctly.

Dave <barx>
Group Member
Tue 27 Jun 2023 06:49:29 AM UTC, comment #1: 

I support this.  Tadziu's proposal seems well-considered (not a suprise).


I think the best would be a specification that allows sequences
of characters to be mapped to groff entity names, either in
terms of already-compounded entities (similar to what the
AFM file defines for PS glyph names, or what TeX does),

  ...
  charset
  ...
  ligatures
  f  i fi
  f  l fl
  f  f ff
  ff i Fi
  ff l Fl
  kernpairs
  ...

or looking at more than just the next input character,

  ...
  charset
  ...
  ligatures
  f f i Fi
  f f l Fl
  f i   fi
  f l   fl
  f f   ff
  kernpairs
  ...


The only thing that makes me uncomfortable about the above is that "ligatures" is already a recognized directive with pretty different parsing semantics.


    ligatures lig1 ... lign [0]
        Glyphs lig1, ..., lign are ligatures; possible ligatures are ff,
        fi, fl, ffi, and ffl.  For compatibility with other troff
        implementations, the list of ligatures may be terminated with
        a 0.  The list of ligatures must not extend over more than one
        line.



It would suck to break back-compatibility, might be fragile to maintain enough state to distinguish the foregoing while maintaining compatibility, and promises to be tedious to document such a Janus-faced directive so that users will understand it.

So I would pick a different keyword.

G. Branden Robinson <gbranden>
Group administrator
Sun 25 Jun 2023 03:52:14 PM UTC, original submission:  

Bug #40717 covers modernizing groff's font support, a massive undertaking.  But even with only PostScript Type 1 support, as groff presently has, incremental improvements can be made.

One relatively simple one is to expand what ligatures groff recognizes.  The current hard-coded five (fi, fl, ff, ffi, and ffl) are based on the C/A/T, an output device that hasn't been relevant in decades.  Type 1 fonts can specify arbitrary ligatures; a small but significant improvement would be letting afmtodit generate font description files with these, and having groff use them.

http://lists.gnu.org/r/groff/2013-11/msg00028.html has some design spitballing that may or may not prove useful.

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

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 gbranden (Posted a comment)
  • -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.13-4448.
    Corresponding source code