bug-groff
[Top][All Lists]
Advanced

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

[bug #62763] [man] groff_hdtbl.1.man: do not redefine global character n


From: G. Branden Robinson
Subject: [bug #62763] [man] groff_hdtbl.1.man: do not redefine global character names
Date: Sat, 16 Jul 2022 04:25:54 -0400 (EDT)

Update of bug #62763 (project groff):

                  Status:               Need Info => Confirmed              

    _______________________________________________________

Follow-up Comment #2:

Oh, I get it.

I finally caught Bjarni using the UTF-8 encoding.  ;-)

With the `-Tascii` or `-Tlatin1` options, this problem does not happen.

And that in turn sniffs out the issue.

A groff character entry generally overrides any existing glyph definition of
the same name in the currently available fonts (the one selected plus any
special fonts).

The "ascii", "latin1", and "cp1047" output devices, like most of the others,
all define an "or" glyph as an alias of the "|" glyph.

Character definitions are checked before the font glyph lists.  So if you
remove such a character definition, troff will fall through to the fonts.

For the aforementioned 3 output devices, this works.

But for "utf8", it doesn't.  That is because the UTF-8 fonts have a degraded
glyph repertoire as represented in their font descriptions.  devutf8/DESC has
the "unicode" directive, which means that any font in use is assumed to have
glyphs for all Unicode code points.  (devhtml/DESC does the same thing.)  A
font for such a device can still have glyph definitions, which in that case
override the default logic (which simply constructs a UTF-8 sequence or an
HTML entity).

We should be able to test this theory by running the same experiment on one of
the several typesetter devices that defines an "or" character in terms of
drawing escape sequences.


$ ./build/test-groff -Tlbp -mandoc -t -z build/contrib/hdtbl/groff_hdtbl.7
./EXPERIMENTS/if-c.groff build/man/groff_char.7 
\[or] is NOT defined
\[lB] is defined
troff:build/man/groff_char.7:969: warning: special character 'or' not defined
troff:build/man/groff_char.7:1007: warning: special character '.j' not
defined
troff:build/man/groff_char.7:1356: warning: special character 'braceex' not
defined
troff:build/man/groff_char.7:1358: warning: special character 'bracketlefttp'
not defined
...


I'm undecided as to whether there's anything wrong with this.

As Bjarni notes, the man page shouldn't be doing this in the first place.  I
made the problem worse by removing the character definitions (commit
09687ec7c457d5a8508f3e30280081f467b21d39).  What I should have done was stash
any existing character definitions in strings, and restore the character
definitions using those strings at the end.

But what should _really_ be done is for _groff_hdtbl_(7) to stop fooling
around with character definitions at all.

 Some of the typesetter devices use `char`.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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