[bug #64155] Specifying -fZD on command line generates warnings

[Dave]

Update of bug #64155 (group groff):

Category:Core => Macro package -
others/general
 Summary: [troff] specifying -fZD on command line generates
warnings => Specifying -fZD on command line generates warnings


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Peter Schaffter]

Update of bug #64155 (group groff):

  Status:   Confirmed => Need Info  

___

Follow-up Comment #32:


[comment #28 comment #28:]
> [comment #27 comment #27:]
> > Hi Peter,
> 
> I should have spent a little longer on that comment since I tossed the ball
back into your court, even if just for advice.
> 
> > Please confirm my understanding of the foregoing and I will proceed with
the reversion right away.
> 
> Specifically, am I correct to claim either of the following?
> 
> A.  "[G]iven that mom has her own system of managing fonts, and part of her
contract with the user [...] is that [the] user will not go behind her back
and start invoking *roff requests." is a false statement.  (Possibly an
exaggeration.)

Oversimplification, possibly my fault.  You got the idea from this bit of the
documentation:

"In some cases, mom’s typesetting macros merely imitate groff primitives. In
others, they approach typesetting concerns in conceptually new ways (for
groff, at least). This should present no problem for newcomers to groff who
are learning mom. Old groff hands should be careful. Just because it looks
like a duck and walks like a duck does not, in this instance, mean that it is
a duck. When using mom, stay away from groff primitives if mom provides a
macro that accomplishes the same thing."

That's not a contract, it's a recommendation.  I don't want users imagining.
for example, that they can use either .ps or .PT_SIZE interchangeably (or
.ft/.FT) and expect the same results.  E.g. if AUTOLEAD is enabled, .PT_SIZE
changes the pointsize and updates the leading.  Plain .ps only changes the
size, hence the recommendation to stay away from groff primitives *if mom
provides a macro that accomplishes the same thing.*  There a number of macros
where the documentation explicitly states that using a primitive instead of a
macro is fine.

I'm not comfortable with the statement "mom has her own system of managing
fonts."  Other than that .FAM and .FT perform checks and set registers needed
by other macros, and the inclusion of pre-defined supplementary styles (none
loaded in positions 1-4), there is nothing unique about mom's font
management.
 
> B.  The statement "By issuing appropriate formatter instructions, you can
override these defaults before your document writes its first glyph." in our
manual should be dropped, or revised to stipulate that some macro packages
(namely _mom_), will assume that that before a document requests a glyph to be
formatted, mounting position 1 will be assigned to a style named 'R'.

I'm confused.  The docs currently say, "The default mounting position, and
therefore style, is always '1' ('R')"  Why would this suddenly only apply to
"some" macro packages?  I don't think the B. statement should be dropped, but
I would change "these defaults" because the only formatter flag pertinent to
that section of the documentation is -f .



___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #31, bug #64155 (group groff):

[comment #27 comment #27:]
> it would be good to know if/how Dave's original report in
> comment #0 was invalid.

I'm fine with -fZD failing on the grounds that groff doesn't consider ZD a
family, but the failure mechanism should be cleaner.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Update of bug #64155 (group groff):

  Status:   Need Info => Confirmed  

___

Follow-up Comment #30:

Thanks, Deri--that analysis was highly illuminating.  I feel I know what I
need now to write a rationale committing the reversion.

That will take a little time, as will composing a proper response to comment
#29 where I expect to mull alternative avenues for solving the problem of
comment #0, but y'all can expect the reversion to land overnight UTC.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Deri James]

Follow-up Comment #29, bug #64155 (group groff):


> Well, when you're prepared to discuss it, it would be good to know if/how
Dave's original report in comment #0 was invalid

I think I can answer this - it is certainly not invalid, it just has nothing
to do with ZD not being a "proper" family (in your eyes). If you do -fZD,
which has no alphabetic glyphs, any start up macros which contain conditional
statements of the form:-

.if '\*[.T]'html' \" etc..

Will produce character not found errors, since, as we know, both sides are
formatted in separate environments and compared.

The give away in Dave's initial report is that the "character undefined"
errors spell out the words "ps/pdf/html" at least can be seen. I'm sure this
"feature" has come up before. Even with Branden's code which stopped -fZD from
working did not address the real problem because if you have four fonts with
R, I, B, and BI extension but don't contain alphabetic characters, -f works
for the "family" but you will see exactly the same errors as Dave reported.

One way for a proper fix, is to create a copy of TR as TRSKEL, add the
"special" parameter, and change the name parameter to TRSKEL, remove all
kernpairs, delete all glyph definitions above 127, and finally alter the DESC
file by incrementing the number and adding TRSKEL on the end. This will solve
the error occurring if you use -f on fonts which don't contain ascii glyphs,
such as some CJK fonts. This can all be done in the devpdf directory (I have
done it for testing), but a very similar change can be made to devps as well.

An alternative fix would be to consider including the GNU UnifontMedium font
in groff and using it as a special instead of TRSKEL, this has the advantage
of solving any undefined glyphs as well, but there are other issues.



___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Follow-up Comment #28, bug #64155 (group groff):

[comment #27 comment #27:]
> Hi Peter,

I should have spent a little longer on that comment since I tossed the ball
back into your court, even if just for advice.

> Please confirm my understanding of the foregoing and I will proceed with the
reversion right away.

Specifically, am I correct to claim either of the following?

A.  "[G]iven that mom has her own system of managing fonts, and part of her
contract with the user [...] is that [the] user will not go behind her back
and start invoking *roff requests." is a false statement.  (Possibly an
exaggeration.)

B.  The statement "By issuing appropriate formatter instructions, you can
override these defaults before your document writes its first glyph." in our
manual should be dropped, or revised to stipulate that some macro packages
(namely _mom_), will assume that that before a document requests a glyph to be
formatted, mounting position 1 will be assigned to a style named 'R'.

Thanks for any light you can shed here.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Follow-up Comment #27, bug #64155 (group groff):

Hi Peter,

[comment #26 comment #26:]
> I guess I wasn't clear enough when I advised not implementing .fam checking
as proposed by Branden,

Please be reassured that this wasn't a matter of proceeding over your protest
(5 March 2024); the commit had already been in place on the master branch
since 10 July 2023.
 
> as I have just discovered the change has been committed, with the expected
consequence: partial families in my library that have only R and I fonts choke
on .fam.
> 
>   printf ".fam Technical\n.ft R" | groff -z 
>   troff::1: error: 'Technical' is not a valid font family
> 
> This is a regression.

This example invalidates one of the premises I put forward in comment #22
("given that mom has her own system of managing fonts, and part of her
contract with the user, as I understand it, is that [the] user will not go
behind her back and start invoking *roff requests") and regarding which I
solicited your input.

It may also invalidate some language I put into our Texinfo manual.


   The default family used with abstract styles is initially 'T'.
Typically, abstract styles are arranged in the first four mounting
positions in the order shown above.  The default mounting position, and
therefore style, is always '1' ('R').  By issuing appropriate formatter
instructions, you can override these defaults before your document
writes its first glyph.


...namely, the final sentence.

Please confirm my understanding of the foregoing and I will proceed with the
reversion right away.

> Please revert the commit that introduced it,
> 39ffa368dc6a1de4c11cf3f4f5b8594d3c974173.  I don't see any need for .fam
checking in the first place, but that discussion should be left for after the
commit is reverted.

Well, when you're prepared to discuss it, it would be good to know if/how
Dave's original report in comment #0 was invalid.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Update of bug #64155 (group groff):

  Status:   Confirmed => Need Info  


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Peter Schaffter]

Follow-up Comment #26, bug #64155 (group groff):

I guess I wasn't clear enough when I advised not implementing .fam checking as
proposed by Branden, as I have just discovered the change has been committed,
with the expected consequence: partial families in my library that have only R
and I fonts choke on .fam.

  printf ".fam Technical\n.ft R" | groff -z 
  troff::1: error: 'Technical' is not a valid font family

This is a regression.  Please revert the commit that introduced it,
39ffa368dc6a1de4c11cf3f4f5b8594d3c974173.  I don't see any need for .fam
checking in the first place, but that discussion should be left for after the
commit is reverted.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

Update of bug #64155 (group groff):

  Status:   Need Info => Confirmed  
 Assigned to:PTPi => gbranden   

___

Follow-up Comment #25:

Thanks, Peter.  In light of comment #24, taking this out of Need Info status
and reassigning to Branden.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Peter Schaffter]

Follow-up Comment #24, bug #64155 (group groff):

The restriction does conflict with mom's supplementary styles, however  the
conflict is not unique to mom.  Any user-installed family may not have all of
R/I/B/BI and, if a user gets creative with .sty, may not, in fact, have any of
them.  I have dozens of partial families, and plenty with just .sty's taken
from mom's offerings


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

Update of bug #64155 (group groff):

 Assigned to:deri => PTPi   

___

Follow-up Comment #23:

[comment #21 comment #21:]
> this code:-
...
> Copied the corrupt file rather than the correct file in
> ./font/devpdf. What is the purpose of this?

This issue being unrelated to this ticket's original purpose (which was fixed
and closed with comment #17), I opened bug #65415 to address it separately.

> I am going to leave this open so that you can reply to 
...
> whether you think this change will affect mom's use of .fam.

This seems to be the only other question keeping this ticket open now.  Ping:
Peter.  (Also assigning the bug to him for now, since Deri has withdrawn from
gropdf work.)


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Update of bug#64155 (group groff):

 Assigned to:gbranden => deri   

___

Follow-up Comment #22:

[comment #21 comment #21:]
> Hi Branden,
> 
> I've worked it out. This is the problem, I had a corrupt copy of U-TR in my
build directory

Ok.  That explains the different file size as noted in comment #20.

> so this code:-

>   if test -f $f; then \
> /usr/bin/install -c -m 644 $f /usr/share/groff/1.23.0/font/devpdf/$f; \
>   else \
> /usr/bin/install -c -m 644 ./font/devpdf/$f \
>   /usr/share/groff/1.23.0/font/devpdf/$f; \
>   fi; \


> Copied the corrupt file rather than the correct file in ./font/devpdf. What
is the purpose of this?

I don't know.  My name is on the 2 lines of the else branch per "git blame"
but closer inspection reveals that all I did was break the long lines.  Before
that was a commit by Bertrand.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=b101574cae1b3019d4109d72b81e4c0a33bb5a86

and before that it was a "Makefile.sub" written by...

...you.  ;-)

> I am going to leave this open so that you can reply to the above

I'm going to plead noninvolvement on this one.  :P

> and whether you think this change will affect mom's use of .fam.

I don't _think_ so, given that mom has her own system of managing fonts, and
part of her contract with the user, as I understand it, is that user will not
go behind her back and start invoking *roff requests.

But I'll add Peter to the CC so he can opine.  I trust he'll know if I'm
confounding anything mom does.

> Also, I am a bit surprised that you must be reading U-TR (rather than just
checking for its existence) and then when it fails (silently) it compains
about the family, which is confusing, rather than reporting a font as
corrupt.

I agree.  I'm not happy with that, either.  See the end of comment #15.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Deri James]

Update of bug#64155 (group groff):

 Assigned to:deri => gbranden   

___

Follow-up Comment #21:

Hi Branden,

I've worked it out. This is the problem, I had a corrupt copy of U-TR in my
build directory so this code:-

  if test -f $f; then \
/usr/bin/install -c -m 644 $f /usr/share/groff/1.23.0/font/devpdf/$f; \
  else \
/usr/bin/install -c -m 644 ./font/devpdf/$f \
  /usr/share/groff/1.23.0/font/devpdf/$f; \
  fi; \

Copied the corrupt file rather than the correct file in ./font/devpdf. What is
the purpose of this?

I am going to leave this open so that you can reply to the above and whether
you think this change will affect mom's use of .fam.

Also, I am a bit surprised that you must be reading U-TR (rather than just
checking for its existence) and then when it fails (silently) it compains
about the family, which is confusing, rather than reporting a font as
corrupt.




___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Update of bug#64155 (group groff):

 Assigned to:gbranden => deri   

___

Follow-up Comment #20:

Hi Deri,

[comment #19 comment #19:]

> [derij@pip build (master)]$ ll ~/groff-git/groff/build/font/devpdf/U-T*
> -rw-r--r-- 1 derij derij 26563 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TB
> -rw-r--r-- 1 derij derij 30421 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TBI
> -rw-r--r-- 1 derij derij 30662 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TI
> -rw-r--r-- 1 derij derij 26596 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TR

> [derij@pip build (master)]$ ll /usr/share/groff/1.23.0/font/devpdf/U-T*
> -rw-r--r-- 1 root root 26563 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TB
> -rw-r--r-- 1 root root 30421 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TBI
> -rw-r--r-- 1 root root 30662 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TI
> -rw-r--r-- 1 root root 17000 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TR


Before we go down a rabbit hole of instrumentation and/or GDB backtracing, I
noticed something there.

These file sizes are the same except for U-TR.  What's going on there?  Is the
U-TR in _/usr/share/groff/1.23.0/font/devpdf/_ a valid font file?  If so, how
does it differ from the one in
_/home/derij/groff-git/groff/build/font/devpdf/_?


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Deri James]

Follow-up Comment #19, bug#64155 (group groff):

Further testing shows that test-groff works but after a make install it
fails!!

test-groff

[pid 3056312] openat(AT_FDCWD,
"/home/derij/groff-git/groff/build/font/devpdf/U-TR", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=26596, ...},
AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD,
"/home/derij/groff-git/groff/build/font/devpdf/U-TI", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=30662, ...},
AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD,
"/home/derij/groff-git/groff/build/font/devpdf/U-TB", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=26563, ...},
AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD,
"/home/derij/groff-git/groff/build/font/devpdf/U-TBI", O_RDONLY) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=30421, ...},
AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3664, ...},
AT_EMPTY_PATH) = 0
[pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3664, ...},
AT_EMPTY_PATH) = 0
[pid 3056312] openat(AT_FDCWD,
"/home/derij/groff-git/groff/build/font/devpdf/U-TR", O_RDONLY) = 3

[derij@pip build (master)]$ ll ~/groff-git/groff/build/font/devpdf/U-T*
-rw-r--r-- 1 derij derij 26563 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TB
-rw-r--r-- 1 derij derij 30421 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TBI
-rw-r--r-- 1 derij derij 30662 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TI
-rw-r--r-- 1 derij derij 26596 Feb  5 23:40
/home/derij/groff-git/groff/build/font/devpdf/U-TR

after install (groff)

[pid 3048720] openat(AT_FDCWD, "/usr/share/groff/1.23.0/font/devpdf/U-TR",
O_RDONLY) = 3
[pid 3048720] newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=17000, ...},
AT_EMPTY_PATH) = 0
troff: fatal error: 'U-T' is not a valid font family
[pid 3048720] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3048720,
si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---

[derij@pip build (master)]$ ll /usr/share/groff/1.23.0/font/devpdf/U-T*
-rw-r--r-- 1 root root 26563 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TB
-rw-r--r-- 1 root root 30421 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TBI
-rw-r--r-- 1 root root 30662 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TI
-rw-r--r-- 1 root root 17000 Feb  5 23:44
/usr/share/groff/1.23.0/font/devpdf/U-TR




___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Deri James]

Update of bug#64155 (group groff):

Severity:   2 - Minor => 3 - Normal 
  Status:   Fixed => Need Info  
 Open/Closed:  Closed => Open   

___

Follow-up Comment #18:

Why is this happening?

[derij@pip Russian]$ echo "Deri" | groff -Tpdf -fU-T -z
troff: fatal error: 'U-T' is not a valid font family
[derij@pip Russian]$ ls /usr/share/groff/1.23.0/font/devpdf/U-T*
/usr/share/groff/1.23.0/font/devpdf/U-TB  
/usr/share/groff/1.23.0/font/devpdf/U-TI
/usr/share/groff/1.23.0/font/devpdf/U-TBI 
/usr/share/groff/1.23.0/font/devpdf/U-TR

Whilst this is clearly wrong, I wondered if you had run this new restriction
past Peter. You may not be aware of this Appendix for mom:-

http://www.schaffter.ca/mom/momdoc/appendices.html#fonts

I'm not sure whether this restriction will affect mom's use of .fam, .ft and
.sty.

+verbatim+



___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Update of bug #64155 (project groff):

  Status: Ready for Merge => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 
 Summary: [PATCH] specifying -fZD on command line generates
warnings => specifying -fZD on command line generates warnings

___

Follow-up Comment #17:


commit 39ffa368dc6a1de4c11cf3f4f5b8594d3c974173
Author: G. Branden Robinson 
Date:   Thu May 25 05:35:25 2023 -0500

[troff]: Validate a font family before using it.

* src/roff/troff/env.cpp (is_family_valid): New function checks for all
  text styles (R, I, B, BI) and returns true only if the given family
  supports them all.

  (family_change): Call `is_family_valid()` on given argument.  If
  invalid, throw diagnostic and ignore `fam` request.

* src/roff/troff/env.h (is_family_valid): Declare; make visible.

* src/roff/troff/input.cpp (main): Call `is_family_valid()` on `-f`
  option argument.  Its invalidity is a fatal error.

Fixes .  Thanks to Dave Kemper for
the report.

Tested with:

$ echo | ./build/test-groff -fZD -z
troff: fatal error: 'ZD' is not a valid font family
$ echo | ./build/test-groff -fH -z
$ nl ./EXPERIMENTS/validate-family.groff
 1  .tm .fam=\n[.fam]
 2  .fam H
 3  .tm .fam=\n[.fam]
 4  .fam
 5  .tm .fam=\n[.fam]
 6  .fam ZD
 7  .fam BOGUS
 8  .tm .fam=\n[.fam]
 9  .fam
10  .tm .fam=\n[.fam]
$ ./build/test-groff ./EXPERIMENTS/validate-family.groff
.fam=T
.fam=H
.fam=T
troff:./EXPERIMENTS/validate-family.groff:6: error: 'ZD' is not a valid
font family
troff:./EXPERIMENTS/validate-family.groff:7: error: 'BOGUS' is not a valid
font family
.fam=T
.fam=H




___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Update of bug #64155 (project groff):

  Status:None => In Progress
 Assigned to:None => gbranden   

___

Follow-up Comment #10:

Hi Dave,

How does this look?  (Apart from a little confusing, since this is mixed input
and output.)


$ ./build/test-groff -b -ww
.tm .fam=\n[.fam]
.fam=T
.fam H
.tm .fam=\n[.fam]
.fam=H
.fam
.tm .fam=\n[.fam]
.fam=T
.fam ZD
troff: backtrace: file '':6
troff::6: error: 'ZD' is not a family; missing style 'I'
.fam BOGUS
troff: backtrace: file '':7
troff::7: error: 'BOGUS' is not a family; missing style 'R'
.tm .fam=\n[.fam]
.fam=T
.fam
.tm .fam=\n[.fam]
.fam=H




___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Deri James]

Follow-up Comment #9, bug #64155 (project groff):

I don't think CJK fonts have I or BI variants (but they can have R and B). To
view Japanese man pages something like this is used:-

groff -Tpdf -man -dHF=MB -kt -mja -fM -dpaper=a4 -P-pa4 groff.7  >
groff.7.pdf

So it probably would be better to check if the R font of given -f fam contains
latin-1 charset (don't need to check all - if 'a' and 'A' are in their latin-1
positions it would be sufficiently indicative).

NB gropdf support for multi thousand glyph fonts is in development, grops
already supports.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Follow-up Comment #8, bug #64155 (project groff):


[comment #7 comment #7:]
>   Thus "ZD" is accepted as a family name,
> as the letter "R" is interpreted as meaning a roman font.

[and on the 'ps' device, a "ZDR" font description actually exists]

I noticed this myself, and is one reason I proposed checking all four styles
when the user (attempts to) select a family.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Bjarni Ingi Gislason]

Follow-up Comment #7, bug #64155 (project groff):

  My "solution" has a side effect,
so it can't be integrated into the software.

  If an input file is used with some characters,
then it turns out,
that the font "ZDR" is used.

  Thus "ZD" is accepted as a family name,
as the letter "R" is interpreted as meaning a roman font.



___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Follow-up Comment #6, bug #64155 (project groff):


> Is it an error to specify a family where some font styles are missing if the
document never asks to use those styles?

I'd characterize that as a warning.  I'd like to see the formatter check for
the existence of all four styles when a family is requested.  (Or at startup
if `-f` is specified.)
 
> Is it an error to specify a family where _all_ font styles are missing if
the document never actually uses that family? (e.g., specifying "-fZD" on the
command line to process a document whose first line is ".fam T")

I'd make this a warning too.

And, more realistically, in the case where, on the "dvi" device, someone
specified -fC, thinking they could get something equivalent to the "Courier"
family.  But the Computer Modern fonts aren't quite up to that.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #5, bug #64155 (project groff):

[comment #3 comment #3:]
> Possibly a search for the requisite styles could be undertaken
> upon use of the `-f` flag or `fam` request, errors thrown for
> any that are missing, and the option or request ignored.

Hmm, that raises a couple of interesting questions.

Is it an error to specify a family where some font styles are missing if the
document never asks to use those styles?

Is it an error to specify a family where _all_ font styles are missing if the
document never actually uses that family? (e.g., specifying "-fZD" on the
command line to process a document whose first line is ".fam T")


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

Follow-up Comment #4, bug #64155 (project groff):

[comment #3 comment #3:]
> However, Zapf Dingbats is a specific face, not a family.  And
> not a member of a family.

Whoops!  You're right.

> Remember this old chestnut?
> 

> troff: EXPERIMENTS/font-errors.groff:23: warning: can't find font
'BOGUSR'


> 
> This is pretty close to the actual problem.  If "ZD" is the
> family, then the formatter expects to find fonts named "ZDR",
> "ZDI", "ZDB", and "ZDBI".

This could be what's going on, but the "character not defined" warnings
suggest that groff _is_ successfully (though perhaps wrongly) setting the font
to something that lacks basic alphabetic characters (as ZD does), then running
into the string-comparison issue Deri noted (comment #1).  If groff were
seeking a phantom "ZDR" font, the font-setting should fail altogether, leaving
the font as TR, which I wouldn't expect to produce those particular warnings.

> The numeric overflow is interesting.

#NoBoringBugs


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[G. Branden Robinson]

Follow-up Comment #3, bug #64155 (project groff):

This is kind of a case of "don't do that, then".  ("Doctor, it hurts when I do
this!")


-f fam
Set default font family.


However, Zapf Dingbats is a specific face, not a family.  And not a member of
a family.

No matter what happens, you'll get diagnostics, but we probably could improve
the diagnostics you get.

Remember this old chestnut?


troff: EXPERIMENTS/font-errors.groff:23: warning: can't find font
'BOGUSR'


This is pretty close to the actual problem.  If "ZD" is the family, then the
formatter expects to find fonts named "ZDR", "ZDI", "ZDB", and "ZDBI".

Possibly a search for the requisite styles could be undertaken upon use of the
`-f` flag or `fam` request, errors thrown for any that are missing, and the
option or request ignored.

The numeric overflow is interesting.


___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Bjarni Ingi Gislason]

Follow-up Comment #2, bug #64155 (project groff):

  I found a solution, it did though need thinking to find it.

test-groff -ww -b -z -fZD /dev/null

  runs then with no output and returns with zero as exit value.

  I will leave this bug as is, to give you (plural) a chance to find a
solution on your own.



___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Deri James]

Follow-up Comment #1, bug #64155 (project groff):

I suspect this is related to bug #64144 (errors when setting -f to a font
which does not contain a full latin-1 character set). It occurs when using .if
''' in a macro so a construct such as .if '\*[.T]'html' will fail when troff
generates the output of both to compare.

Branden devised an ingenious solution in bug #64144, it is a bit odd because
-T pdf produces a different error:-

[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tps -fEURO -a
troff: fatal error: invalid default font family 'EURO'
[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tpdf -fEURO -a
troff: fatal error: invalid default font family 'EURO'
[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tpdf -fZD -a
troff: fatal error: invalid default font family 'ZD'
[derij@pip build (new-gropdf)]$ echo ' ' | ./test-groff -Tps -fZD -a
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning:
character 'p' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning:
character 's' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning:
character 'a' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning:
character 'c' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:14: warning:
character 'i' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:16: warning:
character 'l' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:16: warning:
character 't' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:16: warning:
character 'n' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:17: warning:
character 'u' not defined
troff:/home/derij/groff-git/groff/build/../tmac/fallbacks.tmac:17: warning:
character 'f' not defined
troff:/home/derij/groff-git/groff/build/../tmac/troffrc-end:7: warning:
character 'h' not defined
troff:/home/derij/groff-git/groff/build/../tmac/troffrc-end:7: warning:
character 'm' not defined

  
troff:/home/derij/groff-git/groff/build/../tmac/html-end.tmac:20: error:
numeric overflow




___

Reply to this item at:

  

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

[bug #64155] specifying -fZD on command line generates warnings

[Dave]

URL:
  

 Summary: specifying -fZD on command line generates warnings
   Group: GNU roff
   Submitter: barx
   Submitted: Fri 05 May 2023 06:41:19 PM CDT
Category: Font - others/general
Severity: 2 - Minor
  Item Group: Warning/Suspicious behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 05 May 2023 06:41:19 PM CDT By: Dave 
This bug was present in 1.22.4:


$ echo ' ' | groff -fZD -a
troff: /usr/share/groff/1.22.4/tmac/ps.tmac:686: warning: can't find character
'a'
troff: /usr/share/groff/1.22.4/tmac/troffrc-end:7: warning: can't find
character 'p'
troff: /usr/share/groff/1.22.4/tmac/troffrc-end:7: warning: can't find
character 's'
troff: /usr/share/groff/1.22.4/tmac/troffrc-end:7: warning: can't find
character 'h'
troff: /usr/share/groff/1.22.4/tmac/troffrc-end:7: warning: can't find
character 't'
troff: /usr/share/groff/1.22.4/tmac/troffrc-end:7: warning: can't find
character 'm'
troff: /usr/share/groff/1.22.4/tmac/troffrc-end:7: warning: can't find
character 'l'

  
troff: /usr/share/groff/1.22.4/tmac/html-end.tmac:20: numeric overflow


But the number of warnings increased in 1.23.  (Pathnames below trimmed.)

$ groff --version | head -1
GNU groff version 1.23.0.rc4.19-96b92-dirty
$ echo ' ' | groff -fZD -a
troff:.../tmac/fallbacks.tmac:14: warning: character 'p' not defined
troff:.../tmac/fallbacks.tmac:14: warning: character 's' not defined
troff:.../tmac/fallbacks.tmac:14: warning: character 'a' not defined
troff:.../tmac/fallbacks.tmac:14: warning: character 'c' not defined
troff:.../tmac/fallbacks.tmac:14: warning: character 'i' not defined
troff:.../tmac/fallbacks.tmac:16: warning: character 'l' not defined
troff:.../tmac/fallbacks.tmac:16: warning: character 't' not defined
troff:.../tmac/fallbacks.tmac:16: warning: character 'n' not defined
troff:.../tmac/fallbacks.tmac:17: warning: character 'u' not defined
troff:.../tmac/fallbacks.tmac:17: warning: character 'f' not defined
troff:.../tmac/troffrc-end:7: warning: character 'h' not defined
troff:.../tmac/troffrc-end:7: warning: character 'm' not defined

  
troff:.../tmac/html-end.tmac:20: error: numeric overflow









___

Reply to this item at:

  

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