bugGNU roff - Bugs: bug #54759, slide-demo.mom: Wrong kerning for...

 
 

bug #54759: slide-demo.mom: Wrong kerning for "(°C"

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Sun 30 Sep 2018 06:28:15 PM UTC
   
 
Category:  Macro mom Severity:  2 - Minor
Item Group:  Rendering/Cosmetics Status:  Invalid
Privacy:  Public Assigned to:  PTPi
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 05 Dec 2018 05:35:01 PM UTC, comment #10: 

Deri --

'fc-match Helvetica' on my system returns

  n019003l.pfb: "Nimbus Sans L" "Regular"

as expected.  Is this a distro-related issue?  I'm presently running Kubuntu 16.04 LTS (Xenial) and this is the default.  If your default is Liberation Sans, then the decision is being made upstream.

I propose moving this discussion to the mailing list since it isn't a groff or mom bug but does affect their users.  The degree sign issue in slides-demo has been dealt with.

Peter Schaffter <PTPi>
Group Member
Wed 05 Dec 2018 12:09:11 AM UTC, comment #9: 

Hmm, the font you mention (n0190031.pfb) is one of the URW fonts, which are intended to be used in the "U" foundry. There are differences in the width and height metrics for the "ring above" (degree) glyph, between the fonts HR and U-HR. Since your version of okular is choosing the URW Helvetica font (n0190031.pfb) if you change the table to use .FAMILY U-H you will find that the degree symbol prints normally.

The next question is why is okular using this particular fonts since this particular glyph is not matching the Adobe standard metrics which the default HR font is built to use. Okular (and evince) use the poppler library which in turn uses fontconfig. On my system if I type:-

fc-match Helvetica

I get:-

LiberationSans-Regular.ttf: "Liberation Sans" "Regular"

and this is what Okular shows in its font list.

Please check what you get. This font works correctly on my system because it uses the standard metrics, even though the glyph shapes are different, the overal widths of the glyph with their spacing are the same. If you try changing the .FAMILY before the table and remove the extra spacing around the \[de] it should look Ok, because the metrics in the groff font will match the metrics in the font okular is using.

However, I entirely agree with you that in this particular case having no degree sign is perfectly acceptable given the purpose of the document, however, I decided to investigate, since at some point it may matter.

Deri James <deri>
Group Member
Tue 04 Dec 2018 05:57:57 PM UTC, comment #8: 

The fonts used by PDF viewers are the likely culprits, as you've determined, which Deri pointed out can be fixed by building files with the -P-e flag.

On inspection, Okular and evince are substituting non-embedded HR with Nimbus Sans L (/usr/share/fonts/X11/Type1/n0190031.pdf.  The fonts on my system are the ones shipped with Ubuntu 16.04 (Xenial), so not old or deprecated as far as I know. 

This issue therefore has the potential to affect any groff-generated pdf file and is not a mom bug.  It needs to be discussed on the groff mailing list.  It isn't a groff bug, either, but we need to decide how to deal with it.  Most likely with cautionary notes in all the right places and a recommendation to embed fonts in pdf files.

slides.demo is not an appropriate place for such a note.  Whether or not the fake table used as an example contains the degree sign is of no importance whatsoever so I've taken it out.  No intention of restoring it just to add a note saying it might not look good in some viewers.  Pointless, and puts a bad face on groff.


Peter Schaffter <PTPi>
Group Member
Mon 03 Dec 2018 11:08:25 PM UTC, comment #7: 

  The degree sign is NOT the culprit, but the used font by the your
pdf-viewer.  You did not mention the name of those.

  Adding a note about the inability of a named pdf-viewer (or font)
(with version) to place the degree sign properly is then appropriate to
put above the table on the slide.

  I changed the following in the file "slide-demo.mom" (besides
"(\[de]C)" to "/\[de]C"):

--- slide-demo.mom.bak.30-11-2018.2960 2018-11-29 23:57:50.000000000 +0000
+++ slide-demo.mom 2018-11-30 21:25:45.000000000 +0000
@@ -285,10 +285,14 @@ typesetting macros, including preprocess
 .TS H BOXED
 tab(^) allbox;
 c c
-n n.
+a a.
 \*[darkred]\s[-.5]\*[DOWN .5p]Year^Mean Temp./\[de]C\s[0]\*[blue2]
 _
 .TH
+|\[de]|^/\[de]C /\[de]F
+(\[de])^(\[de]C) (\[de]F)
+(C)^(F)
+\s[-0.5]Year^Mean Temp./\s-2\[de]\s+2C\s[+0.5]
 \*[cyan4]\fB2015^28.3\*[blue2]
 \*[cyan4]1998^28.3\*[blue2]
 \*[cyan4]1997^28.3\*[blue2]


  So changing "(\[de]C)" to "/\[de]C" showed no (obvious) defects,
adding testing with the following packages with a pdf-viewer:

evince

okular

viewpdf.app

  and

Adobe Acrobat Reader DC version 2019,008,20081 on another computer.

  To see how the degree sign is placed within its boundaries one can
change the file "fonts_n.roff" by adding '|' on each side of a
character, line nr. 128:

\N'\En[c#]'""" \

  My fonts show a central position of the degree sign, except for some
italic fonts, which can be regarded as acceptable.

  With "xpdf" version 3.03 (August 2011?) on another computer, I see
the same displacement of the degree sign as in the example file
"not-adjusted.png".

  So you are (were) using an old, deprecated font.


Bjarni Ingi Gislason <bjarniig>
Fri 30 Nov 2018 04:08:36 PM UTC, comment #6: 

All the patch does is re-introduce the problematic degree sign I just took out.  We want a good example of tbl, not an example of a good table.  The material could just as well be greeked for all its relevance to the purpose.   

Peter Schaffter <PTPi>
Group Member
Fri 30 Nov 2018 12:09:32 AM UTC, comment #5: 


  Measurements need a unit to be unique.

  In headers the name of the quantity and the unit are displayed with a
division mark between them, for example 't/°C', 'T/K', 'distance/m',
and so on.  The name or symbol of the quantity is usually printed in
italic.

Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
---
 contrib/mom/examples/slide-demo.mom | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/mom/examples/slide-demo.mom b/contrib/mom/examples/slide-demo.mom
index 2dc44392..d8d14ae8 100644
--- a/contrib/mom/examples/slide-demo.mom
+++ b/contrib/mom/examples/slide-demo.mom
@@ -286,7 +286,7 @@ typesetting macros, including preprocessors and image insertion\*[HANG .]
 tab(^) allbox;
 c c
 n n.
-\*[darkred]\s[-.5]\*[DOWN .5p]Year^Mean Temp.\s[0]\*[blue2]
+\*[darkred]\s[-.5]\*[DOWN .5p]Year^Mean Temp./\[de]C\s[0]\*[blue2]
 _
 .TH
 \*[cyan4]\fB2015^28.3\*[blue2]
--
2.19.2


Bjarni Ingi Gislason <bjarniig>
Mon 26 Nov 2018 04:21:09 PM UTC, comment #4: 

For the present issue, the simplest solution  is to replace the table header with something that renders neatly without kerning.  It is, after all, just an example.  I'll take care of it and mark this bug closed.

Since the matter of slight differences in font rendering across pdf viewers has come up before, I'm wondering if we should make a note of it somewhere that recommends the -P-e solution.

Peter Schaffter <PTPi>
Group Member
Mon 26 Nov 2018 08:54:31 AM UTC, comment #3: 

Since you are seeing different results with different viewers, you could try the flags "-P-e" on your test-groff line. (This will embed the fonts in the pdf so the viewers should all look the same, but the file will be much larger).

Deri James <deri>
Group Member
Mon 26 Nov 2018 01:33:39 AM UTC, comment #2: 

  The line I use is:

(\[de]C)\s[0]\*[blue2]

  The differences could be

1) different PDF-files, slide-demo.pdf

  From "test-groff -Tps -mpdfmark -mom -Z ..."

and

  from "test-groff -Tpdf -mom -Z ...":

x font 20 HB (or number 22)
...
f20 (or number 22)
...
s11000
...
t(
Cde
h4400
tC)



From "pdfinfo ...":

File size:      90208 bytes (does not say much)
Optimized:      no
PDF version:    1.4

From "pdffonts ...":

name                type     encoding         emb sub uni object ID
------------------- -------- ---------------- --- --- --- ---------
Courier             Type 1   Custom           no  no  yes     96  0
Symbol              Type 1   Custom           no  no  no      90  0
ZapfDingbats        Type 1   Custom           no  no  no      21  0
Helvetica-Bold      Type 1   Custom           no  no  yes     12  0
Helvetica-Oblique   Type 1   Custom           no  no  yes     72  0
Helvetica           Type 1   Custom           no  no  yes      9  0
Times-Italic        Type 1   Custom           no  no  yes     87  0
Times-Roman         Type 1   Custom           no  no  yes      5  0
Courier-Bold        Type 1   Custom           no  no  yes     51  0


2) different pdf-viewer

To 1:

  I use "test-groff" to create the files in a copy of the current groff
repository.

To 2:

Used pdf-viewers from the testing version of Debian.

xpdf bigger letter than with "gv" and more space in front of ')'

gv OK

atril more space in front of ')'

mupdf OK

zathura more space in front of ')'


Bjarni Ingi Gislason <bjarniig>
Sun 25 Nov 2018 03:08:04 PM UTC, comment #1: 

Not seeing the problem.  Unadjusted (°C looks terrible: far too much space after the left parens and the degree-sign crashes into the letter "C".  Adjusted version corrects both errors.  Have attached pngs demonstrating both as they appear at my end.


Peter Schaffter <PTPi>
Group Member
Sun 30 Sep 2018 06:28:15 PM UTC, original submission:  


slide-demo.mom: Wrong kerning for "(°C"

  The line

(\*[BU6]\[de]\*[FU4]C)\s[0]\*[blue2]

in "contrib/mom/examples/slide-demo.mom" looks bad in the output file
"slide-demo.pdf", page 20.

  I see no need to put (remove) additional space between the left
parentheses, the degree sign ("de") and the letter C.


Bjarni Ingi Gislason <bjarniig>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45522:  not-adjusted.png added by PTPi (3KiB - image/png)
file #45523:  adjusted.png added by PTPi (3KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by PTPi (Updated the item)
  • -email is unavailable- added by bgarrigues (Updated the item)
  • -email is unavailable- added by bjarniig (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.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-30 gbranden StatusConfirmed Invalid
    2018-11-26 PTPi Open/ClosedOpen Closed
    2018-11-25 PTPi Attached File- Added not-adjusted.png, #45522
        Attached File- Added adjusted.png, #45523
    2018-11-25 bgarrigues CategoryNone Macro mom
        Severity3 - Normal 2 - Minor
        Item GroupNone Rendering/Cosmetics
        StatusNone Confirmed
        Assigned toNone PTPi

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code