[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

[Deri James]

Follow-up Comment #5, bug #65901 (group groff):

I don't think bug #44530 is related, that seems to be a misunderstanding what
".PS 1i" does to picture. You may have specified a certain space/dashwid but
the inclusion of .PS 1i has the effect of scaling the whole picture down to 1
inch so everything is reduced proportionally including the spaces, but not it
seems, the linethick setting.

Anyway, I have setup bug #65910, so you can have a look at what I am talking
about. 


___

Reply to this item at:

  

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

[bug #65910] Some dashed ellipse sizes produce irregular dashes

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65910>

 Summary: Some dashed ellipse sizes produce irregular dashes
   Group: GNU roff
   Submitter: deri
   Submitted: Sat 22 Jun 2024 07:52:18 PM UTC
Category: Preprocessor pic
Severity: 3 - Normal
  Item Group: Rendering/Cosmetics
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sat 22 Jun 2024 07:52:18 PM UTC By: Deri James 
The attached two pdfs are for an 8x3 inch and a 4x1.5 dashed ellipses, i.e.
one is half the size of the other. One looks lovely and one a mess. Both
produced with this command:-

test-groff -Tpdf -ms -p -P-l file.trf > file.pdf

Changing the output device to -Tps does not make any difference, so I think
this indicates the problem lies in pic, possible variable overflow?






___
File Attachments:


---
Name: 8x3.pdf  Size: 4KiB
<https://file.savannah.gnu.org/file/8x3.pdf?file_id=56186>
---
Name: 4x1.5.pdf  Size: 4KiB
<https://file.savannah.gnu.org/file/4x1.5.pdf?file_id=56187>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-3cd0d2c94962908e0e7c31b0cfb957af29c7d567.tar.gz

___

Reply to this item at:

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

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

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

[Deri James]

Update of bug #65901 (group groff):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

This should be fixed now:-

commit dd63af83c106a6a44dbb15ab36d5f3e211515ca5
Author: Deri James 
Date:   Sat Jun 22 18:33:49 2024 +0100

Fix invalid pdf when using certain sizes of
dashed ellipse in pic.

* src/devices/gropdf/gropdf.pl: For short dashes on flat part
of ellipse some v. small numbers written in form n.nnnE-n which
is invalid for pdfs. Also rather than split each arc always into
4 pieces, split into number of quadrants described between start
and end angle. If arc describes a straight line, use line segment
rather than bezier curve. (grops does this as well)

Fixes https://savannah.gnu.org/bugs/index.php?65901

Thanks to Morten Bo Johansen for reporting this issue.

The problem reported for dotted ellipses could not be reproduced, and the dots
are much easier to see if you include the command "linethick=2" in the
picture.

Although this bug is now closed, and I hate maths, I will be opening a new bug
since when dashed ellipses are very large the dashes are irregular, grops and
gropdf show identical irregularity so I suspect it is a problem in pic.


___

Reply to this item at:

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

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

[groff] 01/01: [gropdf] I left a line of debug code

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 5a68413f9458f0b27522019915ed8f0b7ec1b09e
Author: Deri James 
AuthorDate: Sat Jun 22 18:40:39 2024 +0100

[gropdf] I left a line of debug code

* src/devices/gropdf/gropdf.pl: Remove it.
---
 src/devices/gropdf/gropdf.pl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 85a3a5e0f..5a88bc65a 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -3958,7 +3958,6 @@ sub do_D
$endang+=$rad360 if $endang < $startang;
my $pieces=int(($endang-$startang) / $rad90)+1;
my $totang=($endang-$startang)/$pieces;   # do it in pieces
-   print STDERR "Pieces=$pieces, P=",join(',',@p),"\n";
 
# Now 1 piece
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/01: Fix invalid pdf when using certain sizes of dashed ellipse in pic.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit dd63af83c106a6a44dbb15ab36d5f3e211515ca5
Author: Deri James 
AuthorDate: Sat Jun 22 18:33:49 2024 +0100

Fix invalid pdf when using certain sizes of
dashed ellipse in pic.

* src/devices/gropdf/gropdf.pl: For short dashes on flat part
of ellipse some v. small numbers written in form n.nnnE-n which
is invalid for pdfs. Also rather than split each arc always into
4 pieces, split into number of quadrants described between start
and end angle. If arc describes a straight line, use line segment
rather than bezier curve. (grops does this as well)

Fixes https://savannah.gnu.org/bugs/index.php?65901

Thanks to Morten Bo Johansen for reporting this issue.
---
 ChangeLog| 16 
 src/devices/gropdf/gropdf.pl | 60 
 2 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index cec91f58e..e9c4c568f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2024-06-22  Deri James  
+
+   [gropdf] Fix invalid pdf when using certain sizes of
+   dashed ellipse in pic.
+
+   * src/devices/gropdf/gropdf.pl: For short dashes on flat part
+   of ellipse some v. small numbers written in form n.nnnE-n which
+   is invalid for pdfs. Also rather than split each arc always into
+   4 pieces, split into number of quadrants described between start
+   and end angle. If arc describes a straight line, use line segment
+   rather than bezier curve. (grops does this as well)
+
+   Fixes https://savannah.gnu.org/bugs/index.php?65901
+
+   Thanks to Morten Bo Johansen for reporting this issue.
+
 2024-06-21  G. Branden Robinson 
 
* src/roff/troff/env.cpp (environment::possibly_break_line):
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index df645c4e0..85a3a5e0f 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -3922,7 +3922,7 @@ sub do_D
 }
 elsif ($Dcmd eq 'a')
 {
-   # Arc
+   # Arc : h1 v1 h2 v2
$par=substr($par,1);
my (@p)=split(' ',$par);
my $rad180=3.14159;
@@ -3941,25 +3941,43 @@ sub do_D
 
my ($startang,$r)=RtoP(-$centre->[0],$centre->[1]);
my 
($endang,$r2)=RtoP(($p[0]+$p[2])-$centre->[0],-($p[1]+$p[3]-$centre->[1]));
-   $endang+=$rad360 if $endang < $startang;
-   my $totang=($endang-$startang)/4;   # do it in 4 pieces
 
-   # Now 1 piece
-
-   my $x0=cos($totang/2);
-   my $y0=sin($totang/2);
-   my $x3=$x0;
-   my $y3=-$y0;
-   my $x1=(4-$x0)/3;
-   my $y1=((1-$x0)*(3-$x0))/(3*$y0);
-   my $x2=$x1;
-   my $y2=-$y1;
-
-   # Rotate to start position and draw 4 pieces
-
-   foreach my $j (0..3)
+   if (abs($endang-$startang) < 0.004)
+   {
+   if ($frot)
+   {
+   $stream.="q $ypos ".GraphY($xpos)." m ".($ypos+$p[1]+$p[3])." 
".GraphY($xpos+$p[0]+$p[2])." l S Q\n";
+   }
+   else
+   {
+   $stream.="q $xpos ".GraphY($ypos)." m ".($xpos+$p[0]+$p[2])." 
".GraphY($ypos+$p[1]+$p[3])." l S Q\n";
+   }
+   }
+   else
{
-   
PlotArcSegment($totang/2+$startang+$j*$totang,$r,$xpos+$centre->[0],GraphY($ypos+$centre->[1]),$x0,$y0,$x1,$y1,$x2,$y2,$x3,$y3);
+   $endang+=$rad360 if $endang < $startang;
+   my $pieces=int(($endang-$startang) / $rad90)+1;
+   my $totang=($endang-$startang)/$pieces;   # do it in pieces
+   print STDERR "Pieces=$pieces, P=",join(',',@p),"\n";
+
+   # Now 1 piece
+
+   my $x0=cos($totang/2);
+   my $y0=sin($totang/2);
+   return if !$y0;
+   my $x3=$x0;
+   my $y3=-$y0;
+   my $x1=(4-$x0)/3;
+   my $y1=((1-$x0)*(3-$x0))/(3*$y0);
+   my $x2=$x1;
+   my $y2=-$y1;
+
+   # Rotate to start position and draw pieces
+
+   foreach my $j (0..$pieces-1)
+   {
+   
PlotArcSegment($totang/2+$startang+$j*$totang,$r,d3($xpos+$centre->[0]),d3(GraphY($ypos+$centre->[1])),d3($x0),d3($y0),d3($x1),d3($y1),d3($x2),d3($y2),d3($x3),d3($y3));
+   }
}
 
$xpos+=$p[0]+$p[2];
@@ -4001,7 +4019,7 @@ sub adjust_arc_centre
 }
 else
 {
-   return(undef);
+   return([0,0]);
 }
 }
 
@@ -4009,8 +4027,8 @@ sub adjust_arc_centre
 sub PlotArcSegment
 {
 my ($ang,$r,$transx,$transy,$x0,$y0,$x1,$y1,$x2,$y2,$x3,$y3)=@_;
-my $cos=cos($ang);
-my $sin=sin($ang);
+my $cos=sprintf("%0.5f",cos($ang));
+my $sin=sprintf("%0.5f",sin($ang));
 my @mat=($cos,$sin,-$sin,$cos,0,0);
 my $lw=$lwidth/$r;
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

[Deri James]

Follow-up Comment #2, bug #65901 (group groff):

Morton wrote on the bug list:-
 
> Odd. The pdf on my end is simply broken. It doesn't show in
> mupdf either.

Please could you run the dotted ellipse example again but adding this flag
"-P-d", and post the resulting pdf. This adds some debug data which may be
helpful.


___

Reply to this item at:

  

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

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

[Deri James]

Follow-up Comment #1, bug #65901 (group groff):

After changing elipse to ellipse in the two code examples, I can't recreate
the first problem. The dots are visible in zathura. The issue with dashed is
real and is down to my appalling ability with maths. For dashed
ellipse/circles groff outputs each segment as an arc:-

Da h1 v1 h2 v2

Draw arc from current position to (h1,v1)+(h2 ,v2 ) with center at (h1,v1);
then
move the current position to the final point of the arc.

Postscript has an operator called arcn which grops uses:-

arcn
centerx centery radius angle1 angle2 arcn 
- 
clockwise

PDF on the other hand uses cubic bezier curves:-

x1 y1 x2 y2 x3 y3 c

Append a cubic Bézier curve to the current path. The curve extends
from the current point to the point (x3 , y3 ), using (x1 , y1 ) and
(x2 , y2 ) as the Bézier control points (see “Cubic Bézier Curves,” be-
low). The new current point is (x3 , y3 ).

So I have to calculate the control points for the curve. I suspect the
algorithm I am using for this ("borrowed" from
http://www.tinaja.com/glib/bezcirc2.pdf) is breaking down when a very small
arc actually describes a straight line.

As this is a maths problem it may take a while for me to sort out, but if a
proper mathematician can give me an algorithm to create a bezier from the arcn
parameters I can pinch code from grops. :-)



___

Reply to this item at:

  

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

[bug #65619] [afmtodit] want a default value for space width if unspecified

[Deri James]

Follow-up Comment #8, bug #65619 (group groff):

[comment #7 comment #7:]
> As a refresher, I'm wondering what should be done about some of the space
glyphs identified in comment #5.

> So, check for "space", "uni0020", and "uni00A0" in that order?

Yes.

> sterlingmonospace;FFE1

This is not a space it's '￡' FULLWIDTH POUND SIGN

> ideographicspace;3000

Yes.

> nbspace;00A0

This is uni00A0 (see above)

> spacehackarabic;0020

Same as uni0020.

> Advice desired.

Attached are three PDFs.

UniSpaces.pdf: Documents any glyph in the unifont.ttf font (which covers
-FFFE) where the unicode name includes 'space'. This is a mono-spaced font
so the widths given are not particulary helpful.

TinosSpace.pdf: Similar, but covering the Tinos-Regular.ttf font, which gives
proportional widths (the 4 fields in the first line of each glyph are:
unicode, groff name, width, postscript name).

U-TR: Just showing off my new font tool for a complete font. :-)

My take is that EM SPACE and EN SPACE are too large, and EM divisions would be
unreliable, so I think the glyphs suggested above is what I will use to
calculate 'spacewidth'. 

(file #56142, file #56143, file #56144)

___

Additional Item Attachment:

File name: UniSpaces.pdf  Size: 15KiB


File name: U-TR.pdf   Size: 415KiB


File name: TinosSpace.pdf Size: 19KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-67b04ef8737d6f02579af43d702ebae34ebfcbfd.tar.gz


___

Reply to this item at:

  

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

[bug #64005] [ms] fix for Savannah #62688 suppresses page breaks between displays

[Deri James]

Update of bug #64005 (group groff):

  Status:   Fixed => Need Info  
 Open/Closed:  Closed => Open   

___

Follow-up Comment #7:

I think there may be a problem with this fix.

The fix:-

+.\" Wrap the `bp` request so that we disregard the enablement of
+.\" no-space mode, which we enter after displays and equations to
+.\" prevent multiple sources of vertical space (like the DD and PD
+.\" registers) from incorrectly accumulating.  Thus, if the user
+.\" requests a page break, we honor it.  See Savannah #62688 & #64005.
+.als @break-page bp
+.de bp
+.  nr @saved-no-space-mode \\n[.ns]
+.  rs
+.  ie \\n[.br] '@break-page \\$1
+.  el  .@break-page \\$1
+.  if \\n[@saved-no-space-mode] .ns
+.  rr @saved-no-space-mode
+..
+.

In the groff_book the documentation of the .br register has this code
snippet:-

.als bp*orig bp
.de bp
. tm before bp
. ie \\n[.br] .bp*orig
. el ’bp*orig
. tm after bp
..

Very similar, but the break/non-break versions of bp are round the other way.
This seems to cause a problem:-

[derij@pip build (jpeg)]$ printf "
What is Lorem Ipsum?

Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's standard dummy text ever since the 1500s,
when an unknown printer took a galley of type and scrambled it to make a type
specimen book. It has survived not only five centuries, but also the leap into
electronic typesetting, remaining essentially unchanged. It was popularised in
the 1960s with the release of Letraset sheets containing Lorem Ipsum passages,
and more recently with desktop publishing software like Aldus PageMaker.
.bp\nPage 2"|groff -ms -a

Results in:-


What is Lorem Ipsum?
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Lorem Ipsum has been the industry's
standard dummy text ever since the 1500s, when an unknown printer took a
galley of type and scrambled it to make
a type specimen book. It has survived not only five centuries, but also the
leap into electronic typesetting, remaining
essentially unchanged. It was popularised in the 1960s with the release of
Letraset sheets containing Lorem Ipsum
  

 -2- 
passages, and more recently with desktop publishing software like Aldus
PageMaker. Page 2

The partial line ending in "Aldus PageMaker" should be on page 1, it isn't. I
have not looked at the regression test associated with this bug, but it does
not seem to detect this issue.


___

Reply to this item at:

  

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

[groff] 01/01: [gropdf] Deal better with invalid destination names.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit b8038971a3cc51cd3981af49092dbdb493f76c06
Author: Deri James 
AuthorDate: Sat May 25 13:40:21 2024 +0100

[gropdf] Deal better with invalid destination names.

Bookmark destinations (supplied by -T to .pdfbookmark)
are "Name Objects" in pdf terms, as such they are limited
to characters in the range 33 (!) to 126 (~). Characters
outside this range must be coded as a # followed by the
2 digit hex number. So a space character should be '#20'.

Gropdf produces pdfs which conform to this rule, but the
pdf parser (used to import pdfs for pdfpic) expects only
valid syntax. To convert pdfmark input to a pdf object
gropdf used this inbuilt parser.

The .TH macro in an.tmac passes its first parameter as a
bookmark destination. Normally this is fine, since the
convention is that this will be the name of the program
the man page is documenting. The problem in this case
is the line:-

.TH "Pamaltsat User Manual" 0 "14 September 2018"
"netpbm documentation"

The first parameter contains spaces, which yields invalid
syntax when parsed as "/Dest /Pamaltsat User Manual(0)".

* src/devices/gropdf/gropdf: Don't use internal parser
on "user" supplied input, be a bit more careful.

Fixes: https://savannah.gnu.org/bugs/?65788

Thanks to Bjarni for the report.
---
 ChangeLog| 36 
 src/devices/gropdf/gropdf.pl | 15 ---
 2 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e978a25dd..2d68c60e5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,39 @@
+2024-05-25  Deri James  
+
+   [gropdf] Deal better with invalid destination names.
+
+   Bookmark destinations (supplied by -T to .pdfbookmark)
+   are "Name Objects" in pdf terms, as such they are limited
+   to characters in the range 33 (!) to 126 (~). Characters
+   outside this range must be coded as a # followed by the
+   2 digit hex number. So a space character should be '#20'.
+
+   Gropdf produces pdfs which conform to this rule, but the
+   pdf parser (used to import pdfs for pdfpic) expects only
+   valid syntax. To convert pdfmark input to a pdf object
+   gropdf used this inbuilt parser.
+
+   The .TH macro in an.tmac passes its first parameter as a
+   bookmark destination. Normally this is fine, since the
+   convention is that this will be the name of the program
+   the man page is documenting. The problem in this case
+   is the line:-
+
+   .TH "Pamaltsat User Manual" 0 "14 September 2018"
+   "netpbm documentation"
+
+   The first parameter contains spaces, which yields invalid
+   syntax when parsed as "/Dest /Pamaltsat User Manual(0)".
+
+   * src/devices/gropdf/gropdf: Don't use internal parser
+   on "user" supplied input, be a bit more careful.
+
+   Fixes:-
+
+   https://savannah.gnu.org/bugs/?65788
+
+   Thanks to Bjarni for the report.
+
 2024-05-14  Deri James  
 
[gropdf] Problem if mixed fonts have different lenIV.
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 30a8de868..df645c4e0 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -1465,11 +1465,12 @@ sub do_x
$cat->{$k}=$docview->{$k} if !exists($cat->{$k});
}
}
-   elsif ($pdfmark=~m/(.+) \/DEST\s*$/)
+   elsif ($pdfmark=~m/\/Dest (\/.+?)( \/View .+) \/DEST\s*$/)
{
-   my @xwds=split(' ',"<< $1 >>");
+   my (@d)=($1,$2);
+   my @xwds=split(' ',"<< $d[1] >>");
my $dest=ParsePDFValue(\@xwds);
-   $dest->{Dest}=UTFName($dest->{Dest});
+   $dest->{Dest}=UTFName($d[0]);
$dest->{View}->[1]=GraphY($dest->{View}->[1]*-1);
unshift(@{$dest->{View}},"$cpageno 0 R");
 
@@ -1504,14 +1505,14 @@ sub do_x
my $t=$1;
$t=~s/\\\) /\) /g;
$t=~s/\\e//g;
-   $t=~m/(^.*\/Title \()(.*)(\).*)/;
-   my ($pre,$title,$post)=($1,$2,$3);
+   $t=~m/^\/Dest (.+?) \/Title \((.*)(\).*)/;
+   my ($d,$title,$post)=($1,$2,$3);
$title=utf16($title);
 
$title="\\134" if $title eq "\\";
-   my @xwds=split(' ',"<< $pre$title$post >>");
+   my @xwds=split(' ',"<< \/Title ($title$post >

[bug #65788] gropdf: warning: PDF Dict Key 'User' does not start with '/'

[Deri James]

Update of bug #65788 (group groff):

  Status:None => Fixed  
 Assigned to:None => deri   

___

Follow-up Comment #1:


commit b8038971a3cc51cd3981af49092dbdb493f76c06 (HEAD -> master)
Author: Deri James 
Date:   Sat May 25 13:40:21 2024 +0100

[gropdf] Deal better with invalid destination names.

Bookmark destinations (supplied by -T to .pdfbookmark)
are "Name Objects" in pdf terms, as such they are limited
to characters in the range 33 (!) to 126 (~). Characters
outside this range must be coded as a # followed by the
2 digit hex number. So a space character should be '#20'.

Gropdf produces pdfs which conform to this rule, but the
pdf parser (used to import pdfs for pdfpic) expects only
valid syntax. To convert pdfmark input to a pdf object
gropdf used this inbuilt parser.

The .TH macro in an.tmac passes its first parameter as a
bookmark destination. Normally this is fine, since the
convention is that this will be the name of the program
the man page is documenting. The problem in this case
is the line:-

.TH "Pamaltsat User Manual" 0 "14 September 2018"
"netpbm documentation"

The first parameter contains spaces, which yields invalid
syntax when parsed as "/Dest /Pamaltsat User Manual(0)".

* src/devices/gropdf/gropdf: Don't use internal parser
on "user" supplied input, be a bit more careful.

Fixes: https://savannah.gnu.org/bugs/?65788

Thanks to Bjarni for the report.

There are a few other issues with this man page, such as an invalid . TS/TE
tbl, but these are more to do with the conversion from html to man, rather
than gropdf.


___

Reply to this item at:

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

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

[groff] 01/01: [gropdf] Problem if mixed fonts have different lenIV.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 4c62e07f364957be83fe9fe46151a9edb544a34c
Author: Deri James 
AuthorDate: Fri May 17 17:48:55 2024 +0100

[gropdf] Problem if mixed fonts have different lenIV.

* src/devices/gropdf/gropdf: Restore default value (4) for
each font in case custom value used by previous font. Slight
change to pattern matches.
---
 ChangeLog| 8 
 src/devices/gropdf/gropdf.pl | 9 +
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 64ffb4231..e978a25dd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-14  Deri James  
+
+   [gropdf] Problem if mixed fonts have different lenIV.
+
+   * src/devices/gropdf/gropdf: Restore default value (4) for
+   each font in case custom value used by previous font. Slight
+   change to pattern matches.
+
 2024-05-14  Deri James  
 
[gropdf] \X'pdf: xrev' has issues.
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 74d32a5d7..30a8de868 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -747,6 +747,7 @@ foreach my $fontno (sort keys %fontlst)
 
($head,$body,$tail)=GetType1($fnt->{fontfile});
$head=~s/\/Encoding \d.*?readonly def\b/\/Encoding StandardEncoding 
def/s;
+   $lenIV=4;
 
if ($options & SUBSET)
{
@@ -4617,15 +4618,15 @@ sub map_subrs
$RDre=qr/\Q$RD\E/;
$NDre=qr/\Q$ND\E/;
}
-   elsif ($lin=~m/^\/(.+?)\s+\{string currentfile exch readstring 
pop\}\s*executeonly def/)
+   elsif ($lin=~m/^\/(.+?)\s*\{string currentfile exch readstring 
pop\}\s*executeonly def/)
{
$RD=$1;
}
-   elsif ($lin=~m/^\/(.+?)\s+\{noaccess def\}\s*executeonly def/)
+   elsif ($lin=~m/^\/(.+?)\s*\{noaccess def\}\s*executeonly def/)
{
$ND=$1;
}
-   elsif ($lin=~m/^\/(.+?)\s+\{noaccess put\}\s*executeonly def/)
+   elsif ($lin=~m/^\/(.+?)\s*\{noaccess put\}\s*executeonly def/)
{
$NP=$1;
}
@@ -4873,7 +4874,7 @@ sub MarkSub
 }
 else
 {
-   Log(1,"Missing Subrs '$k'");
+   Warn("Missing Subrs '$k'");
 }
 }
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

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

I have been investigating the AFMs Branden found with a view to using them as
a way to recreate the grops fonts, particularly in situations where there have
been changes to the maps, encoding files and afmtodit itself. Since the last
release afmtodit, and dingbats map have been altered, and the grops fonts have
been hand edited by me to add the UTF-16 code as a comment. Afmtodit is to be
changed soon to add the new spacewidth algorithm and improvements to the font
comments.

For all these reasons it would be convenient to have an automated procedure
which generates the grops fonts. The attached grops-fonts-AFMs.tar.gz has
everything required to do this. It contains the afms from the
Adobe-Core35_AFMs-229.tar.gz from CTAN, with one change, the Symbol.afm has
been replaced with symbol.afm from the git grops directory, since I suspect
this has been edited to work best with eqn. Investigation showed that the
original Symbol.afm from the 229 tar.gz produced different italic corrections,
whereas the copy from the grops directory produces identical results.

All the AFMs have had the ellipsis kerning lines added, (see script
EllipsisFix.sh - a blatant rip off from Daves code in bug #58897 - except it
now operates on the KPX lines in the AFM files, so no need to run it again,
but left in place to show what was done).

The script BuildPSfonts.pl runs afmtodit with the correct parameters. It takes
4 parameters:-

BuildPSfonts.pl [-F font-directory] [-map directory-with-map-files] [-enc
directory-with-enc-files] [-afm directory-with-afm-files]

>From the build directory I ran it with this parameter:-

./BuildPSfonts.pl -F ./devps -enc ../font/devps -map ../font/devps/generate
-afm grops-fonts-AFMs

Note I used a separate directory for the new fonts so I could then compare
them with the current files for checking.

When you check the results you will notice a few differences:-

The final glyph in each file has a different UTF-16 comment, the new versions
are correct, mistake in my hand editing when I committed them, the new
generated files are correct.

In some fonts there is one case where the position of the ellipsis and period
kern lines are swapped, this has no effect, it happens when afmtodit is
processing a glyph alias (i.e. when two groff names refer to the same glyph,
contains just a name and a " in the font entry. In this case generates two
kern entries and sorts them alphabetically. Dave's sed script which added an
epsilon kern after each '.' kern, so the order would be like this:-

. rq -70
u2026 rq -70
. ' -70
u2026 ' -70

Whereas afmtodit sorts the kern list alphabetically so it becomes:-

. rq -70
. ' -70
u2026 rq -70
u2026 ' -70

This has no effect.

The S font has the most changes. There is a new glyph Upsilon which is not in
the current font, and it is given the groff name "u03A5" rather than *U,which
is assigned to 03D2 "GREEK UPSILON WITH HOOK SYMBOL", so I don't think this
will cause an issue. The rest of the difference are all to do with the comment
field and have no effect.

The SS font is a problem. There is a file called symbolsl.afm in the devps
directory which one could reasonably assume was used to produce the SS file
via afmtodit. However, if you look at the file you will see it has problems:-

C 33 ; WX 333 ; N exclam ; B 128 -13 240 686 ;

The width is shown as 333, but this produces:-

--- 296,598,15,137,-73,99   3   33  exclam

Where the width is now 296 (=333*.89) and the height goes from 673 (686-13) to
598 (=673*.89). The .89 factor is from the transformation applied to the
normal symbol file in the file symbolsl.ps:-

%%IncludeResource: font Symbol

/Symbol-Slanted
[.89 0.0 15.5 dup sin exch cos div .89 0.0 0.0]
/Symbol
MakeTransformedFont

Which seems to be a zoom factor plus either a rotate or shear transformation
(my maths is not up to it). I was 17 before I had my first proper maths
lesson, the benefits of going to a school where you are not expected to be
academic. :-)

So I don't think we can faithfully reproduce the SS font from source files,
unless someone is mathematical enough to apply a transformation to the llx,
lly, urx, ury (which defines a rectangle) so if someone can convert the
postscript transformation to a formula which converts the rectangle, we could
add it as an option to afmtodit

Another issue which applies to SS, is that because it is defined in DESC fonts
before the S font and will be searched first, it is important that only the
symbol glyphs we want to become slanted (i.e. lowercase greek for equations)
are named, the rest need to be unnamed (---) so groff will look for them in
the normal symbol font instead. This script does that as well.

I have done a fair bit of work on this, because I think it is important we
have the ability to recreate the grops fonts, but I am now stuck: need help
with the maths outlined above and also guidance on implementing this as a make
target.

(file #56053)

[groff] 01/03: [gropdf] Passing just "\" as a bookmark problem.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 2cf8f41d3f9985da0670ddd2cbc07837d5433299
Author: Deri James 
AuthorDate: Wed May 8 18:39:30 2024 +0100

[gropdf] Passing just "\" as a bookmark problem.

* src/devices/gropdf/gropdf: it ends up as a pdf string "(\)",
which is treated as an escaped bracket and the string is not
terminated! Solution is to embed the "\" in octal notation,
i.e. (\134).
---
 src/devices/gropdf/gropdf.pl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 31a35db4a..800af64c3 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -1507,6 +1507,7 @@ sub do_x
my ($pre,$title,$post)=($1,$2,$3);
$title=utf16($title);
 
+   $title="\\134" if $title eq "\\";
my @xwds=split(' ',"<< $pre$title$post >>");
my $out=ParsePDFValue(\@xwds);
$out->{Dest}=UTFName($out->{Dest});

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 03/03: Forgot to push last two fixes.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit d998339bef8af990cca00b2b0a9939cc9fc2e7cf
Author: Deri James 
AuthorDate: Tue May 14 15:43:44 2024 +0100

Forgot to push last two fixes.
---
 ChangeLog | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index aa8814703..64ffb4231 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2024-05-14  Deri James  
+
+   [gropdf] \X'pdf: xrev' has issues.
+
+   * src/devices/gropdf/gropdf: Fails if point size not = 10, in
+   a number of ways.
+
+   * src/devices/gropdf/gropdf.1.man: Clarify exact operation of
+   'xrev'.
+
+2024-05-14  Deri James  
+
+   [gropdf] Passing just "\" as a bookmark problem.
+
+   * src/devices/gropdf/gropdf: it ends up as a pdf string "(\)",
+   which is treated as an escaped bracket and the string is not
+   terminated! Solution is to embed the "\" in octal notation,
+   i.e. (\134).
+
 2024-05-13  G. Branden Robinson 
 
* tmac/an.tmac (EE): Define macro with `de1` request, not `de`.

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 02/03: [gropdf] \X'pdf: xrev' has issues.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 4886b57816841de32c51b88ccffc9580b07bb535
Author: Deri James 
AuthorDate: Wed May 8 22:23:28 2024 +0100

[gropdf] \X'pdf: xrev' has issues.

* src/devices/gropdf/gropdf: Fails if point size not = 10, in
a number of ways.

* src/devices/gropdf/gropdf.1.man: Clarify exact operation of
'xrev'.
---
 src/devices/gropdf/gropdf.1.man |  6 ++
 src/devices/gropdf/gropdf.pl| 12 +++-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/devices/gropdf/gropdf.1.man b/src/devices/gropdf/gropdf.1.man
index cc1971858..04e5799a5 100644
--- a/src/devices/gropdf/gropdf.1.man
+++ b/src/devices/gropdf/gropdf.1.man
@@ -977,10 +977,8 @@ height.
 .B \[rs]X\[aq]pdf: xrev\[aq]
 Toggle the reversal of glyph direction.
 .
-This feature works \[lq]letter by letter\[rq],
-that is,
-each letter in a word is reversed left-to-right,
-not the entire word.
+This feature works by reversing all following text.
+Each separate letter is also mirrored.
 .
 One application is the reversal of glyphs in the Zapf Dingbats font.
 .
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 800af64c3..74d32a5d7 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -4088,11 +4088,11 @@ sub PutLine
 my $len=0;
 my $rev=0;
 
-if (($lin[0]->[CHR]||0) < 0)
+if ($xrev)
 {
-   $len=($lin[$#lin]->[XPOS]-$lin[0]->[XPOS]+$lin[$#lin]->[HWID])*100;
-   $s.=d3($len).' ';
-$rev=1;
+   
$len=($lin[$#lin]->[XPOS]-$lin[0]->[XPOS]+$lin[$#lin]->[HWID])*1000/$cftsz;
+   $s.=d3($len).' ' if $len;
+   $rev=1;
 }
 
 $stream.="%! wht0sz=".d3($whtsz/$unitwidth).", 
wt=".((defined($wt))?d3($wt/$unitwidth):'--')."\n" if $debug;
@@ -4157,7 +4157,7 @@ sub PutLine
if ($rev)
{
$s.=') ' if !$n;
-   $s.=d3(($c->[CWID]-$c->[HWID])*100).' (';
+   $s.=d3(($c->[CWID]-$c->[HWID])*1000/$cftsz).' (';
$n=0;
}
 
@@ -4331,11 +4331,13 @@ sub PutGlyph
{
MakeMatrix(1);
$inxrev=1;
+   $#lin=-1;
}
elsif ($inxrev and $cn > 0)
{
MakeMatrix(0);
$inxrev=0;
+   $#lin=-1;
}
 
if ($matrixchg or $poschg)

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

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

Dave.

I think the implied question is: When it is a separate make target (bug
#65698), if we wish to retain the epsilon kerns the make target must either
re-apply the shell script after the font generation, or these "gold" AFMs
should have the extra kerns added once before we pour aspic on them. The make
targe then gets run whenever afmtodit, the maps, or the encoding files, are
altered.

As far as I can tell the "slant" parameter does nothing for composite (e.g. a
glyph plus an accent glyph on top of each other) placement. What it does do is
affect both italic correction factors and the subscript correction, i.e. when
a font switches from roman to italic for example.

Branden.

You piqued my curiosity about Hungarian umlauts, so I took a peak at the list
archives. :-)

There are two issues with Gergő's predicament. His package was built with no
URW fonts whatsoever, even though the required fonts are sitting in
/usr/share/fonts/Type1/ as can be seen in the list of files supplied to Alex.
I know this because the pdf he supplied had absolutely no embedded fonts in
it, so if you cast your mind back to the games played with the URW font
detection during configure, he has the setup where only the base 14 pdf fonts
would be available (without warnings about missing fonts). The placement of
the umlauts is because the standard fonts lack the four individual glyphs, so
groff sends a composite:-

wx font 5 TR
f5
h13750
Ca"
to
wh13750
Ca"
tO
wh13750
Ca"
tu
wh13750
Ca"
tU

Where the U- foundry fonts have separate glyphs:-

wx font 42 U-TR
f42
h13750
Cu006F_030B
wh41250
Cu004F_030B
wh53460
Cu0075_030B
wh41250
Cu0055_030B

In the attached pdf you can see that in the U- fonts the height of the umlaut
is fitted to the height of the letter, since the glyph is custom designed. It
is always better to use a single glyph rather than composing a compose. I did
send him some information how to access those URW fonts by just replacing the
TR, TI... With 4 custom versions, but it was just an email, since I am no
longer on the list, so it may get filed as "junk".

Also, because of the big pointsize, it is easier to see what is happening. In
TI and TBI you can see the umlaut is slightly shifted to the right, this has
nothing to do with "slant" it is just an artifact of the probable
transformation applied to TR to arrive at TI when the font was designed.

(file #56036)

___

Additional Item Attachment:

File name: umlautTimes.pdfSize: 27KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-0329bc976c56c39d462c6cc5223a9b3c843a6486.tar.gz


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

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

I have been investigating the AFMs contained in the tar files Branden
referenced in comment #15. Using the 229 versions it is possible to generate
the 35 fonts for grops. The only difference is that our fonts include kerning
data for the ellipsis font which is not included in the AFMs, because commit
81b4ffadc1ced modified the files via a shell script to duplicate the full stop
kerning information to ellipsis.

I have only tested the TR and TI fonts and I used the following afmtodit
commands:-

./afmtodit -c -i0 -m -e ../font/devps/text.enc
Adobe-Core35_AFMs-229/Times-Roman.afm font/devpdf/map/text.map DJTR

./afmtodit -c -i50 -a7 -e ../font/devps/text.enc
Adobe-Core35_AFMs-229/Times-Italic.afm font/devpdf/map/text.map DJTI

For italic fonts you need to ensure that the "slant" value (-a) matches the
value used previously, (in case of Times-Italic the AFM has an Italic Angle of
15.5, but the groff font was clearly produced with a slant of 7, i.e. it was
overridden with the -a flag). I don't know why this was done, it is the only
one with such an override:-

ABI:slant 10.5  ITCAvantGarde-BookOblique.afm:ItalicAngle -10.5
AI:slant 10.5   ITCAvantGarde-DemiOblique.afm:ItalicAngle -10.5
BMBI:slant 10   ITCBookman-DemiItalic.afm:ItalicAngle -10
BMI:slant 10ITCBookman-LightItalic.afm:ItalicAngle -10
CBI:slant 11Courier-BoldOblique.afm:ItalicAngle -11
CI:slant 11 Courier-Oblique.afm:ItalicAngle -11
HBI:slant 12Helvetica-BoldOblique.afm:ItalicAngle -12
HI:slant 12 Helvetica-Oblique.afm:ItalicAngle -12
HNBI:slant 12   Helvetica-NarrowBoldOblique.afm:ItalicAngle -12
HNI:slant 12Helvetica-NarrowOblique.afm:ItalicAngle -12
NBI:slant 16NewCenturySchlbk-BoldItalic.afm:ItalicAngle -16
NI:slant 16 NewCenturySchlbk-Italic.afm:ItalicAngle -16
PBI:slant 10Palatino-BoldItalic.afm:ItalicAngle -10
PI:slant 10 Palatino-Italic.afm:ItalicAngle -10
SS:slant 15.5   (S font with 15.5 degree transformation)
TBI:slant 15Times-BoldItalic.afm:ItalicAngle -15
TI:slant 7  Times-Italic.afm:ItalicAngle -15.5
ZCMI:slant 14   ITCZapfChancery-MediumItalic.afm:ItalicAngle -14

Maybe some people on the list may know.

It is a good thing Branden found the AFMs since the conversion from afm to a
groff font is not completely reversible.


___

Reply to this item at:

  

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

[bug #65716] We don't seem to be using the "latest" glyphlist.txt to generate the tables for afmtodit.

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65716>

 Summary: We don't seem to be using the "latest" glyphlist.txt
to generate the tables for afmtodit.
   Group: GNU roff
   Submitter: deri
   Submitted: Wed 08 May 2024 11:47:44 PM UTC
Category: Utilities
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Wed 08 May 2024 11:47:44 PM UTC By: Deri James 
As an example current glyphlist.txt has:-

bqsquare;33C3
braceex;F8F4
braceleft;007B

but our afmtodit.tables file has:-

  "bqsquare", "33C3",
  "braceleft", "007B",

"braceex" is missing. (300+ lines missing). Is there a reason for this? It
seems to have been created 2022-10-09 which is later than the last change to
glyphlist.txt. I have been writing a little tool to document the glyph
properties of the fonts we deliver with groff. The braceex is used in our S
font (see the "Private Use Area" unicode block in S.pdf).
 






___
File Attachments:


---
Name: S.pdf  Size: 47KiB
<https://file.savannah.gnu.org/file/S.pdf?file_id=56028>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-bb6ac47258d6ad8e166786c81860d8aedf63a25a.tar.gz

___

Reply to this item at:

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

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

Follow-up Comment #22, bug #63018 (group groff):

Speaking about afmtodit only.

If vintage afm files are not forthcoming, then (2 - makefile target) is moot.

Only (1) is not dependent and that will be done when I rejig afmtodit to:-

Look for different 'spaces' to set 'spacewidth'.
Implement -ww switch - force even if 'space' found.
Warn if -w used and 'space' found (but advise rerun with -ww to override).
Document if -w or -ww used in font header comments.

But this already has its own bug #65659 which is assigned to me and I'm doing
font research.


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

Follow-up Comment #20, bug #63018 (group groff):

This might be a bit previous! Whether we should regenerate the grops font
files is rather dependent on whether Branden is successful in locating afm
files of a suitable vintage so that running current afmtodit will generate
fonts with compatible meta-data capable of duplicating existing documents.

The problem is shown in https://savannah.gnu.org/bugs/?63018#comment14


___

Reply to this item at:

  

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

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

Follow-up Comment #17, bug #63018 (group groff):

It is a bit moot now. If Branden does have the original afms for the grops
fonts, which produce identical meta-data as currently, then much better to run
afmtodit on all of them as a refresh.


___

Reply to this item at:

  

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

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

[Deri James]

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

[comment #34 comment #34:]
> > > 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).
> 
> This isn't a matter of my subjective opinion; the "family" and "style"
features of _groff_ date back to 1990.
> 
>
https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.115?h=1.23.0#n5535
> 
> There is a long AT _troff_ hangover of assuming that `R`, `I`, and `B`
fonts will exist (or, in _groff_, that abstract styles that work analogously
to fonts of those names will).  This assumption can extend to `S` as well. 

I don't dispute R, I, B, and BI is a family, it's not the only possible
family, previously a font family of just R and B would be happily accepted and
\fBword\fP worked as expected. It was your code which insisted on a far more
inflexible rule.

[...]

> > 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.
> 
> Yes.  I find this troublesome.
> 
> It seems to be an idiom to use the output comparison operator (a term I had
to coin, for it had no name) for string comparisons even when there is no
intention of formatting either of the comparands as text.
> 
> But that idiom would seem to port poorly to document environments where the
basic Latin alphabet doesn't need to be formatted at all.
> 
> > 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.
> 
> You paid better attention than I did.  I managed to overlook it, staring
more closely at the 1.23.0 output, seeing only the character sequence
"psaciltnufhm", and deducing nothing much in particular from that.
> 
> Good sleuthing!
> 
> But also there's no way in hell we should be spewing diagnostics on, or
failing to correctly perform comparisons within, control structures that are
initializing the state of the formatter.  These macro files are profoundly
uninterested in formatting any output, and they'd be buggy if they did so,
since an empty input document should produce no output no matter what (stock)
macro packages or startup macro files you load.
> 
> Maybe it is time for a proper string equality operator in our conditional
expressions.

Ooh, yes please.

> > 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.
> 
> Fair point.
>  
> > 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.
> 
> Here, I must disagree.  The foregoing strikes me as a workaround rather than
a proper fix.

I agree, it's a workaround, but it is also a proper fix in the sense that it
prevented Dave's errors appearing for non-latin fonts, which you agreed your
code did not (so was not a proper fix).

[...]

> A string equality test.  Not a comparison of node lists, which are laden
with all sorts of other data.[1]  Just a string equality test.
> 
> Well, let's give the people what they are asking for.  Especially since a
lot of the time, "the people" is us.

+1 here, that would be a proper fix too. What semantics are you considering
for this new conditional?

> [1] Now that I've started resurrecting and expanding the formatter's
facilities for node dumping, I'm getting a better notion of what all that
extra data is.  I begin to revise upward my expectations of the performance
improvement I can expect from a straight-up simple string equality operator,
particularly since the operation can be handed off to the C++ standard library
and from there, likely to platform-specific, optimized assembly code.  It
hasn't escaped me that this might also help, say, string comparisons of PDF
bookmark tags, since they too are not output to be formatted.

I liked .pline.



___

Reply to this item at:

  

___
Message sent via Savannah

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

[Deri James]

Follow-up Comment #14, bug #63018 (group groff):

[comment #9 comment #9:]
> Hi Dave,
> 
> [comment #8 comment #8:]
> > To clarify: my objection isn't the stale afmtodit version 
> 
> It is nevertheless a legitimate one.  We should be dogfooding the font
description files that _afmtodit_ generates.
> 
> We also should not be advertising a file as automatically generated when it
was hand-crafted.
> 
> > (I doubt refreshing the file will change the data),
> 
> If you mean re-running it as of _groff_ 1.23.0 or recent Git, I agree:
probably not.
> 
> > but that the line claims afmtodit generated it at all: once Deri's ZD is
committed, precious little of its content will be from afmtodit.
> 
> I understood Deri as proposing to update "dingbats.map" _and_ regenerating
the ZD file using _afmtodit_ with it...
> 
> [comment #5 comment #5:]
> > Probably the best way of doing this is by adding to dingbats.map, a
suitable one is attached (to replace the one in font/devps/generate).  Also
attached is a replacement ZD file to be placed in fonts/devps.
> 
> ...hence the characterization of the "ZD" file as supplementary; I assume it
was a demonstrator and/or a convenience for people who didn't want to fiddle
with coming up with an _afmtodit_ command invocation themselves.
> 
> > Doing make will propagate the changes to devpdf and when U-ZD is created
it will use the new dingbats.map.
> 
> This matches my understanding.
There is a slight wrinkle with this. Although we have the groff font files for
devps, we don't have the original pfa and afm files which were used to
generate those files. If we use the current generation of URW fonts, as the
U-foundry in devpdf does, you will see differences between what is produced
now, with current .afm files and afmtodit, and what was produced when the
original grops fonts were created.

You can see the difference between the two fonts TR (original grops file) and
U-TR produced from latest afm file. Depending on which particular version of
the URW fonts you have installed will affect your results, but on the version
I have installed the original (copied from grops) has under 300 kernpairs
defined but U-TR has about 4200. The actual glyph widths are largely the same,
but the difference in the kerning data may make a difference in output.

I did a little test, using the U-foundry fonts to generate the
groff_man_pages.pdf, and differences are not hard to spot, see the two screen
shots. For this reason I don't think it is a good idea to refresh the original
font files or everyone's documents will change slightly from what used to be
produced. It may annoy a lot of users who have crafted a document to be
"perfect" typographically (in their eyes) but will not appear again with such
perfection. This was the reason I have the U-foundry in devpdf, you can choose
if you want the traditional spacing or latest (which is not guaranteed to stay
the same between versions because they are generated as part of the build),
and having static groff font files makes checking for regressions between
versions slightly easier.

As regards whether to describe my new ZD file as handcrafted or generated, it
is of course, both. For the reasons given above, I consider it important to
retain the traditional spacing in our stock fonts, so all the columns except
the first are from the original afmtodit, as documented in the header, the
name column has been updated with the groff unicode names, which is what would
have happened if the current dingbats.map was used for the original run when
ZD was first created. I'm quite happy to put something in the header like
"unicode names added by Deri 2024", but I certainly would not suggest removing
the afmtodit header which documents the version used, since that is the
program which calculated the font meta-data, not me!

To try to clarify. The ZD file is not a demonstrator, it carefully preserves
the original font meta-data adding the unicode name instead of "---". As to
whether refreshing the file would alter the meta-data, the answer is yes,
about 80 percent of the glyphs have different values for the meta-data.
Admittedly the differences are very small umbers, and may not be noticeable
unless someone is using a program to compare differences in the pdfs produced,
but I would not want to put hand on heart to say there are NO differences
since the values are changed for so many glyphs, which is why I made the
effort to preserve the original meta-data rather than simply regenerate the
font.

(file #56004, file #56005)

___

Additional Item Attachment:

File name: grog_TR.pngSize: 33KiB
<https://file.savannah.gnu.org/file/grog_TR.png?file_id=56004>

File name: grog_U-TR.png  Size: 36KiB
<https://file.savannah.gnu.org/file/grog

[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 #65619] [afmtodit] want a default value for space width if unspecified

[Deri James]

Follow-up Comment #3, bug #65619 (group groff):

Afmtodit has always used the width of the space glyph (if defined in the
font), what your change did was enable this to be overridden on the command
line, which is probably wrong. If the intention was to provide a fallback
value when a spacewidth was not present, the logic could have been written
that way.

A useful change to afmtodit would be to look for other space glyphs in the
font (u0020 and u00A0) if space is not found, then if none are found, use the
value given on the command line, and if that is missing, it is not a special
font, warn user the font will be unusable in groff and suggest they rerun
afmtodit with a suitable -w flag.

This was Branden's change:-

+my $sw = 0;
+$sw = conv($width{"space"}) if defined $width{"space"};
+$sw = $space_width if ($space_width);
+
 print("name $name\n");
 print("internalname $psname\n") if $psname;
 print("special\n") if $opt_s;
 printf("slant %g\n", $italic_angle) if $italic_angle != 0;
-printf("spacewidth %d\n", conv($width{"space"})) if defined $width{"space"};
+printf("spacewidth %d\n", $sw) if $sw;




___

Reply to this item at:

  

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

[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[Deri James]

Follow-up Comment #5, bug #65601 (group groff):


> It would help if you didn't assume autocratic motives behind my code
changes.

But I'm unsure how to achieve that. By autocratic I am simply meaning that you
seem to assume that your ideas are automatically better than your inferiors.
In this bug for example, I initially gave you a one liner which illustrated
the problem:-

xzcat /usr/share/man/man7/iso_8859-6.7.xz |preconv|nroff -Tutf8 -man -t -z

Then, over 2 weeks later, you post more than 1200 words, essentially defending
your change. What am I to think? You know that if you "snow" me under with
words I will either give up or make myself ill trying to answer all your
points. I know you are not stupid so you must have run the example and seen
the errors it produced, but your reply was "no I am right to make this
change". I hope you see my point that this behaviour seems autocratic. I had
to simplify the one liner for you to see the issue, but you then insist that
what you did was correct in some way, but you would undo it anyway.

Unfortunately, there are other examples of autocratic behaviour. How about
taking advantage of my sabbatical to introduce a change to pdf.tmac which not
only had bugs in it, but caused one job to go from a few seconds to 13
minutes. A reasonable person would consult the author of pdf.tmac after his
sabbatical, an autocrat would just go and do it.

Even something as innocuous as spacewidth in afmtodit yields examples. Rather
than something like "I agree with Deri" or "Deri is correct", we see "Looks
like Deri is right", which could be construed as adding an element of
surprise! And, I agree, I am skating on thin ice here, because we are
considering autocratic behaviour, and mere words add nought, to the scales, it
just may be indicative of the mind set which accompanies autocratic
behaviour.




___

Reply to this item at:

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

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

[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[Deri James]

Update of bug #65601 (group groff):

  Status:   Need Info => Confirmed  

___

Follow-up Comment #3:

It is very simple!

[derij@pip build (master)]$ echo "This is the arabic alef with a madda above
-> آ"|groff -Tutf8 -Kutf8 -z
troff::1: error: cannot format glyph: 'u0627_0653' is not a
valid composite character

It is no longer possible to output this particular utf-8 character (along with
hundreds of others), all perfectly valid utf-8 to the utf-8 device. I can't
believe that is your intention, to police which particular parts of unicode
are acceptable to you.

Just in case the character in the above example gets mangled by savannah,
here's the equivalent:-

[derij@pip build (master)]$ echo "This is the arabic alef with a madda above
-> \[u0622]"|groff -Tutf8 -z
troff::1: error: cannot format glyph: 'u0627_0653' is not a
valid composite character

I hope this gives you enough information to fix this bug.


___

Reply to this item at:

  

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

[groff] 01/01: [gropdf] Re-arrange pattern matches.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit a951b44fd9d2acf060067b24c994604351a27888
Author: Deri James 
AuthorDate: Tue Apr 30 15:25:49 2024 +0100

[gropdf] Re-arrange pattern matches.

* src/devices/gropdf/gropdf.pl: Correct order of pattern
match.

Fixes https://savannah.gnu.org/bugs/?65585 (again!)
---
 ChangeLog| 9 +
 src/devices/gropdf/gropdf.pl | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index bb8fc9fb1..c947229d3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2024-04-24  Deri James  
+
+   [gropdf] Re-arrange pattern matches.
+
+   * src/devices/gropdf/gropdf.pl: Correct order of pattern
+   match.
+
+   Fixes https://savannah.gnu.org/bugs/?65585 (again!)
+
 2024-04-30  Christof Meerwald 
 
* src/devices/gropdf/gropdf.pl: Call PDFDate with the output of
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 1656db821..31a35db4a 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -1983,6 +1983,7 @@ sub Clean
 my $p=shift;
 
 $p=~s/\\c?$//g;
+$p=~s/\\[eE]/\\/g;
 $p=~s/\\[ 0~t]/ /g;
 $p=~s/\\[,!"#\$%&’.0:?{}ˆ_‘|^prud]//g;
 $p=~s/\\'/\\[aa]/g;
@@ -1992,8 +1993,8 @@ sub Clean
 
 $p=~s/\\[Oz].//g;
 $p=~s/\\[ABbDHlLoRSvwXZ]$parcln//g;
-$p=~s/\\[hs][-+]?$parclntyp//g;
 $p=~s/\\[FfgkMmnVY]$parclntyp//g;
+$p=~s/\\[hs][-+]?$parclntyp//g;
 
 $p=~s/\\\((\w\w)/\\\[$1\]/g;   # convert \(xx to \[xx]
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

[Deri James]

Follow-up Comment #5, bug #63018 (group groff):

Probably the best way of doing this is by adding to dingbats.map, a suitable
one is attached (to replace the one in font/devps/generate). Also attached is
a replacement ZD file to be placed in fonts/devps. Doing make will propagate
the changes to devpdf and when U-ZD is created it will use the new
dingbats.map.

The attached .trf file includes all the characters in the unicode 2700 code
page (see U2700.pdf). When you run it you will see that some code points are
missing from the font, this probably because the font was created before
unicode and there have been numerous changes.

ZDR is a different kettle of fish! It does not make sense reversing many of
the glyphs, and they would not have unicodes anyway. We currently only have
one entry in reversed-dingbats.map, for \[lh]. For gropdf we have it defined
in pdf.tmac as:-

.char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'


(file #55989, file #55990, file #55991, file #55992)

___

Additional Item Attachment:

File name: ZD Size: 6KiB


File name: dingtst.trfSize: 1KiB


File name: dingbats.map   Size: 2KiB


File name: dingtst.pdfSize: 49KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-02a92bc3de37203138822bd2520e89ef55345685.tar.gz


___

Reply to this item at:

  

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

[groff] 01/01: [gropdf] ignore 'Cspace' as input

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 1ab868c5c84a02f32ab2c385066215d2aa7d650b
Author: Deri James 
AuthorDate: Sun Apr 28 18:03:59 2024 +0100

[gropdf] ignore 'Cspace' as input

* src/devices/gropdf/gropdf.pl: As grops does.
---
 ChangeLog| 6 ++
 src/devices/gropdf/gropdf.pl | 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f88d241a4..d8d48e2b2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-04-24  Deri James  
+
+   [gropdf] ignore 'Cspace' as input
+
+   * src/devices/gropdf/gropdf.pl: As grops does.
+
 2024-04-24  Deri James  
 
[gropdf] use nospace mode if font does not contain
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index df61903e4..acf86389f 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -4455,7 +4455,7 @@ sub do_C
 my $par=shift;
 my $fnt=$fontlst{$cft}->{FNT};
 
-PutGlyph($fnt,$par,1);
+PutGlyph($fnt,$par,1) if $par ne 'space';
 }
 
 sub do_c
@@ -4479,7 +4479,7 @@ sub do_N
 }
 
 my $chnm=$fnt->{NO}->[$par];
-PutGlyph($fnt,$chnm,1);
+PutGlyph($fnt,$chnm,1) if $chnm ne 'space';
 }
 
 sub do_n

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/01: [gropdf] use nospace mode if font does not contain /space glyph.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 9e0a3316c7b1f33f22d3b314456b2415cc9856eb
Author: Deri James 
AuthorDate: Sun Apr 28 14:59:05 2024 +0100

[gropdf] use nospace mode if font does not contain
/space glyph.

Gropdf always had two modes, depending on whether the font
defined /space or not (using space could make the pdf
slightly more compact). Some fonts which don't have /space
do have a glyph named /u0020 and the code used that as a
space, however I'm not convinced of the robustness of this
so, now, if a font has no /space then nospace mode is used.

* src/devices/gropdf/gropdf.pl: Always use nospace mode if
font has no /space glyph.
---
 ChangeLog| 15 +++
 src/devices/gropdf/gropdf.pl | 12 +---
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ba4f786e8..f88d241a4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2024-04-24  Deri James  
+
+   [gropdf] use nospace mode if font does not contain
+   /space glyph.
+
+   Gropdf always had two modes, depending on whether the font
+   defined /space or not (using space could make the pdf
+   slightly more compact). Some fonts which don't have /space
+   do have a glyph named /u0020 and the code used that as a
+   space, however I'm not convinced of the robustness of this
+   so, now, if a font has no /space then nospace mode is used.
+
+   * src/devices/gropdf/gropdf.pl: Always use nospace mode if
+   font has no /space glyph.
+
 2024-04-24  Deri James  
 
[gropdf] Can't handle DecodeParams in Deflate filter.
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 7bb1610c2..df61903e4 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -729,7 +729,7 @@ foreach my $fontno (sort keys %fontlst)
 my @fontdesc=();
 my $chars=$fnt->{TRFCHAR};
 my $glyphs='/.notdef';
-$glyphs.='/space' if defined($fnt->{NO}->[32]) and $fnt->{NO}->[32] eq 
'u0020';
+$glyphs.='/space' if defined($fnt->{NO}->[32]) and $fnt->{NO}->[32] eq 
'space';
 my $fobj;
 @glyphused=@subrused=%seac=();
 push(@subrused,'#0','#1','#2','#3','#4');
@@ -783,7 +783,7 @@ foreach my $fontno (sort keys %fontlst)
my @widths;
my $miss=-1;
my $CharSet=join('',@{$fnt->{CHARSET}->[$j]});
-   push(@{$chars->[$j]},'u0020') if $j==0 and 
$fnt->{NAM}->{u0020}->[PSNAME];
+   push(@{$chars->[$j]},'space') if $j==0 and 
$fnt->{NAM}->{space}->[PSNAME];
 
foreach my $og (sort { $nam->{$a}->[MINOR] <=> $nam->{$b}->[MINOR] } 
(@{$chars->[$j]}))
{
@@ -3232,8 +3232,6 @@ sub LoadFont
}
 
$r[3]=oct($r[3]) if substr($r[3],0,1) eq '0';
-   $r[0]='u0020' if $r[3] == 32;
-   $r[0]="u00".hex($r[3]) if $r[0] eq '---';
$r[4]=$r[0] if !defined($r[4]);
$fnt{NAM}->{$r[0]}=[$p[0],$r[3],'/'.$r[4],undef,undef,$r[6]];
$fnt{NO}->[$r[3]]=$r[0];
@@ -3253,8 +3251,8 @@ sub LoadFont
 
 close($f);
 
-$fnt{NAM}->{u0020}->[MINOR]=32;
-$fnt{NAM}->{u0020}->[MAJOR]=0;
+$fnt{NAM}->{space}->[MINOR]=32;
+$fnt{NAM}->{space}->[MAJOR]=0;
 my $fno=0;
 my $slant=0;
 $fnt{DIFF}=[];
@@ -3266,7 +3264,7 @@ sub LoadFont
 $fnt{NAM}->{''}=[0,-1,'/.notdef',-1,0];
 $slant=-$fnt{'slant'} if exists($fnt{'slant'});
 $fnt{slant}=$slant;
-$fnt{nospace}=(!defined($fnt{NAM}->{u0020}->[PSNAME]) or 
$fnt{NAM}->{u0020}->[PSNAME] ne '/space' or !exists($fnt{'spacewidth'}))?1:0;
+$fnt{nospace}=(!defined($fnt{NAM}->{space}->[PSNAME]) or 
$fnt{NAM}->{space}->[PSNAME] ne '/space' or !exists($fnt{'spacewidth'}))?1:0;
 $fnt{'spacewidth'}=270 if !exists($fnt{'spacewidth'});
 Notice("Using nospace mode for font '$ofontnm'") if $fnt{nospace} == 1 and 
$options & USESPACE;
 

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/01: [gropdf] Can't handle DecodeParams in Deflate filter.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 14563f831454bd879f465ac4738624c5e3f380ed
Author: Deri James 
AuthorDate: Sun Apr 28 13:36:31 2024 +0100

[gropdf] Can't handle DecodeParams in Deflate filter.

If gropdf called with -d (debug) the pdf is produced with
objects uncompressed, if object does not use default deflate
parameters Zlib does not decompress properly, so the
decompressed object is invalid. This affects when using a
pdf imported with 'pdfpic' which contains a png image.

This only affects imported pdfs when using the -d flag,
because otherwise it is just passed through with no
decompress.

* src/devices/gropdf/gropdf.pl: Don't decompress if object has
a DecodeParams dictionary.
---
 ChangeLog| 17 +
 src/devices/gropdf/gropdf.pl |  2 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index e1483c5ed..ba4f786e8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2024-04-24  Deri James  
+
+   [gropdf] Can't handle DecodeParams in Deflate filter.
+
+   If gropdf called with -d (debug) the pdf is produced with
+   objects uncompressed, if object does not use default deflate
+   parameters Zlib does not decompress properly, so the
+   decompressed object is invalid. This affects when using a
+   pdf imported with 'pdfpic' which contains a png image.
+
+   This only affects imported pdfs when using the -d flag,
+   because otherwise it is just passed through with no
+   decompress.
+
+   * src/devices/gropdf/gropdf.pl: Don't decompress if object has
+   a DecodeParams dictionary.
+
 2024-04-20  G. Branden Robinson 
 
* tmac/tmac.am ($(M4CHECK)): Ensure directory exists to house
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 59434a8ec..7bb1610c2 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -2577,7 +2577,7 @@ sub LoadStream
 Warn("failed to read all of the stream")
 if $l != sysread(PD,$o->{STREAM},$l);
 
-if ($gotzlib and exists($o->{OBJ}->{'Filter'}) and $o->{OBJ}->{'Filter'} 
eq '/FlateDecode')
+if ($gotzlib and exists($o->{OBJ}->{'Filter'}) and $o->{OBJ}->{'Filter'} 
eq '/FlateDecode' and !exists($o->{OBJ}->{'DecodeParms'}))
 {
$o->{STREAM}=Compress::Zlib::uncompress($o->{STREAM});
delete($o->{OBJ }->{'Filter'});

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

[Deri James]

Follow-up Comment #6, bug #62300 (group groff):

\[u00A0] is meaningful if you are using a font which defines the glyph. (I
appear to have about 67 fonts which define the glyph, some even define kern
pairs for the glyph, and one tibetan font defines composites using it).

Groff does not convert it to a horizontal motion and the font defines
operators for the glyph, which results in a space of a certain width.


___

Reply to this item at:

  

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

[bug #65619] Provide a default value for afmtodit(1) -w, when unspecified

[Deri James]

Follow-up Comment #1, bug #65619 (group groff):

If no -w is given afmtodit uses the width of the space glyph as the value.
This is ideal since this is the value which the font designer has chosen as
most appropriate for particular font. The various values for the URW fonts
are:-

font/devpdf/U-AB:spacewidth 280
font/devpdf/U-AB:space  280
font/devpdf/U-AB:M  900
font/devpdf/U-ABI:spacewidth 280
font/devpdf/U-ABI:space 280
font/devpdf/U-ABI:M 900
font/devpdf/U-AI:spacewidth 277
font/devpdf/U-AI:space  277
font/devpdf/U-AI:M  919
font/devpdf/U-AR:spacewidth 277
font/devpdf/U-AR:space  277
font/devpdf/U-AR:M  919
font/devpdf/U-BMB:spacewidth 340
font/devpdf/U-BMB:space 340
font/devpdf/U-BMB:M 940
font/devpdf/U-BMBI:spacewidth 340
font/devpdf/U-BMBI:space340
font/devpdf/U-BMBI:M860
font/devpdf/U-BMI:spacewidth 300
font/devpdf/U-BMI:space 300
font/devpdf/U-BMI:M 860
font/devpdf/U-BMR:spacewidth 320
font/devpdf/U-BMR:space 320
font/devpdf/U-BMR:M 920
font/devpdf/U-CB:spacewidth 600
font/devpdf/U-CB:space  600
font/devpdf/U-CB:M  600
font/devpdf/U-CBI:spacewidth 600
font/devpdf/U-CBI:space 600
font/devpdf/U-CBI:M 600
font/devpdf/U-CI:spacewidth 600
font/devpdf/U-CI:space  600
font/devpdf/U-CI:M  600
font/devpdf/U-CR:spacewidth 600
font/devpdf/U-CR:space  600
font/devpdf/U-CR:M  600
font/devpdf/U-HB:spacewidth 278
font/devpdf/U-HB:space  278
font/devpdf/U-HB:M  833
font/devpdf/U-HBI:spacewidth 278
font/devpdf/U-HBI:space 278
font/devpdf/U-HBI:M 833
font/devpdf/U-HI:spacewidth 278
font/devpdf/U-HI:space  278
font/devpdf/U-HI:M  833
font/devpdf/U-HNB:spacewidth 228
font/devpdf/U-HNB:space 228
font/devpdf/U-HNB:M 683
font/devpdf/U-HNBI:spacewidth 228
font/devpdf/U-HNBI:space228
font/devpdf/U-HNBI:M683
font/devpdf/U-HNI:spacewidth 228
font/devpdf/U-HNI:space 228
font/devpdf/U-HNI:M 683
font/devpdf/U-HNR:spacewidth 228
font/devpdf/U-HNR:space 228
font/devpdf/U-HNR:M 683
font/devpdf/U-HR:spacewidth 278
font/devpdf/U-HR:space  278
font/devpdf/U-HR:M  833
font/devpdf/U-NB:spacewidth 287
font/devpdf/U-NB:space  287
font/devpdf/U-NB:M  981
font/devpdf/U-NBI:spacewidth 287
font/devpdf/U-NBI:space 287
font/devpdf/U-NBI:M 944
font/devpdf/U-NI:spacewidth 278
font/devpdf/U-NI:space  278
font/devpdf/U-NI:M  944
font/devpdf/U-NR:spacewidth 278
font/devpdf/U-NR:space  278
font/devpdf/U-NR:M  944
font/devpdf/U-PB:spacewidth 250
font/devpdf/U-PB:space  250
font/devpdf/U-PB:M  1000
font/devpdf/U-PBI:spacewidth 250
font/devpdf/U-PBI:space 250
font/devpdf/U-PBI:M 944
font/devpdf/U-PI:spacewidth 250
font/devpdf/U-PI:space  250
font/devpdf/U-PI:M  944
font/devpdf/U-PR:spacewidth 250
font/devpdf/U-PR:space  250
font/devpdf/U-PR:M  946
font/devpdf/U-S:spacewidth 250
font/devpdf/U-S:space   250
font/devpdf/U-TB:spacewidth 250
font/devpdf/U-TB:space  250
font/devpdf/U-TB:M  944
font/devpdf/U-TBI:spacewidth 250
font/devpdf/U-TBI:space 250
font/devpdf/U-TBI:M 889
font/devpdf/U-TI:spacewidth 250
font/devpdf/U-TI:space  250
font/devpdf/U-TI:M  833
font/devpdf/U-TR:spacewidth 250
font/devpdf/U-TR:space  250
font/devpdf/U-TR:M  889
font/devpdf/U-ZCMI:spacewidth 220
font/devpdf/U-ZCMI:space220
font/devpdf/U-ZCMI:M840
font/devpdf/U-ZD:spacewidth 278
font/devpdf/U-ZD:space  278

As you can see, generally, 1/3 of an em would deliver looser text, except for
mono spaced fonts where it is considerably tighter. Most western language
fonts do include a "space" glyph [1].

Some CJK fonts (which also include western glyphs) have all glyphs mono spaced
but 2 different widths, a larger one for ideographs, the space width for these
is usually matching the western glyph size. (See font DFSongStd as an
example).

Other CJK fonts have proportional western glyphs and fixed width CJK, with no
space glyph defined, this is when afmtodit fails to write a spacewidth
parameter. See font TakaoPGothic as an example).

When fonts do not have a space glyph they sometimes have a u0020 and a u00A0
glyph which are also good candidates for setting spacewidth. The GNU Unifont
Alex is using has both of these glyph which are good candidates for setting
spacewidth since it is a mono spaced font.

[1] you can use \[space] in groff, if your font has a space glyph, and you
seem to get a fixed width space. It is usually defined into font as something
like:-

/space {
0 512 hsbw
endchar
} ND

And hsbw operator is defined as:-

hsbw RD sbx wx hsbw ND

sets the left sidebearing point at (sbx, 0) and sets the character
width vector to (wx, 0) in character space. This command also
sets the current point to (sbx, 0), but does not place the point in
the character path. Use rmoveto for the first point in the path.
The name hsbw stands for horizontal sidebearing and width; hor-
izontal indicates that the y component of both the sidebearing
and width is 0. Either 

[bug #65601] Bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[Deri James]

Update of bug #65601 (group groff):

 Assigned to:None => gbranden   

___

Follow-up Comment #1:

Assigning to Branden as the expert on this, since it seems to be his new code
causing the issue.  See bug #65109



___

Reply to this item at:

  

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

[groff] 01/01: [gropdf] Handle both types in one document.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 0f96f3a281d82bb0c1a59e5e819d2a22bede6c5d
Author: Deri James 
AuthorDate: Thu Apr 18 01:17:22 2024 +0100

[gropdf] Handle both types in one document.

The different format of font described in previous commit fails if
document contains fonts of both formats. The reason is because the
regexes included the /o flag (compile once) for speed, but if the
format changed (from RD to -|) in a different font, parsing failed.

Now the regexes are compiled once for each font.

* src/devices/gropdf/gropdf.pl: Use qr// to compile regexes once
per font.
---
 ChangeLog| 14 ++
 src/devices/gropdf/gropdf.pl |  9 ++---
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1cce0827d..a88d52c5d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2024-04-17  Deri James  
+
+   [gropdf] Handle both types in one document.
+
+   The different format of font described in previous commit fails if
+   document contains fonts of both formats. The reason is because the
+   regexes included the /o flag (compile once) for speed, but if the
+   format changed (from RD to -|) in a different font, parsing failed.
+
+   Now the regexes are compiled once for each font.
+
+   * src/devices/gropdf/gropdf.pl: Use qr// to compile regexes once
+   per font.
+
 2024-04-17  Deri James  
 
[gropdf] Improve font parsing.
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 240f1025c..59434a8ec 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -4601,6 +4601,7 @@ sub map_subrs
 my $stage=0;
 my $lin=$lines->[0];
 my $i=0;
+my ($RDre,$NDre);
 
 for (my $j=0; $j<=$#{$lines}; $lin=$lines->[++$j] )
 {
@@ -4612,6 +4613,8 @@ sub map_subrs
{
$sec{'#Subrs'}=$j;
$stage=1;
+   $RDre=qr/\Q$RD\E/;
+   $NDre=qr/\Q$ND\E/;
}
elsif ($lin=~m/^\/(.+?)\s+\{string currentfile exch readstring 
pop\}\s*executeonly def/)
{
@@ -4638,7 +4641,7 @@ sub map_subrs
$stage=2;
$i=0;
}
-   elsif ($lin=~m/^\s*dup\s+(\d+)\s+(\d+)\s+\Q$RD\E (.*)/os)
+   elsif ($lin=~m/^\s*dup\s+(\d+)\s+(\d+)\s+$RDre (.*)/s)
{
my $n=$1;
my $l=$2;
@@ -4666,7 +4669,7 @@ sub map_subrs
 #  subs_call($s,"#$n");
$lines->[$i]=["#$n",$l,$s,$NP];
}
-   elsif ($lin=~m/^\Q$ND\E/o)
+   elsif ($lin=~m/^$NDre/)
{}
else
{
@@ -4680,7 +4683,7 @@ sub map_subrs
$sec{'#Pad'}=$j;
$stage=3;
}
-   elsif ($lin=~m/^\s*\/([-.\w]*)\s+(\d+)\s+\Q$RD\E (.*)/os)
+   elsif ($lin=~m/^\s*\/([-.\w]*)\s+(\d+)\s+$RDre (.*)/s)
{
my $n=$1;
my $l=$2;

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/01: Improve font parsing.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 5589bcd18776c6d236c53226a0ee30506180e6b6
Author: Deri James 
AuthorDate: Wed Apr 17 19:25:03 2024 +0100

Improve font parsing.

The usual (for fontforge converted ttf fonts) is to use the RD, ND
and NP operators within charstring definitions, however these are
just named in the private subrs dictionary so could be assigned
any name.

A debian .pfb version of a google .ttf font (which has not passed
through fontforge) used -| |- and | as the 3 equivalent. In
addition it used a different lenIV value for the eexec encryption (4)
and the charstring encryption (0) (didn't know you could do that).

* src/devices/gropdf/gropdf.pl: Make RD, ND and NP variables set
from parsing the private subrs. Honour lenIV=0 when encrypting
charstrings.
---
 ChangeLog| 18 ++
 src/devices/gropdf/gropdf.pl | 39 +--
 2 files changed, 47 insertions(+), 10 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e56b92eb1..1cce0827d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2024-04-17  Deri James  
+
+   [gropdf] Improve font parsing.
+
+   The usual (for fontforge converted ttf fonts) is to use the RD, ND
+   and NP operators within charstring definitions, however these are
+   just named in the private subrs dictionary so could be assigned
+   any name.
+
+   A debian .pfb version of a google .ttf font (which has not passed
+   through fontforge) used -| |- and | as the 3 equivalent. In
+   addition it used a different lenIV value for the eexec encryption (4)
+   and the charstring encryption (0) (didn't know you could do that).
+
+   * src/devices/gropdf/gropdf.pl: Make RD, ND and NP variables set
+   from parsing the private subrs. Honour lenIV=0 when encrypting
+   charstrings.
+
 2024-04-16  Deri James  
 
[gropdf] Problem with '(' and '\' (\[rs])
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 5543b0f1f..240f1025c 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -361,6 +361,9 @@ my $textenccmap=''; # CMap for groff text.enc encoding
 my @XOstream=();
 my @PageAnnots={};
 my $noslide=0;
+my $ND='ND';
+my $NP='NP';
+my $RD='RD';
 my $transition={PAGE => {Type => '/Trans', S => '', D => 1, Dm => '/H', M => 
'/I', Di => 0, SS => 1.0, B => 0},
BLOCK => {Type => '/Trans', S => '', D => 1, Dm => '/H', M => 
'/I', Di => 0, SS => 1.0, B => 0}};
 my $firstpause=0;
@@ -4577,7 +4580,7 @@ sub encrypt_exec
 sub encrypt_char
 {
 my $la=shift;
-unshift(@{$la},0x44,0x65,0x72,0x69);
+unshift(@{$la},0x44,0x65,0x72,0x69) if $lenIV;
 my $res;
 my $cypher;
 my $cr=C_DEF;
@@ -4610,6 +4613,22 @@ sub map_subrs
$sec{'#Subrs'}=$j;
$stage=1;
}
+   elsif ($lin=~m/^\/(.+?)\s+\{string currentfile exch readstring 
pop\}\s*executeonly def/)
+   {
+   $RD=$1;
+   }
+   elsif ($lin=~m/^\/(.+?)\s+\{noaccess def\}\s*executeonly def/)
+   {
+   $ND=$1;
+   }
+   elsif ($lin=~m/^\/(.+?)\s+\{noaccess put\}\s*executeonly def/)
+   {
+   $NP=$1;
+   }
+   elsif ($lin=~m'^/lenIV\s+(\d+)')
+   {
+   $lenIV=$1;
+   }
}
elsif ($stage == 1)
{
@@ -4619,7 +4638,7 @@ sub map_subrs
$stage=2;
$i=0;
}
-   elsif ($lin=~m/^\s*dup\s+(\d+)\s+(\d+)\s+RD (.*)/s)
+   elsif ($lin=~m/^\s*dup\s+(\d+)\s+(\d+)\s+\Q$RD\E (.*)/os)
{
my $n=$1;
my $l=$2;
@@ -4645,9 +4664,9 @@ sub map_subrs
 
 #  $s=decrypt_char($s);
 #  subs_call($s,"#$n");
-   $lines->[$i]=["#$n",$l,$s,'NP'];
+   $lines->[$i]=["#$n",$l,$s,$NP];
}
-   elsif ($lin=~m/^ND/)
+   elsif ($lin=~m/^\Q$ND\E/o)
{}
else
{
@@ -4661,7 +4680,7 @@ sub map_subrs
$sec{'#Pad'}=$j;
$stage=3;
}
-   elsif ($lin=~m/^\s*\/([-.\w]*)\s+(\d+)\s+RD (.*)/s)
+   elsif ($lin=~m/^\s*\/([-.\w]*)\s+(\d+)\s+\Q$RD\E (.*)/os)
{
my $n=$1;
my $l=$2;
@@ -4690,7 +4709,7 @@ sub map_subrs
}
else
{
-   $lines->[$i]=["/$n",$l,$s,'ND'];
+   $lines->[$i]=["/$n",$l,$s,$ND];
}
 
$i=0;
@@ -4886,7 +4905,7 @@ sub encrypt
 
next if !defined($lin);
 
-   if (ref($lin) eq 'ARRAY' and $lin->[TYPE] eq 'NP')
+   if (ref($lin) eq 'ARRAY' and

[groff] 02/03: Problem with '(' and '\' (\[rs])

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit f336f8244b09191b16722984c33fc5addcc4a284
Author: Deri James 
AuthorDate: Tue Apr 16 17:34:59 2024 +0100

Problem with '(' and '\' (\[rs])

Bpth these tokens have meaning for roff AND pdf strings. In
pdfs unbalanced parentheses have to be escaped (with '\') and
a single '\' has to be similarly escaped, '\\'. It is gropdf's
responsibility to ensure pdf strings are valid, no matter what
the input.

If '\(ul' is passed then the UTF-16 character becomes '_'.
If '\[rs](ul' is passed (i.e. '\(ul' is intended to become the
UTF-16 string) \[rs] becomes '\' leaving '\(ul', which if
becomes '_', not what is intended. If the unbalanced '(' is
eascaped first, '\[rs]\(ul' which could become '\\_' when the
'\' is escaped, yielding '\_'. The code which escpes parenthesis
checks it is not already preceded by '\' since adding another
would give you '\\(' which is not what you want. The correct
output should be '\\\(ul' to achieve the correct pdf string.

This fixes the above issue (I hope).

* src/devices/gropdf/gropdf.pl: Change pattern matches
---
 src/devices/gropdf/gropdf.pl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 3ca187f69..5543b0f1f 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -1981,7 +1981,6 @@ sub Clean
 my $p=shift;
 
 $p=~s/\\c?$//g;
-$p=~s/\\[eE]/\\/g;
 $p=~s/\\[ 0~t]/ /g;
 $p=~s/\\[,!"#\$%&’.0:?{}ˆ_‘|^prud]//g;
 $p=~s/\\'/\\[aa]/g;
@@ -2004,6 +2003,7 @@ sub utf16
 my $p=Clean(shift);
 my $label=shift;
 
+$p=~s/\\\(rs|\\\[rs\]/\\E/g;
 $p=~s/\\\[(.*?)\]/FindChr($1,0)/eg;
 $p=~s/\\C($parcln)/FindChr($1,1)/eg;
 #$p=~s/\\\((..)/FindChr($1)/eg;
@@ -2019,6 +2019,7 @@ sub utf16
 
 $p=~s/(?https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/03: Another font with UTF-16 added to comment

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 3cb502448b1de76036af7c143230ac11f7410bee
Author: Deri James 
AuthorDate: Tue Apr 16 15:28:41 2024 +0100

Another font with UTF-16 added to comment

* font/devps/S
---
 font/devps/S | 316 +--
 1 file changed, 158 insertions(+), 158 deletions(-)

diff --git a/font/devps/S b/font/devps/S
index ae8b3a902..e76b7bae2 100644
--- a/font/devps/S
+++ b/font/devps/S
@@ -19,189 +19,189 @@ spacewidth 250
 
 charset
 space  250 0   32  space
-!  333,672,17  3   33  exclam
-fa 713,705 3   34  universal
-#  500,673,16  3   35  numbersign
+!  333,672,17  3   33  exclam  --  0021
+fa 713,705 3   34  universal   --  2200
+#  500,673,16  3   35  numbersign  --  0023
 sh "
-te 549,707 3   36  existential
-%  833,655,36  3   37  percent
-&  778,661,18  3   38  ampersand
-st 439,500,17  3   39  suchthat
-(  333,673,191 3   40  parenleft
-)  333,673,191 3   41  parenright
-** 500,551 3   42  asteriskmath
-+  549,533 3   43  plus
+te 549,707 3   36  existential --  2203
+%  833,655,36  3   37  percent --  0025
+&  778,661,18  3   38  ampersand   --  0026
+st 439,500,17  3   39  suchthat--  220B
+(  333,673,191 3   40  parenleft   --  0028
+)  333,673,191 3   41  parenright  --  0029
+** 500,551 3   42  asteriskmath--  2217
++  549,533 3   43  plus--  002B
 pl "
-,  250,104,152 3   44  comma
-\- 549,288 3   45  minus
+,  250,104,152 3   44  comma   --  002C
+\- 549,288 3   45  minus   --  2212
 mi "
-.  250,95,17   3   46  period
-/  278,646,18  3   47  slash
+.  250,95,17   3   46  period  --  002E
+/  278,646,18  3   47  slash   --  002F
 sl "
-0  500,685,14  3   48  zero
-1  500,673 3   49  one
-2  500,685 3   50  two
-3  500,685,14  3   51  three
-4  500,685 3   52  four
-5  500,690,14  3   53  five
-6  500,685,14  3   54  six
-7  500,673,16  3   55  seven
-8  500,685,14  3   56  eight
-9  500,685,18  3   57  nine
-:  278,460,17  3   58  colon
-;  278,460,152 3   59  semicolon
-<  549,522 3   60  less
-=  549,390 3   61  equal
+0  500,685,14  3   48  zero--  0030
+1  500,673 3   49  one --  0031
+2  500,685 3   50  two --  0032
+3  500,685,14  3   51  three   --  0033
+4  500,685 3   52  four--  0034
+5  500,690,14  3   53  five--  0035
+6  500,685,14  3   54  six --  0036
+7  500,673,16  3   55  seven   --  0037
+8  500,685,14  3   56  eight   --  0038
+9  500,685,18  3   57  nine--  0039
+:  278,460,17  3   58  colon   --  003A
+;  278,460,152 3   59  semicolon   --  003B
+<  549,522 3   60  less--  003C
+=  549,390 3   61  equal   --  003D
 eq "
->  549,522 3   62  greater
-?  444,686,17  3   63  question
-=~ 549,475 3   64  congruent
-*A 722,673 3   65  Alpha
-*B 667,673 3   66  Beta
-*X 722,673,0,0,9   3   67  Chi
-*D 612,688 3   68  Delta
-*E 611,673,0,6 3   69  Epsilon
-*F 763,673 3   70  Phi
-*G 603,673,0,6 3   71  Gamma
-*Y 722,673,0,7 3   72  Eta
-*I 333,673 3   73  Iota
-+h 631,689,18  3   74  theta1
-*K 722,673 3   75  Kappa
-*L 686,688 3   76  Lambda
-*M 889,673 3   77  Mu
-*N 722,673,8   3   78  Nu
-*O 722,685,17  3   79  Omicron
-*P 768,673 3   80  Pi
-*H 741,685,17  3   81  Theta
-*R 556,673,0,7 3   82  Rho
-*S 592,673 3   83  Sigma
-*T 611,673 3   84  Tau
-ts 439,500,233 3   86  sigma1
-*W 768,688 3   87  Omega
-*C 645,673 3   88  Xi
-*Q 795,684 3   89  Psi
-*Z 611,673,0,253   90  Zeta
-[  333,674,155 3   91  bracketleft
+>  549,522 3   62  greater --  003E
+? 

[groff] 03/03: ... and the ChangeLog

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 1cd6ed080ff026f0df1e213f4f93523120d54e94
Author: Deri James 
AuthorDate: Tue Apr 16 17:46:15 2024 +0100

... and the ChangeLog
---
 ChangeLog | 24 
 1 file changed, 24 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 4ec2ff55a..fd58b607d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,27 @@
+2024-04-16  Deri James  
+
+   [gropdf] Problem with '(' and '\' (\[rs])
+
+   Bpth these tokens have meaning for roff AND pdf strings. In
+   pdfs unbalanced parentheses have to be escaped (with '\') and
+   a single '\' has to be similarly escaped, '\\'. It is gropdf's
+   responsibility to ensure pdf strings are valid, no matter what
+   the input.
+
+   If '\(ul' is passed then the UTF-16 character becomes '_'.
+   If '\[rs](ul' is passed (i.e. '\(ul' is intended to become the
+   UTF-16 string) \[rs] becomes '\' leaving '\(ul', which
+   becomes '_', not what is intended. If the unbalanced '(' is
+   eascaped first, '\[rs]\(ul' which could become '\\_' when the
+   '\' is escaped, yielding '\_'. The code which escapes parenthesis
+   checks it is not already preceded by '\' since adding another
+   would give you '\\(' which is not what you want. The correct
+   output should be '\\\(ul' to achieve the correct pdf string.
+
+   This fixes the above issue (I hope).
+
+   * src/devices/gropdf/gropdf.pl: Change pattern matches
+
 2024-04-15  G. Branden Robinson 
 
* tmac/an-ext.tmac : Trivially refactor.  Rename string

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #65601] Bogus 'bogus composite' errors introduced by commit 6008b6b7aa

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65601>

 Summary: Bogus 'bogus composite' errors introduced by commit
6008b6b7aa
   Group: GNU roff
   Submitter: deri
   Submitted: Tue 16 Apr 2024 11:21:28 AM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 16 Apr 2024 11:21:28 AM UTC By: Deri James 
If preconv produces a valid composite character groff should not reject it. Of
course if the composite is not available in any available font it will elicit
the normal "not defined" error, but, if it is, this bug prevents it being
used. I have many examples including these using groff -man on some man
pages:-

troff:charsets.7:76: error: cannot format glyph: 'u0073_0326' is not a valid
composite character
troff:charsets.7:76: error: cannot format glyph: 'u0074_0326' is not a valid
composite character
troff:iso_8859-6.7:54: error: cannot format glyph: 'u0627_0653' is not a valid
composite character
troff:iso_8859-6.7:55: error: cannot format glyph: 'u0627_0654' is not a valid
composite character
troff:iso_8859-6.7:56: error: cannot format glyph: 'u0648_0654' is not a valid
composite character
troff:iso_8859-6.7:57: error: cannot format glyph: 'u0627_0655' is not a valid
composite character
troff:iso_8859-6.7:58: error: cannot format glyph: 'u064A_0654' is not a valid
composite character
troff:iso_8859-6.7:54: error: cannot format glyph: 'u0627_0653' is not a valid
composite character
troff:iso_8859-6.7:55: error: cannot format glyph: 'u0627_0654' is not a valid
composite character
troff:iso_8859-6.7:56: error: cannot format glyph: 'u0648_0654' is not a valid
composite character
troff:iso_8859-6.7:57: error: cannot format glyph: 'u0627_0655' is not a valid
composite character
troff:iso_8859-6.7:58: error: cannot format glyph: 'u064A_0654' is not a valid
composite character
troff:iso_8859-16.7:56: error: cannot format glyph: 'u0053_0326' is not a
valid composite character
troff:iso_8859-16.7:72: error: cannot format glyph: 'u0073_0326' is not a
valid composite character
troff:iso_8859-16.7:108: error: cannot format glyph: 'u0054_0326' is not a
valid composite character
troff:iso_8859-16.7:140: error: cannot format glyph: 'u0074_0326' is not a
valid composite character
troff:iso_8859-16.7:56: error: cannot format glyph: 'u0053_0326' is not a
valid composite character
troff:iso_8859-16.7:72: error: cannot format glyph: 'u0073_0326' is not a
valid composite character
troff:iso_8859-16.7:108: error: cannot format glyph: 'u0054_0326' is not a
valid composite character
troff:iso_8859-16.7:140: error: cannot format glyph: 'u0074_0326' is not a
valid composite character

Even nroff -T utf8 can't reproduce the man page properly!

xzcat /usr/share/man/man7/iso_8859-6.7.xz |preconv|nroff -Tutf8 -man -t -z

Personally I see little value in this error, the existing error reporting of a
special character not defined is more helpful since if you find a font which
contains the correct glyph, the error will be gone. I'm sure there are users
capable of creating a font with all sorts of weird composite glyphs, why
should we police what they can do?








___

Reply to this item at:

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

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

[bug #65585] [gropdf] problems introduced by commit cd9fde325f

[Deri James]

Follow-up Comment #5, bug #65585 (group groff):

I am getting this with 'shadow':-

derij@raspberrypi5:~/linuxman/man-pages $ make -B build-book
MANDIR=../build/man
make: *** No rule to make target 'build-book'.  Stop.

Which used to work before git pull --rebase. So I can't reproduce your page
number issue.

As I wrote, the current prepare.pl script does handle man pages which have
been updated to use .MR, it just does not use .MR (for speed).


___

Reply to this item at:

  

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

[groff] 01/01: 4 missing fonts from commit 98b0c1db476

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit cbe5a7802df5ff3a9f84a42e277cf3925a1eb303
Author: Deri James 
AuthorDate: Fri Apr 12 23:48:10 2024 +0100

4 missing fonts from commit 98b0c1db476

* font/devps: Include CR, CI, CB and CBI with
UTF-16 code in the comment field.
---
 font/devps/CB  | 456 -
 font/devps/CBI | 456 -
 font/devps/CI  | 456 -
 font/devps/CR  | 456 -
 4 files changed, 912 insertions(+), 912 deletions(-)

diff --git a/font/devps/CB b/font/devps/CB
index c5b1d9896..22ace6cb5 100644
--- a/font/devps/CB
+++ b/font/devps/CB
@@ -18,249 +18,249 @@ spacewidth 600
 encoding text.enc
 
 charset
-ha 600,750 2   0   asciicircum
-ti 600,311 0   1   asciitilde
-vS 600,811,13  2   2   Scaron
-vZ 600,811 2   3   Zcaron
-vs 600,679,12  2   4   scaron
-vz 600,679 2   5   zcaron
-:Y 600,789 2   6   Ydieresis
-tm 600,678 2   7   trademark
-aq 600,572 2   8   quotesingle
-Eu 600,612,12  2   9   Euro
+ha 600,750 2   0   asciicircum --  005E
+ti 600,311 0   1   asciitilde  --  007E
+vS 600,811,13  2   2   Scaron  --  0160
+vZ 600,811 2   3   Zcaron  --  017D
+vs 600,679,12  2   4   scaron  --  0161
+vz 600,679 2   5   zcaron  --  017E
+:Y 600,789 2   6   Ydieresis   --  0178
+tm 600,678 2   7   trademark   --  2122
+aq 600,572 2   8   quotesingle --  0027
+Eu 600,612,12  2   9   Euro--  20AC
 space  600 0   32  space
-!  600,572,12  2   33  exclam
-"  600,572 2   34  quotedbl
+!  600,572,12  2   33  exclam  --  0021
+"  600,572 2   34  quotedbl--  0022
 dq "
-#  600,649,52  2   35  numbersign
+#  600,649,52  2   35  numbersign  --  0023
 sh "
-$  600,646,124 2   36  dollar
+$  600,646,124 2   36  dollar  --  0024
 Do "
-%  600,617,33  2   37  percent
-&  600,539,12  0   38  ampersand
-'  600,572 2   39  quoteright
+%  600,617,33  2   37  percent --  0025
+&  600,539,12  0   38  ampersand   --  0026
+'  600,572 2   39  quoteright  --  2019
 cq "
-(  600,643,86  2   40  parenleft
-)  600,643,86  2   41  parenright
-*  600,570 2   42  asterisk
-+  600,438 0   43  plus
-,  600,163,100 0   44  comma
--  600,282 0   45  hyphen
+(  600,643,86  2   40  parenleft   --  0028
+)  600,643,86  2   41  parenright  --  0029
+*  600,570 2   42  asterisk--  002A
++  600,438 0   43  plus--  002B
+,  600,163,100 0   44  comma   --  002C
+-  600,282 0   45  hyphen  --  002D
 hy "
-.  600,153,12  0   46  period
-/  600,696,133 2   47  slash
+.  600,153,12  0   46  period  --  002E
+/  600,696,133 2   47  slash   --  002F
 sl "
-0  600,612,12  2   48  zero
-1  600,615 2   49  one
-2  600,613 2   50  two
-3  600,612,12  2   51  three
-4  600,613 2   52  four
-5  600,601,12  2   53  five
-6  600,612,12  2   54  six
-7  600,601 2   55  seven
-8  600,613,11  2   56  eight
-9  600,612,14  2   57  nine
-:  600,403,12  0   58  colon
-;  600,403,100 0   59  semicolon
-<  600,446,8   0   60  less
-=  600,339 0   61  equal
->  600,446,8   0   62  greater
-?  600,582,13  2   63  question
-@  600,579,18  2   64  at
+0  600,612,12  2   48  zero--  0030
+1  600,615 2   49  one --  0031
+2  600,613 2   50  two --  0032
+3  600,612,12  2   51  three   --  0033
+4  600,613 2   52  four--  0034
+5  600,601,12  2   53  five--  0035
+6  600,612,12  2   54  six --  0036
+7  600,601 2   55  seven   --  0037
+8  600,613,11  2   56  eight   --  0038
+9  600,612,14  2   57  nine--  0039
+:

[bug #65585] [gropdf] problems introduced by commit cd9fde325f

[Deri James]

Follow-up Comment #2, bug #65585 (group groff):

Hi Branden,

All the issues raised in this bug have now been fixed in the release I've just
done, one regression is outstanding, can't convert "rs" to unicode, but I will
fix that.

Alex is not screaming because the "special sauce" I gave him to create the
kernel book does not use the .MR macro at all, even when the particular man
page calls .MR! Most of them are using .BR name (n). Once he converts them all
to .MR, I'll let him know he can drop my sauce - then you may hear the
gnashing of teeth as well as the screams.

Your comments on glyphuni.cpp equally apply to afmtodit so when you integrate
it into afmtodit I can use it in gropdf.

Most of the features of my branch are now integrated in some way or another,
not always my code. :-)

The only thing I think which is still missing is the proper SS font for
devpdf, which produces "more perfect" typeset equations.

For the NEWS file perhaps you can use some of the information in the attached
pdf.

My condolences for your bereavement.

Regards

Deri

(file #55939)

___

Additional Item Attachment:

File name: NewGropdf.pdf  Size: 104KiB
<https://file.savannah.gnu.org/file/NewGropdf.pdf?file_id=55939>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4448d8da181e3133acac16b178e98513aa6405cd.tar.gz


___

Reply to this item at:

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

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

[groff] 02/02: Correct linear search introduced in commit cd9fde325f

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 2387949ffc11b753dd91480dcb85be6c22819790
Author: Deri James 
AuthorDate: Fri Apr 12 17:10:49 2024 +0100

Correct linear search introduced in commit cd9fde325f

* tmac/pdf.tmac: Various problems have been rectified, speed
improvements to the linear search, Keith protection against
illegal characters being used in string identifiers.

* contrib/mom/om.tmac: Switch to using Branden's linear search
so that we don't have to maintain two different methods.

Fixes <https://savannah.gnu.org/bugs/?65585>
---
 ChangeLog   | 31 ++
 contrib/mom/om.tmac |  5 ++--
 tmac/pdf.tmac   | 76 +++--
 3 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3f29eecea..e036b25c6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,34 @@
+2024-04-12  Deri James  
+
+   Correct and improve linear search introduced in commit
+   cd9fde325f, 4th March.
+
+   * tmac/pdf.tmac: Various problems have been rectified, speed
+   improvements to the linear search, Keith protection against
+   illegal characters being used in string identifiers.
+
+   * contrib/mom/om.tmac: Switch to using Branden's linear search
+   so that we don't have to maintain two different methods.
+
+   Fixes <https://savannah.gnu.org/bugs/?65585>
+
+2024-04-12  Deri James  
+
+   Support UTF-16 Bookmarks.
+
+   * src/devices/grops: Add comment field to the font files
+   which specifies the UTF-16 code for the character.
+
+   * utils/afmtodit/afmtodit.pl: Add comment field holding the
+   UTF-16 code.
+
+   * man/groff_font.5.man: Document use of comment field to hold
+   UTF-16 code.
+
+   * src/devices/gropdf/gropdf.pl: Extract UTF-16 code from font
+   comment field (rather than a new field). And tweak to pdf
+   parser.
+
 2024-03-26  G. Branden Robinson 
 
* src/utils/grog/grog.pl (do_line): Recognize new requests in
diff --git a/contrib/mom/om.tmac b/contrib/mom/om.tmac
index 299cbc949..c7d20272e 100644
--- a/contrib/mom/om.tmac
+++ b/contrib/mom/om.tmac
@@ -23631,8 +23631,9 @@ No room to start \\*[MN-pos] margin note #\\n[MN-curr] 
on page \\n[#P].
 .if '\\*[PDF_AST]'*' \{\
 .chop PDF_TXT
 .ie '\\*[.T]'pdf' \{\
-.   ie d pdf:look(\\*[PDF_NM]) \
-.   as PDF_TXT 
\&\\*[PDF_AST_Q]\\*[pdf:look(\\*[PDF_NM])]\\*[PDF_AST_Q]
+.   pdf:lookup \\*[PDF_NM]
+.   ie !'\\*[pdf:lookup-result]'' \
+.   as PDF_TXT \&\\*[PDF_AST_Q]\\*[pdf:lookup-value]\\*[PDF_AST_Q]
 .   el \{\
 .   as PDF_TXT Unknown
 .   if !rPDF_UNKNOWN .tm \
diff --git a/tmac/pdf.tmac b/tmac/pdf.tmac
index 1b2415270..745d4ee37 100644
--- a/tmac/pdf.tmac
+++ b/tmac/pdf.tmac
@@ -68,6 +68,7 @@ am solely responsible for any bugs I may have introduced into 
this file.
 .pdf:SS \[*z]
 .char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'
 .nr pdf:bm.nl 1
+.nr pdf:bm.nk 0
 .de pdfmark
 . nop \!x X ps:exec [\\$* pdfmark
 ..
@@ -156,7 +157,8 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .\"
 .\" Parse any specified (recognisable) PDFNOTE options
 .\"
-.   while dpdf:note\\$1 \{\
+.   while \A'\\$1' \{\
+.  if !dpdf:note\\$1 .break
 .  pdf:note\\$1 \\$@
 .  shift \\n[pdf:note.argc]
 .  \}
@@ -201,9 +203,11 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .de pdf:lookup
 .nr pdf:index 0 1
 .ds pdf:lookup-result \" empty
+.ds pdf:lookup-value  \" empty
 .while d pdf:bm\\n+[pdf:index].tag \{\
 .   if '\\$1'\\*[pdf:bm\\n[pdf:index].tag]' \{\
 .  ds pdf:lookup-result \\*[pdf:bm\\n[pdf:index].tag]\"
+.  ds pdf:lookup-value \\*[pdf:bm\\n[pdf:index].val]\"
 .  break
 .  \}
 .   \}
@@ -230,8 +234,10 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .   \" Make the bookmark name "untagged" by default,
 .   \" then parse any specified options, to set a "tag", if required
 .   \"
+.  nr pdf:bm.nr +1
 .  ds pdf:href-T
-.  while dpdf:href.opt\\$1 \{\
+.  while \A'\\$1' \{\
+. if !dpdf:href.opt\\$1 .break
 . pdf:href.opt\\$1 \\$@
 . shift \\n[pdf:href.argc]
 . \}
@@ -267,38 +273,26 @@ am solely responsible for any bugs I may have introduced 
into this file.
 .   \" in order to generate a uniquely serialised bookmark name,
 .   \" ( which we return in the string "PDFBOOKMARK.NAME" ),
 .   \"
-.  nr pdf:bm.nr +1
 .  ie '\\*[pdf:href-T]'' .ds PDFBOOKMARK.NAME pdf:bm\\n[pdf:bm.nr]
 .  el .ds PDFBOOKMARK.NAME \\*[pdf:href-T]
 .  pdf:href.sety
 .  ds pdf:cleaned \\$*
-.  ev pdfcln
-.  tr \[em]-
-.  nf
-.  box pdf:clean
-.  no

[bug #65585] Problems introduced by commit cd9fde325f

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65585>

 Summary: Problems introduced by commit cd9fde325f
   Group: GNU roff
   Submitter: deri
   Submitted: Fri 12 Apr 2024 03:51:08 PM UTC
Category: Driver gropdf
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: In Progress
 Privacy: Public
 Assigned to: deri
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 12 Apr 2024 03:51:08 PM UTC By: Deri James 
I have been looking at the current state of pdf.tmac and have found a few
issues. The changes which have been committed are:-

Introduction of a new flag, -S, which replaces my change which introduced the
concept of passing a single pipe character as a hotspot meant that the actual
text to form the actual hotspot would be "piped" to the document stream,
terminated by doing a markstop. This is what allowed Branden to implement the
man macros which place contents into a diversion before emitting a hotspot. I
have no objection to this change, although there were several ways of setting
up a hotspot containing a single pipe character before this change, and most
users are probably familiar with piping data. (Perhaps I should have used "<"
as the single character). I would be very annoyed if someone sent me a pdf
with a single "|" as a hotspot - would take me about 5 minutes to click it
with the mouse!

Another change was an attempt to only allow a restart after a preceding
suspend. This is a good idea, but it is in the wrong place, it should be
implemented in gropdf rather than pdf.tmac, since a user may use \X'pdf:
markrestart' as documented in the gropdf man page. Which bypasses the check in
pdf.tmac. 

Branden has implemented a looping construct to hold tags replacing an
associative array. It is not used if the user is using mom macros (it does not
work for mom documents). In fact it only works reliably for the man macros
producing a "book" of man pages, where it is used to differenciate between an
internal link to another page in the book or a "man:" URL to an external man
page. The problem is that the new code does not implement:-

.pdfhref L -D name

Which should emit the descriptive text associated with the named tag at the
time it was defined, but instead it just emits the "name". This is documented
in pdfmark.pdf, and used several times in pdfmark.ms, so it is reasonable to
assume users may be using this in their own documents if they use "pdfmom
--roff  -mspdf". So it is wrong to assume the new code is suitable for
everything except mom.

There is also an issue with the speed of the new code. One test file I used
went from an elapsed time of 0m3.08s to 11m31.62s. (About 670 times slower!).
This was producing a large document (LinuxManBook) from a single file, using
the command:-

time ~/groff-git/groff/test-pdfmom  --roff -Tpdf -mandoc -petk
LinuxManBook.trf -z

(test-pdfmom is the same as test-groff but calling the pdfmom in the build
directory). I don't know whether this slow down in groff will be acceptable to
most users, I'm meant to be on a sabatical so I am not going to argue either
way, but be aware that is Branden's attempt to solve one issue which was
solved months ago in my branch waiting for merging. My use of stringhex was
described as "obfuscation", which is rather insulting if the intention was to
imply a deliberate attempt to obscure the purpose of my code. The correct
interpretation of its use is to protect the data from interpretation by groff
so that any byte sequence can be used as a string name in groff. This is
analagous to using base64 to protect binary data in emails.

Although Branden's loopy code solves some issues with 1.23.0 it fails in a
number of ways which are dealt with successfully by the pdf.tmac in my branch
(i.e. t.trf in #64576).

There is a bug in Branden's code. The attached file, pdf-L.trf, illustrates
the issue. According to the documentation in pdfmark.pdf, if you use .pdfhref
L with a destination name but no descriptive text, the descriptive text given
when the destination is named is used. With Branden's code, instead of using
the descriptive text it uses the name of the destination instead. The two pdfs
called pdf-L illustrate the problem.

Another bug results in entries in the array Branden loops over get
over-vritten in certain circumstances. This code illustrates the bug.

.ig
  groff -Tpdf -dPDF.EXPORT=1 -z pdf-M.trf

Results:-

.ds pdf:bm1.tag one
.ds pdf:bm1.tag two

(The bm1.tag has been overwritten!!!)

But,

  groff -Tpdf -dPDF.EXPORT=1 -dPRINTSTYLE=1 -z pdf-M.trf

Results:-

.ds pdf:look(one) Once upon...
.ds pdf:look

Re: Milestone reached: hyperlinked mdoc(7) documents in PDF

[Deri]

On Friday, 22 March 2024 16:59:14 GMT Alejandro Colomar wrote:
> ow, how am I supposed to
> get that patch without anyone tampering it during its trip to my
> computer?  :(

derij@ws:~$ md5sum  /var/www/chinese.patch.gz 
109e2681b7402ca55118226aa575b6d3  /var/www/chinese.patch.gz

Tears in my eyes, joy in my heart (was: gropdf-ng merge status (was: PDF outline not capturing Cyrillic text))

[Deri]

 are actually held as nodes within 
troff so would be discarded as not a character. So the criticism is of my 
design, hardly what I call a code review and far too late to initiate a design 
review after all the code has been written.

One could see the current changes to \X and .device as a futile attempt to 
prevent my design from working by introducing a new error (not in 1.23.0) 
which prevents special characters being passed to output drivers. On current 
master try this:-

[derij@pip Russian]$ printf "\&\n.device \\[u0403]\n"|./test-groff -Tpdf -z
troff::2: error: special character 'u0413_0301' is invalid 
within a device control command

And it has been like that for weeks, is this a case of Branden trying to force 
his design? At some point he will have to reverse the change since his design 
requires the ability to pass special characters to the output driver. Maybe 
this will finally get reversed when the vapourware is ready. :-) Or may be 
soon after reading this. :-) Futile because circumvention of the new error was 
fairly simple.

Since I won't be around to change gropdf to use the new vapourware, and given 
the amount of new code in gropdf to handle font subsetting it will probably be 
sensible to revert to the 1.23.0 version of gropdf before the next release, 
since that code base has been well tested and although the font subsetting has 
been tested on about a hundred fonts there are thousands of different fonts 
out there which it has not been tested with, and disassembling a rogue font 
and comparing it to the subsetting code is not an easy task. If you do chance 
your arm with the new code, please could you remove my authorship since I have 
asked you not to release it when I can't support it.

I started this at 9:30 this morning (after a particularly sleepless night, one 
coffee break, and cooked the other half's lunch (she's the girl next door - 
known her for 65 years - also has cerebral palsy like me - she thinks us being 
together is divine providence, but I think everyone's unlucky sometimes. No, 
no no, don't mean it, I love her.)), it is now 17:45 and I'm starting to get 
excited this is my last monster typing marathon, and I say farewell to the 
lovely people on the list, I shall be clocking off the list probably tomorrow, 
I can't say I won't be back at some point, but I definitely need a good 6 
months at least. You have warn me out Branden, you should have agreed to video 
calls when I suggested it. :-)

Cheers 

Deri x

Re: PDF outline not capturing Cyrillic text

[Deri]

On Wednesday, 7 February 2024 01:07:37 GMT Robin Haberkorn wrote:
> Still, when using UTF-8 input, there are problems (missing letters) with
> link texts autogenerated by .pdfhref L.

[...]

> 
> Best regards,
> Robin
> 
> PS: And to comment on some of the heated discussions on this list:
> It's great that you and Branden spend so much time on improving Groff.
> I think, you do a great job. Regressions are sometimes unavoidable,
> especially when taking over a large code base from somebody else.

Hi Robin,

Many thanks for the kind words, although there will be some sad news later. :-
(

I wonder if you could send me a small example of .pdfhref L missing letters 
and the command you are using, I don't need the whole thesis, I would not 
understand it.

Cheers 

Deri

Re: gropdf-ng merge status (was: PDF outline not capturing Cyrillic text)

[Deri]

On Tuesday, 6 February 2024 14:45:59 GMT G. Branden Robinson wrote:
> Hi Deri,
> 
> Now _does_ seem to be a good time to catch up on gropdf-ng merge status.
> There were two things I knew were still unmerged: the slanted symbol
> (SS) font support and the stringhex business, which has larger
> consequences than I understood at first.
> 
> At 2024-02-06T13:39:51+, Deri wrote:
> > The current gropdf (in the master branch) does support UTF-16BE
> > for pdf outlines (see attached pdf), but Branden has not released
> 
> At this point it's a merge (to the master branch), not a release, but
> true with that caveat.
> 
> So let me take a crack at a code review.

Hi Branden,

Many thanks for your thoughts on my code. I shall reply in general terms since 
your grasp of some of the issues is rather hazy, as you admit.

Huge AGL lookup table

My least favourite solution, but you made me do it! The most elegant and 
efficient solution was to make a one line amendment to afmtodit which added an 
extra column to the groff font files which would have the UTF-16 code for that 
glyph. This would only affect devpdf and devps and I checked the library code 
groff uses to read its font files was not affected by an extra column. I also 
checked the buffer used would not cause an overflow. Despite this, you didn't 
like this solution, without giving a cogent reason,  but suggesting a lookup 
table!

As to whether I should embed the table, or read it in, I deferred to the more 
efficient method use by afmtodit, embed it as part of make. I still would 
prefer the extra column solution, then there is no lookup at all.

use_charnames_in_special

Probably unnecessary once you complete the work to return .device to its 
1.23.0 condition, as you have stated.

pdfmomclean

Not quite sure how your work on #64484 will affect this, we will have to wait 
and see.

Stringhex

Clearly you are still misunderstanding the issue, because there are some 
incorrect statements.

In any lookup there is a key/value pair. If dealing with a document written in 
Japanese, both the key and the value will arrive as unicode. No problem for 
the value, but the key will be invalid if used as part of a register name. 
There are two obvious solutions. One is to encode the key into something, 
easily decoded, which is acceptable to be used as part of a register name, or 
do a loop traversal over two arrays, one holding the keys and one the values. 
I'm pretty sure my 9yr old grandson would come up with a looping solution. I 
really don't understand your opposition to the encoding solution, Ok, I accept 
you would have done it the childs way with the performance hit, but I prefer 
the more elegant encoding solution.

Uniqueness of keys is an issue for either strategy. In mom, a user supplied 
key name is only possible by using the NAMED parameter, and if a user uses the 
same name twice in the document nothing nasty will happen, the overview panel 
will be correct, since each of those is tagged with a safe generated name, and 
if they have used the same name for two different places in the document, when 
they are checking all the intra-document links they will find one of them will 
go to the wrong place. Of course this could be improved by warning when the 
same name is provided for a different destination. The man/mdoc macros 
currently have no named destinations, all generated, but this will change if 
the mdoc section referencing is implemented.

You mention a possible issue if a diversion is passed to stringhex, since this 
is 95% your own code for stringup/down, I'm pretty sure that whatever you do 
to solve the issue in your own code can be equally applied to stringhex, so 
this not an argument you can use to prevent its inclusion.

As regards your point 2, this is a non-issue, in 1.23.0 it works fine with 
.device. You ask what does:-

\X'pdf: bizzarecmd \[u1234]'

Mean? Well, assuming you are writing in the ethiopic language and wrote:-

\X'pdf: bizzarecmd ሴ'

And gropdf would do a "bizzarecmd" using the CHARACTER given (ETHIOPIC 
SYLLABLE SEE). Which could be setting a window title in the pdf viewer, I'm 
not sure, I have not written a handler for bizzarecmd. As you can see not 
"misleading to a novice" at all, the fact that preconv changed it to be a 
different form and gropdf changed it back to a character to use in pdf meta-
data is completely transparent to the user.

Your work on \X and .device is to put .device back to how it was in 1.23.0 and 
alter \X to be the same, this is what you said would happen.

The purpose of my patch was intended to give Robin a robust solution to what 
he wanted to do.

You wrote in another email:-

"But tparm(const char *str, long, long, long, long, long, long, long,
long, long) is one of the worst things I've ever seen in C code.

As I just got done saying (more or less) to Deri, when you have to
obfuscate your inputs to cra

[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:

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

___
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/

Re: Configuring groff 1.23.0 on Fedora 39 fails to find the URW base 35 fonts

[Deri]

On Monday, 5 February 2024 16:51:29 GMT T.  Kurt Bond wrote:
> On Wed, 20 Dec 2023 04:52:31 -0500,
> 
> "G. Branden Robinson"  wrote:
> > Do any of the following directories exist on Fedora 39 and contain .afm
> > files alongside the fonts proper?
> > 
> >   _list_paths="\
> >   
> > /usr/share/fonts/type1/gsfonts/ \
> > /usr/share/fonts/default/Type1/ \
> > /usr/share/fonts/default/Type1/adobestd35/ \
> > /usr/share/fonts/type1/urw-base35/ \
> > /opt/local/share/fonts/urw-fonts/ \
> > /usr/local/share/fonts/ghostscript/"
> 
> No, none of those directories exist.
> 
> However, /usr/share/fonts/urw-base35 does exist and does contain .afm files.

Hi,

Have you tried running configure with the flag:-

--with-urw-fonts-dir=/usr/share/fonts/urw-base35

Cheers 

Deri

[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:

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

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

[bug #65246] grops download file does not handle .pfa filenames which contain spaces

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65246>

 Summary: grops download file does not handle .pfa filenames
which contain spaces
   Group: GNU roff
   Submitter: deri
   Submitted: Sat 03 Feb 2024 01:39:01 PM UTC
Category: Driver grops
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sat 03 Feb 2024 01:39:01 PM UTC By: Deri James 
Truncates name.







___

Reply to this item at:

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

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

Re: Ornamented Page Borders

[Deri]

On Thursday, 1 February 2024 16:59:36 GMT Emilia Stoyanova wrote:
> Greetings everyone,
> 
> Do any of you have experience with creating ornamented page borders?
> I have looked through the mailing list[^1] and through both mom's and
> utmac's
> documentation but I couldn't find exactly what I have in mind.
> 
> I have attached a pdf document, together with its pic(1) source code,
> to illustrate exactly what I am going for.
> 
> I also tried looking through cstr54 and UTP to maybe figure out how I might
> do
> that myself with pure troff requests, but I gave up after a while, since I'm
> still a bit of a neophyte here . . .
> 
> Also, does anyone perhaps have/host a collection of pic decorations one
> might
> browse and/or add to? I don't even know if using pic for that is standard
> o.o
> 
> Kind Regards,
> Emilia
> ---
> [^1]: https://lists.gnu.org/r/groff/2022-09/msg00088.html

Hi Emilia,

Everyone has probably got a different way of doing this. Tadziu gave you a 
pure pic way of doing the edge ornamentation, but the resulting pdf was over 
100kb, which is why he would program the pattern in postscript. Peter offered 
a method using a suitable repeated glyph from a font, which resulted in a 
9.5kb file. The big reduction is because the actual stroking of the pattern is 
stored in the font so the actual pattern is only stored once but used many 
times.

There is a way of pinching that idea of storing the pattern once and using it 
again and again, but using a single pic instance of your pattern rather than a 
font glyph. There are 3 stages:-

A) First run ornsingle.tr which produces ornsingle.pdf with this command:-

groff -Tpdf -p ornsingle.tr -P-p.35i,.35i >orn.pdf

Notice the custom paper size (.35 inch square) which is big enough to 
encompass one instance of your pattern, which, on its own is 2.9kb.

B) Now run ornpage.tr which generates an A4 page containing many copies of the 
pattern in ornpage.pdf, using groff commands. Use:-

groff -Tpdf -P-pa4 ornpage.tr > ornpage.pdf

Note the 4 lines at the top of the groff script which can affect the pattern 
generated. Now the whole page of patterns is 4.1kb.

C) Is to use ornpage.pdf as a type of watermark to ornament your document. 
There are several pdf utility programs which could do this job after groff has 
produced the document you want to ornament. But there is a way to get groff to 
do this while it is producing your document. The trick is to hook some code 
into whichever macro deals with starting a new page, for whichever macro 
language you use, that includes ornpage.pdf on every page. If you include the 
same pdf multiple times gropdf only stores it once and links to it if you use 
it again. The file ornmom.tr is a very crude example of this. Since it hooks 
into the START macro it is really only useful for single page simple 
documents, something much more sophisticated would be required for multi-page 
documents, possibly hooking in to NEWPAGE as well. You can run the example 
like this:-

groff -Tpdf -mom -k -P-pa4 ornmom.tr /usr/share/doc/groff-1.23.0/examples/mom/
letter.mom > letter.pdf

The document, including the letter, is now 6.3kb.

Cheers 

Deri
.ig
	groff -Tpdf -p ornsingle.tr -P-p.35i,.35i >orn.pdf
..
.po 1p
.vs 1p
.PS 		\" Scale width for close fit

define orn { [
	# Variables
	sideLength = $1/2;
	cupRad = $1/10;
	petalRad = $1/16.6;
	cornerRad = $1/20;
	splineLength = sideLength/5;
	splineTravel = splineLength * 2;
	rodLength = splineTravel;
	danglyFstRad = sideLength / 10;
	danglySndRad = danglyFstRad/2;
	danglyTrdRad = danglySndRad/2;

	Diamond: [
		NE: line down sideLength right sideLength;
		SE: line down sideLength left sideLength;
		SW: line up sideLength left sideLength;
		NW: line up sideLength right sideLength;
	];

	# Flower in the middle (Cup & Petals)
	Cup: circle rad cupRad at Diamond;
	circle rad petalRad with .s at Cup.n;
	circle rad petalRad with .sw at Cup.ne;
	circle rad petalRad with .w at Cup.e;
	circle rad petalRad with .nw at Cup.se;
	circle rad petalRad with .n at Cup.s;
	circle rad petalRad with .ne at Cup.sw;
	circle rad petalRad with .e at Cup.w;
	circle rad petalRad with .se at Cup.nw;

	# Corner Circles
	N: circle rad cornerRad at Diamond.NE.start;
	E: circle rad cornerRad at Diamond.SE.start;
	W: circle rad cornerRad at Diamond.SW.start;
	S: circle rad cornerRad at Diamond.NW.start;

	# Side splines
	move to N down splineTravel left splineTravel;
	spline left splineLength then down splineLength;
	move to N down splineTravel right splineTravel;
	spline right splineLength then down splineLength;
	move to W up splineTravel right splineTravel;
	spline right splineLength then up splineLength;
	move to W up splineTravel left splineTravel;
	spline left splineLength then up splineLength;

	# Side dangly bits
	Lnw: line up rodLength left rodLength at Diamond.NW.center;
	arc rad danglyFstRad from Lnw.end; 

[bug #61434] [man] want support for hyperlinked paragraph tags

[Deri James]

Follow-up Comment #4, bug#61434 (group groff):

[comment #3 comment #3:]
> This was an important follow-up commit.

> commit 52a5a89c0da9f90c83441b8eb8020344a8468686
> Author: G. Branden Robinson 
> Date:   Thu Feb 1 23:23:45 2024 -0600
> 
...
> Unfortunately, "pdf.tmac" doesn't
> expose a clean abstraction for "link starts here" and "link stops
here",
> instead implementing a hugely featured `pdfhref` macro that attempts to
> do everything--except support bracketing the link text in a diversion,
> which our man(7) design requires.

Is this accurate? It was true before my commit d71f9264 which enabled .MT and
.UR to be hyperlinks (both of which used diversions) and provided a means to
"bracket" the resulting text as a hotspot. Maybe the mechanism of using the
pipe character to "open" the bracket needs further promulgation, or perhaps we
should add a pair of macros to pdf.tmac, something like:-

.de pdflinkstart
.  ds pdf:col \\n[.m]
.  pdfhref \\$1 -D \\$2 "|"
..
.
.de pdflinkend
.  nop \X'pdf: markend'\m[\\*[pdf:col]]\c
..

Which could be used as:-

.pdflinkstart W http://bbc.co.uk
.nf
A multi
line hotlink (possibly from a diversion)
.fi
.pdflinkend

Just a thought. 


___

Reply to this item at:

  

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

Re: Milestone reached: hyperlinked man(7) documents in PDF

[Deri]

On Thursday, 1 February 2024 20:58:09 GMT G. Branden Robinson wrote:
> At 2024-01-31T13:19:18+0000, Deri wrote:
> > Oops, did not mean to send that, although it does show okular working
> > properly with an .MT link.
> 
> I concur.  It seems to only go wrong if the hotspots are misconfigured
> in the PDF, as I found out when accidentally regressing something in my
> working copy.  (Savannah #65233, fixed and pushed yesterday, didn't
> help.)
> 
> I'm working on #61434 now, and learning things I didn't know about input
> traps and diversion nesting...
> 
> Regards,
> Branden

Hi Branden,

I don't understand what you mean by "misconfigured hotspots". Your push for 
#65233 fixed the problem of .MT following a .TP turning off all further .MT's 
(because you were unsetting the an*do-hyperlink flag which affected all 
further .MT's).

This email thread mentioned the "PDF hyperlinks working in Evice and xpdf but 
not Okular" email you sent earlier, and my screenshot shows the links working 
in okular using the groff_man_pages.pdf in your drop box, which you asked 
people to test. In fact I have tested with these viewers - okular, evince, 
mupdf-gl, qpdfview, atril, firefox, chromium and xpdf - all allowed me to 
click on the coloured hotlink.

As far as okular is concerned, there was a problem with okular actioning hot 
links if okular was reading from stdin rather than a file, see https://
bugs.kde.org/show_bug.cgi?id=472440, but it is fixed now.

Cheers 

Deri

Re: Milestone reached: hyperlinked man(7) documents in PDF

[Deri]

On Wednesday, 31 January 2024 13:02:57 GMT Deri wrote:
> On Wednesday, 31 January 2024 05:10:21 GMT G. Branden Robinson wrote:
> > Hi folks,
> > 
> > In a frenzy of activity over the past few days Deri and I have landed
> > everything necessary to bring full hyperlink support to man(7) documents
> > in PDF.
> > 
> > * The MT/ME macros hyperlink email addresses.
> > * The UR/UE macros hyperlink general URLs.
> > * The MR macro produces "man:foo(1)"-style hyperlinks.
> > 
> > This should have been easier than it was, but I'll save my gripes about
> > why it wasn't for a postmortem at another time.  :)
> > 
> > Further, Deri's "groff man pages book" is now the "official"
> > groff-man-pages.pdf document.  It adds a spare but attractive cover page
> > and, importantly, "internalizes" the man page hyperlinks when the
> > document itself provides the page in question.  "External" man pages
> > remain in "man:foo(1)" form.
> > 
> > I've successfully tested these features in Evince and xpdf.  Okular is
> > giving me problems as I reported to this list earlier today.
> > 
> > As always, you can check out the latest version of this and other groff
> > documents in a Dropbox folder.
> > 
> > https://www.dropbox.com/sh/17ftu3z31couf07/AAC_9kq0ZA-Ra2ZhmZFWlLuva?dl=0
> > 
> > I'd appreciate feedback and particularly any report of bugs that you may
> > spot.
> > 
> > What next?
> > ==
> > 
> > mdoc(7) needs feature parity via its `Mt`, `Lk`, and `Xr`.  I'm already
> > working toward that, as recent commits will suggest.  Then we can say
> > that we have full PDF hyperlink support for _man pages_.
> > 
> > In man(7), it sure would be nice if we could turn paragraph tags into
> > hyperlinked text (this already works for `MR`, but not `MT` and `UR`).
> > I'm working on that, too.
> > 
> > Regards,
> > Branden

Oops, did not mean to send that, although it does show okular working properly 
with an .MT link.

[groff] 05/05: Update ChangeLog

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 3fe0a227e1533f8cc6ff56b890e70c79712a73de
Author: Deri James 
AuthorDate: Tue Jan 30 18:16:11 2024 +

Update ChangeLog
---
 ChangeLog | 37 +
 1 file changed, 37 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index b2fa75e5e..47f02fb8a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,40 @@
+2024-01-26  Deri James  
+
+Changes to satisfy Savannah #65231.
+
+Alter build of groff-man-pages.pdf to use the new pdfmom,
+so that all forward references (i.e. reference to groff_font(5)
+in addftinfo(1) page) are handled properly. Also pass bookmark
+names as text strings.
+
+* doc/doc.am: Use pdfmom.
+* tmac/an.tmac: Pass parameters to .pdfbookmark as a string.
+
+New pdfmom, can now be used with all macros.
+
+Previously only useful for producing documents with
+mom.
+
+* src/devices/gropdf/pdfmom.pl: New --roff flag allows
+other macros (e.g. -ms) to be given on the command line.
+
+* src/devices/gropdf/pdfmom.1.man: Document the new facility.
+
+Front Cover for groff-man-pages.pdf
+
+Feel free to alter "artwork" at will (perhaps add maintainer
+information.
+
+* doc/GMPfront.t: Only used during build, not required as part
+of installation.
+
+Remove artifacts from using stringhex.
+
+Introduced in commit #e62b188aacb, betraying its origin
+    from my deri-gropdf-ng branch which uses .stringhex.
+
+* src/devices/gropdf/gropdf.pl: minor fixes
+
 2024-01-29  G. Branden Robinson 
 
[tbl]: Fix Savannah #65225.

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/05: Front Cover for groff-man-pages.pdf

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit f619fee72005fba6fc10e5dc22b3df4ffb1372de
Author: Deri James 
AuthorDate: Tue Jan 30 16:55:43 2024 +

Front Cover for groff-man-pages.pdf

Feel free to alter "artwork" at will (perhaps add maintainer
information.

* doc/GMPfront.t: Only used during build, not required as part
of installation.
---
 doc/GMPfront.t | 70 ++
 1 file changed, 70 insertions(+)

diff --git a/doc/GMPfront.t b/doc/GMPfront.t
new file mode 100644
index 0..5011266b9
--- /dev/null
+++ b/doc/GMPfront.t
@@ -0,0 +1,70 @@
+.ig
+   front.t
+..
+.nr PDFOUTLINE.FOLDLEVEL 1
+.defcolor pdf:href.colour rgb 0.00 0.25 0.75
+.pdfinfo /Title "The Groff Manpage Book"
+.de an*cln
+.  ds \\$1
+.  als an*cln:res \\$1
+.  shift
+.  ds an*cln:res \\$*\"
+.  ds an*cln:chr \\$*
+.  substring an*cln:chr 0 0
+.  if '\%'\\*[an*cln:chr]' \{\
+.substring an*cln:res 1
+.  \}
+..
+.
+.de END
+..
+.
+.am reload-man END
+.de an*bookmark
+.  if '*[.T]'pdf' \{\
+.ie ($1=1) \{\
+.   an*cln an*page-ref-nm $2\"
+.   pdfbookmark -T "*[an*page-ref-nm]" $1 $2
+.\}
+.el .pdfbookmark $1 $2
+.  \}
+..
+.
+.de1 MR
+.  if ((n[.$] < 2) : (n[.$] > 3)) \
+.an-style-warn .$0 expects 2 or 3 arguments, got n[.$]
+.  if '*[.T]'pdf' \{\
+.ie n(.$=1 \
+.  I $1
+.el \{\
+.  an*cln an*page-ref-nm $1($2)
+.  ie d pdf:look(*[an*page-ref-nm]) .pdfhref L -D 
*[an*page-ref-nm] -A "$3" -- \fI$1\fP($2)
+.  el .IR $1 ($2)$3
+.\}
+.  \}
+.  hy n[an*hyphenation-mode]
+..
+.END
+.
+.de Hl
+.br
+\l'\\n[.l]u-\\n[.i]u\&\\$1'
+.br
+..
+\Z@\D't 8p'@
+.pdfbookmark 1 Cover
+.pdfpagenumbering
+.sp 2i
+.Hl
+.sp .6i
+.ad r
+.ps 52
+\m[maroon]Groff\m[]
+.sp 18p
+.ps 16
+\f[BMB]THE MAN PAGES BOOK\fP
+.sp .2i
+.Hl
+.pn 1
+.bp
+.pdfpagenumbering D . 1

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 04/05: Remove artifacts from using stringhex.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 9b8b3e2a508d7df0b661c9042b5f5d5e7a0688da
Author: Deri James 
AuthorDate: Tue Jan 30 18:02:13 2024 +

Remove artifacts from using stringhex.

Introduced in commit #e62b188aacb, betraying its origin
from my deri-gropdf-ng branch which uses .stringhex.

* src/devices/gropdf/gropdf.pl: minor fixes
---
 src/devices/gropdf/gropdf.pl | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index f0b04909a..f7fc229cd 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -2063,10 +2063,9 @@ sub UTFName
 
 $s=substr($s,1);
 my $s1=$s;
-$s1=~s/([[:xdigit:]]{2})/chr(hex($1))/eg;
 my $s2=utf16($s1,1);
 #return "/".MakeLabel((substr($s2,0,1) eq '/')?$s:$s2);
-my $s3='/'.join '', map { MakeLabel($_) } unpack('C*',(substr($s2,0,1) eq 
'\\')?$s:$s2);
+my $s3='/'.join '', map { MakeLabel($_) } unpack('C*',$s2);
 return $s3;
 
 }
@@ -2854,7 +2853,7 @@ sub ParsePDFValue
return(ParsePDFArray($pdfwds));
 }
 
-if ($wd=~m/(.*?)(\(.*)$/)
+if ($wd=~m/(.*?)(\(.*)$/ and substr($wd,0,1) ne '/')
 {
if (defined($1) and length($1))
{

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 02/05: New pdfmom, can now be used with all macros.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit df1d447c99b984f9fd82f46cfc2becb2475b6d6e
Author: Deri James 
AuthorDate: Tue Jan 30 17:05:00 2024 +

New pdfmom, can now be used with all macros.

Previously only useful for producing documents with
mom.

* src/devices/gropdf/pdfmom.pl: New --roff flag allows
other macros (e.g. -ms) to be given on the command line.

* src/devices/gropdf/pdfmom.1.man: Document the new facility.
---
 src/devices/gropdf/pdfmom.1.man | 27 +++-
 src/devices/gropdf/pdfmom.pl| 56 +
 2 files changed, 72 insertions(+), 11 deletions(-)

diff --git a/src/devices/gropdf/pdfmom.1.man b/src/devices/gropdf/pdfmom.1.man
index 8d60047ba..77397fded 100644
--- a/src/devices/gropdf/pdfmom.1.man
+++ b/src/devices/gropdf/pdfmom.1.man
@@ -10,7 +10,7 @@ macro package for
 .\" Legal Terms
 .\" 
 .\"
-.\" Copyright (C) 2012-2020 Free Software Foundation, Inc.
+.\" Copyright (C) 2012-2023 Free Software Foundation, Inc.
 .\"
 .\" Permission is granted to make and distribute verbatim copies of this
 .\" manual provided the copyright notice and this permission notice are
@@ -53,6 +53,7 @@ macro package for
 .\" 
 .
 .SY pdfmom
+.RB [ \-\-roff ]
 .RB [ \-Tpdf ]
 .RI [ groff-options ]
 .RI [ file\~ .\|.\|.]
@@ -60,6 +61,7 @@ macro package for
 .
 .
 .SY pdfmom
+.RB [ \-\-roff ]
 .B \-Tps
 .RI [ pdfroff-options ]
 .RI [ groff-options ]
@@ -89,6 +91,25 @@ macros.
 .
 .
 .P
+If the
+.B \-\-roff
+option is used,
+the wrapper can be used with macro packages other than
+.MR groff_mom @MAN7EXT@ .
+.
+This is also true if the wrapper is renamed or linked as a
+pseudonym;
+for example,
+creating a
+.I pdfms
+link pointing to the
+.I pdfmom
+executable makes a wrapper for producing PDFs with the
+.I ms
+package.
+.
+.
+.P
 .I pdfmom
 prints to the standard output,
 so output must usually be redirected to a destination file.
@@ -173,6 +194,10 @@ options,
 .I pdfmom
 displays its version information and exits.
 .
+Using the
+.B \-\-help
+option displays a usage message and exits.
+.
 .
 .\" 
 .SH Authors
diff --git a/src/devices/gropdf/pdfmom.pl b/src/devices/gropdf/pdfmom.pl
index 89977d496..1c24d85b9 100644
--- a/src/devices/gropdf/pdfmom.pl
+++ b/src/devices/gropdf/pdfmom.pl
@@ -1,6 +1,6 @@
 #!@PERL@
 #
-#  pdfmom  : Frontend to run groff -mom to produce PDFs
+#  pdfmom  : Frontend to run groff to produce PDFs
 #  Deri James  : Friday 16 Mar 2012
 #
 
@@ -29,6 +29,20 @@ my @cmd;
 my $dev='pdf';
 my $preconv='';
 my $readstdin=1;
+my $mom='-mom';
+my $zflg='';
+if ($0=~m/pdf(\w+)$/)
+{
+my $m=$1;
+if ($m=~m/^(mom|mm|ms|me|man|mandoc)$/)
+{
+$mom="-".$m;
+}
+else
+{
+$mom='';
+}
+}
 my $RT_SEP='@RT_SEP@';
 
 $ENV{PATH}=$ENV{GROFF_BIN_PATH}.$RT_SEP.$ENV{PATH} if 
exists($ENV{GROFF_BIN_PATH});
@@ -68,11 +82,30 @@ while (my $c=shift)
$preconv=$c;
next;
 }
-elsif ($c eq '-z' or $c eq '-Z')
+elsif ($c eq '-Z')
 {
-   $dev=$c;
+   $zflg=$c;
next;
 }
+elsif ($c eq '-z')
+{
+   $zflg="$c -dPDF.EXPORT=1";
+   next;
+}
+elsif ($c eq '--roff')
+{
+$mom='';
+}
+elsif ($c eq '--help')
+{
+   print "usage: pdfmom [--roff] [-Tpdf] [groff-option ...] [file ...]\n";
+   print "usage: pdfmom [--roff] -Tps [pdfroff-option ...] [groff-option 
...] [file ...]\n";
+   print "usage: pdfmom {-v | --version}\n";
+   print "usage: pdfmom --help\n";
+   print "\nHandle forward references in PDF documents.\n" .
+ "See the pdfmom(1) manual page.\n";
+   exit;
+}
 elsif ($c eq '-v' or $c eq '--version')
 {
print "GNU pdfmom (groff) version @VERSION@\n";
@@ -123,19 +156,22 @@ if ($readstdin)
 
 if ($dev eq 'pdf')
 {
-system("groff -Tpdf -dLABEL.REFS=1 -mom -z $cmdstring 2>&1 | LC_ALL=C grep 
'^\\. *ds' | groff -Tpdf -dPDF.EXPORT=1 -dLABEL.REFS=1 -mom -z - $cmdstring 
2>&1 | LC_ALL=C grep '^\\. *ds' | groff -Tpdf -mom $preconv - $cmdstring");
+if ($mom)
+{
+system("groff -Tpdf -dLABEL.REFS=1 $mom -z $cmdstring 2>&1 | LC_ALL=C 
grep '^\\. *ds' | groff -Tpdf -dPDF.EXPORT=1 -dLABEL.REFS=1 $mom -z - 
$cmdstring 2>&1 | LC_ALL=C grep '^\\. *ds' | groff -Tpdf $mom $preconv - 
$cmdstring $zflg");
+}
+else
+{
+system("groff -Tpdf -dPDF.EXPORT=1 -z $cmdstring 2>&1 | LC_ALL=C grep 
'^\\. *ds' | groff -Tpdf $preconv - $cmdstring $zflg");
+}
 }
 elsif ($dev eq 'p

[groff] 03/05: Changes to satisfy bug #65231.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 3e5f09d1b3a9df072cd2a67b648925049a655e82
Author: Deri James 
AuthorDate: Tue Jan 30 17:14:08 2024 +

Changes to satisfy bug #65231.

Alter build of groff-man-pages.pdf to use the new pdfmom,
so that all forward references (i.e. reference to groff_font(5)
in addftinfo(1) page) are handled properly. Also pass bookmark
names as text strings.

* doc/doc.am: Use pdfmom.
* tmac/an.tmac: Pass parameters to .pdfbookmark as a string.
---
 doc/doc.am   | 8 +++-
 tmac/an.tmac | 6 +++---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/doc/doc.am b/doc/doc.am
index 76efe43b0..e9cac80cc 100644
--- a/doc/doc.am
+++ b/doc/doc.am
@@ -38,6 +38,11 @@ DOC_GROFF = \
   GROFF_BIN_PATH="$(GROFF_BIN_PATH)" \
   $(GROFFBIN) -M $(doc_srcdir) $(MFLAG) $(FFLAG) -ww -b
 
+DOC_PDFMOM = \
+  GROFF_COMMAND_PREFIX= \
+  GROFF_BIN_PATH="$(GROFF_BIN_PATH)" \
+  $(GROFF_BIN_PATH)/pdfmom -M $(doc_srcdir) $(MFLAG) $(FFLAG) -ww -b --roff
+
 # This image file is used by several documents in the groff source tree.
 DOC_GNU_EPS = doc/gnu.eps
 
@@ -263,8 +268,9 @@ man-clean:
 # feature of gropdf.
 doc/groff-man-pages.pdf: $(GROFF_MAN_PAGES_ALL) eqn pic tbl \
   $(TMAC_PACKAGE_MAN) $(TMAC_PACKAGE_MDOC) font/devps/freeeuro.pfa
-   $(GROFF_V)$(DOC_GROFF) -pet -mandoc -dHF=HB -rC1 \
+   $(GROFF_V)$(DOC_PDFMOM) -pet -mandoc -dHF=HB -rC1 \
  -rCHECKSTYLE=3 -Tpdf -P-e \
+ $(top_srcdir)/doc/GMPfront.t \
  $(GROFF_MAN_PAGES1) \
  $(tmac_srcdir)/sv.tmac $(GROFF_MAN_PAGES2) \
  $(tmac_srcdir)/en.tmac $(GROFF_MAN_PAGES3) > $@
diff --git a/tmac/an.tmac b/tmac/an.tmac
index dceed923b..20d96ff70 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -437,7 +437,7 @@
 .  ie \\n[cR] .pl +1v
 .  el .sp (.5i - .5m)
 .  if !\\n[an*was-TH-bookmark-emitted] \{\
-.an*bookmark 1 \E*[an*page-ref-string]
+.an*bookmark 1 "\\*[an*page-ref-string]"
 .nr an*was-TH-bookmark-emitted 1
 .  \}
 .  tl '\\*[an-pageref]'\\*[an-extra3]'\\*[an-pageref]'
@@ -716,7 +716,7 @@ contains unsupported escape sequence
 .  if \\n[.$] \{\
 .ds an-section-heading \\$*\"
 .if \\n[CS] .stringup an-section-heading
-.an*bookmark 2 \E*[an-section-heading]
+.an*bookmark 2 "\\*[an-section-heading]"
 .nop \&\\*[an-section-heading]
 .  \}
 .  if \\n[an-remap-I-style-in-headings] .ftr I I
@@ -742,7 +742,7 @@ contains unsupported escape sequence
 .  if \\n[an-remap-I-style-in-headings] .ftr I \\*[an-heading-family]BI
 .  if \\n[.$] \{\
 .ds an*subsection-heading \\$*\"
-.an*bookmark 3 \E*[an*subsection-heading]
+.an*bookmark 3 "\\*[an*subsection-heading]"
 .nop \&\\$*
 .  \}
 .  if \\n[an-remap-I-style-in-headings] .ftr I I

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #65231] Improve our groff-man-pages.pdf

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65231>

 Summary: Improve our groff-man-pages.pdf 
   Group: GNU roff
   Submitter: deri
   Submitted: Tue 30 Jan 2024 04:54:29 PM UTC
Category: General
Severity: 1 - Wish
  Item Group: Build/Installation
  Status: In Progress
 Privacy: Public
 Assigned to: deri
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Tue 30 Jan 2024 04:54:29 PM UTC By: Deri James 
To bring it more into line with the LinuxManBook.pdf add clickable links to
navigate between separate man entries in the volume, and add a front cover.
Also introduce the new pdfmom which can now work with all other macros, not
just mom, it's been waiting in the wings since the code freeze last year. It
also requires 3 lines change in an.tmac.







___

Reply to this item at:

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

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

Re: [groff] 02/14: [man]: Warn on bad MT/ME/UR/UE nesting.

[Deri]

On Tuesday, 30 January 2024 02:13:47 GMT G. Branden Robinson wrote:
> [man]: Warn on bad MT/ME/UR/UE nesting.
> 
> * tmac/an.tmac (MT, ME, UR, UE): Throw warnings on bad nesting.

This causes a warning when viewing groff_out(5), because it has a nested .UR 
within a .TP. Replacing:-

.TP
.UR https://\:github.com/\:Alhadis/\:Roff\:.js/
.I Roff.js
.UE
is a viewer for intermediate output written in JavaScript.

With this:-

.P
.UR https://\:github.com/\:Alhadis/\:Roff\:.js/
.I Roff.js
.UE
.TP
\&
\v'-1.4v'is a viewer for intermediate output written in JavaScript.

Seems to work, in this instance, but perhaps there is a better way.

Cheers 

Deri

Re: [groff] 02/14: [man]: Warn on bad MT/ME/UR/UE nesting.

[Deri]

On Tuesday, 30 January 2024 02:13:47 GMT G. Branden Robinson wrote:
> [man]: Warn on bad MT/ME/UR/UE nesting.
> 
> * tmac/an.tmac (MT, ME, UR, UE): Throw warnings on bad nesting.

This causes a warning when viewing groff_out(5), because it has a nested .UR 
within a .TP. Replacing:-

.TP
.UR https://\:github.com/\:Alhadis/\:Roff\:.js/
.I Roff.js
.UE
is a viewer for intermediate output written in JavaScript.

With this:-

.P
.UR https://\:github.com/\:Alhadis/\:Roff\:.js/
.I Roff.js
.UE
.TP
\&
\v'-1.4v'is a viewer for intermediate output written in JavaScript.

Seems to work, in this instance, but perhaps there is a better way.

Cheers 

Deri




___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[bug #65215] .MT/.ME and .UR/.UE should result in hyperlink for pdf output

[Deri James]

Update of bug#65215 (group groff):

  Status: In Progress => Fixed  

___

Follow-up Comment #1:

Fixes committed.

commit d71f9264f8c187aee1161f27cda7d42c4ad7065e
Author: Deri James 
AuthorDate: Fri Jan 26 15:47:28 2024 +

.MT/.ME and .UR/.UE hyperlinking for pdf output

Our documentation groff_man.7 documents that these requests are
for hyperlinks. The .pdfhref W command expects the hotspot text
to be passed as a parameter, but these pairs of requests enclose
the required text. To solve this conundrum if the given
hyperlink text to the .pdfhref request is the single pipe
character "|" then mark all following text sent for output as
the hotspot, terminate the hotspot on receipt of \X'pdf:
markend' escape. This new facility is only available using -T
pdf, not using -T ps and the pdfmark macros. Note the advice in
the gropdf man page to use \X'pdf: marksuspend' and \X'pdf:
markrestart' to protect any headers and footers becoming part of
the hotspot in case the hyperlinked text crosses a page
boundary.

* tmac/an.tmac: add code to use .pdfhref W for these hyperlinks
and protect against crossing page boundaries.

* tmac/pdf.tmac: if the given text for a hyperlink consists of
a single pipe character "|", start the hotspot and only
terminate when \X'pdf: markend' is received.



___

Reply to this item at:

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

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

[groff] 01/01: .MT/.ME and .UR/.UE hyperlinking for pdf output

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit d71f9264f8c187aee1161f27cda7d42c4ad7065e
Author: Deri James 
AuthorDate: Fri Jan 26 15:47:28 2024 +

.MT/.ME and .UR/.UE hyperlinking for pdf output

Our documentation groff_man.7 documents that these requests are
for hyperlinks. The .pdfhref W command expects the hotspot text
to be passed as a parameter, but these pairs of requests enclose
the required text. To solve this conundrum if the given
hyperlink text to the .pdfhref request is the single pipe
character "|" then mark all following text sent for output as
the hotspot, terminate the hotspot on receipt of \X'pdf:
markend' escape. This new facility is only available using -T
pdf, not using -T ps and the pdfmark macros. Note the advice in
the gropdf man page to use \X'pdf: marksuspend' and \X'pdf:
markrestart' to protect any headers and footers becoming part of
the hotspot in case the hyperlinked text crosses a page
boundary.

* tmac/an.tmac: add code to use .pdfhref W for these hyperlinks
and protect against crossing page boundaries.

* tmac/pdf.tmac: if the given text for a hyperlink consists of
a single pipe character "|", start the hotspot and only
terminate when \X'pdf: markend' is received.
---
 ChangeLog | 23 +++
 tmac/an.tmac  | 12 +---
 tmac/pdf.tmac |  9 ++---
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7c42add2e..19d9b6a80 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,26 @@
+2024-01-26  Deri James  
+
+   Our documentation groff_man.7 documents that these requests are
+   for hyperlinks. The .pdfhref W command expects the hotspot text
+   to be passed as a parameter, but these pairs of requests enclose
+   the required text. To solve this conundrum if the given
+   hyperlink text to the .pdfhref request is the single pipe
+   character "|" then mark all following text sent for output as
+   the hotspot, terminate the hotspot on receipt of \X'pdf:
+   markend' escape. This new facility is only available using -T
+   pdf, not using -T ps and the pdfmark macros. Note the advice in
+   the gropdf man page to use \X'pdf: marksuspend' and \X'pdf:
+   markrestart' to protect any headers and footers becoming part of
+   the hotspot in case the hyperlinked text crosses a page
+   boundary.
+
+   * tmac/an.tmac: add code to use .pdfhref W for these hyperlinks
+   and protect against crossing page boundaries.
+
+   * tmac/pdf.tmac: if the given text for a hyperlink consists of
+   a single pipe character "|", start the hotspot and only
+   terminate when \X'pdf: markend' is received.
+
 2024-01-25  G. Branden Robinson 
 
[troff]: Trivially refactor (trap Booleans).
diff --git a/tmac/an.tmac b/tmac/an.tmac
index a60eb888f..cfedbe28b 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -587,6 +587,7 @@ contains unsupported escape sequence
 .  PT
 .  ev
 .  ns
+.  if '\\*[.T]'pdf' .pdfmarkrestart
 ..
 .
 .\" Schedule a page break when the next output line is written (not
@@ -598,6 +599,7 @@ contains unsupported escape sequence
 .\" Prepare the footer for a page of the document.
 .de1 an-footer
 .  if \\n[an-suppress-header-and-footer] .return
+.  if '\\*[.T]'pdf' .pdfmarksuspend
 .  ev an*env-header-and-footer
 .  ie \\n[cR] \
 .ds an*ofoot "\\*[an-pageref]\"
@@ -1106,6 +1108,7 @@ contains unsupported escape sequence
 .  if (\\n[an*is-in-link-text-diversion] & \\n[an*do-hyperlink]) \{\
 .\" Start diversion in a new environment.
 .ev an*link-text-env
+.if \\n[an*is-output-pdf] \&\m[\\*[PDFHREF.TEXT.COLOUR]]\c
 .di an*link-text-div
 .ll (\\n[an*saved-line-length]u - \\n[an*saved-indentation]u)
 .  \}
@@ -1129,9 +1132,9 @@ contains unsupported escape sequence
 .ie \\n[dn] \{\
 .  if \\n[an*is-output-html] \
 .nop \X^html:^\c
-.  if \\n[an*is-output-pdf] \
-.pdfhref W -D \\*[an*prefix]\\*[an*hyperlink] -- \
-\\*[an*hyperlink]\c
+.  if \\n[an*is-output-pdf] \{\
+.pdfhref W -D \\*[an*prefix]\\*[an*hyperlink] -- "|"
+.  \}
 .  if \\n[an*is-output-terminal] \
 .nop \X^tty: link \\*[an*prefix]\\*[an*hyperlink]^\c
 .  \" Strip off the final newline of the diversion and emit it.
@@ -1142,6 +1145,8 @@ contains unsupported escape sequence
 .nop \X^html:^\c
 .  if \\n[an*is-output-terminal] \
 .nop \X^tty: link^\c
+.  if \\n[an*is-output-pdf] \
+.nop \X'pdf: markend'\m[\\*[pdf:curcol]]\c
 .\}
 .\" If there was no link text, format URI as its own link text.  We
 .\" don't add angle brackets here.
@@ -1336,6 +1341,7 @@ contains unsupported escape sequence
 .
 .nr an*can-hyperlink 0
 .if (  \n[an*is-output-html] \
+ : \n[an*is

[bug #65215] .MT/.ME and .UR/.UE should result in hyperlink for pdf output

[Deri James]

URL:
  <https://savannah.gnu.org/bugs/?65215>

 Summary: .MT/.ME and .UR/.UE should result in hyperlink for
pdf output
   Group: GNU roff
   Submitter: deri
   Submitted: Fri 26 Jan 2024 01:27:39 PM UTC
Category: Macro man
Severity: 1 - Wish
  Item Group: Rendering/Cosmetics
  Status: In Progress
 Privacy: Public
 Assigned to: deri
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Fri 26 Jan 2024 01:27:39 PM UTC By: Deri James 
These macros are meant to produce hyperlinks (according to groff_man(7)).







___

Reply to this item at:

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

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

Re: Proposed: make \X read its argument in copy mode

[Deri]

On Tuesday, 23 January 2024 02:46:50 GMT G. Branden Robinson wrote:
> [self-follow-up]
> 
> > Or: Should device control commands affect the environment?
> > 
> > Recall the definition of the \X escape sequence from CSTR #54 (1992).
> > 
> > 10.7.  Transparent output.  The sequence \X'anything' copies anything
> > to the output, as a device control function of the form x X anything
> > (§22).  Escape sequences in anything are processed.
> 
> [...]
> 
> > I therefore propose to change this, and have the `\X` escape sequence
> > read its argument in copy mode.  That will make it work like the
> > `device` request in groff 1.23.0 and earlier[1].
> 
> It's looking like we _will_ be giving up something with this change:
> 
> The ability to use a newline as an escape sequence delimiter with the \X
> escape sequence.
> 
> I would argue that this change is of vanishingly small impact.
> 
> 1.  Likely few people knew you could use a newline as a delimiter with
> this escape sequence in the first place.
> 2.  You couldn't do that in DWB troff anyway.[1]
> 3.  The opposite problem is of greater interest to practical users:
> _embedding_ newlines inside device control commands.  \X didn't
> support that anyway, neither in DWB troff nor groff.[2]

Hi Branden,

Just to be sure, can you confirm your intention is to return .device to its 
1.23.0 state, and mirror that behaviour for \X, so we will have no more red 
seepage.

Cheers 

Deri

Re: Tibetan fonts

[Deri]

On Sunday, 21 January 2024 00:28:42 GMT Oliver Corff via wrote:
> Hi Tom,
> 
> བཀྲ་ཤིས་བདེ་ལེགས།
> 
> (sorry, I forgot the shad)
> 
> have you tried the font TibMachUni-1.901b.ttf? It is available via
> 
> package manager e.g. in Fedora 39.
> 
> Can post a source file for your examples, please? I may try in tomorrow.
> 
> Best regards,
> 
> Oliver.
> 
> On 21/01/2024 00:09, Tom wrote:
> > Hi,
> > 
> > I did typeset few books in Heirloom Troff with quite good outcome.
> > For next book I need to use Tibetan font and unfortunately I can't
> > make work in Heirloom Troff and Groff, only Neatroff does work.
> > 
> > Right now I'm eager to completely switch to Groff. I can make any font
> > work in Groff but not Tibetan. To my basic knowledge, I guess it is
> > all about blwm and blws not accessible. There are only few Tibetan
> > fonts with complex glyph composition which works in Neatroff. In groff
> > I have managed only BabelStoneTibetan to display but several glyphs
> > doesn't compose.
> > 
> > For viewing I have attached Groff and Neatroff pdfs.
> > 
> > YagpoTibetanUni: 100% composing in Neatroff but 100% failed in Groff
> > and Heirloom troff.
> > BabelStoneTibetan: 100% failed in Groff and Neatroff.
> > 
> > I have tried various tibetan fonts, as well NotoSerifTibetan present
> > in linux repositories. All those fonts don't work and groff yields:
> > troff::20: warning: special character 'u0F04' not defined
> > troff::20: warning: special character 'u0F05' not defined
> > troff::20: warning: special character 'u0F0D' not defined
> > ...
> > 
> > If I understand enough, the warnings are about missing glyph mappings.
> > 
> > Would you mind to have a look and check if Tibetan fonts are possible
> > to make work in Groff ? I appreciate for any hints, and direction I
> > can follow to make it happen.
> > 
> > 
> > Regards,
> > Tom
> 

Hi Tom,

Using the font suggested by Oliver (after installing it with Peter Schafter's 
install-font.sh script) and using the latest unicode aware pdf generation 
version of groff (awaiting release by Branden), with this script:-

.ft TibetanR \" What I called Oliver's suggested font
.ps 24
.vs 28
.pdfbookmark 1 བཀྲ་ཤིས་བདེ་ལེགས།
བཀྲ་ཤིས་བདེ་ལེགས།
.br
.ad l
༄༅། །དབུ་མ་རྩ་བའི་ཚིག་ལེའུར་བྱས་པ་ཤེས་རབ་ཅེས་བྱ་བ་བཞུགས་སོ།
ཧཱུ༔ ཨོ་རྒྱན་ཡུལ་གྱི་ནུབ་བྱང་མཚམས༔

It produced the attached. 

Cheers

Deri


Tibetan.pdf
Description: Adobe PDF document

Re: Proposed: make \X read its argument in copy mode

[Deri]

On Saturday, 20 January 2024 00:56:34 GMT G. Branden Robinson wrote:
> Hi Deri,
> 
> At 2024-01-20T00:07:21+0000, Deri wrote:
> > On Friday, 19 January 2024 21:39:57 GMT G. Branden Robinson wrote:
> > > Right.  Before I craft a lengthy response to this--did you see the
> > > footnote?
> > 
> > Yes, sorry, it didn't help. I'm just comparing output now with output
> > in 1.23.0 and what you claim you are doing is the reverse of what I'm
> > seeing.
> 
> I haven't yet pushed anything implementing my (new) intentions,
> reflected in the subject line.  I wanted to gather feedback first.
> 
> What happened was, I thought "the `device` request and `\X` escape
> sequence should behave the same, modulo the usual differences in parsing
> (delimitation vs. reading the rest of the line, the leading double quote
> mechanism in request form, and so forth)".
> 
> Historically, that has never been the case in groff.
> 
> Here's (the meat of) the actual test case I recently wrote and pushed.
> 
> input='.nf
> \X#bogus1: esc \%man-beast\[u1F63C]\\[u1F00]
> -\[aq]\[dq]\[ga]\[ha]\[rs]\[ti]# .device bogus1: req
> \%man-beast\[u1F63C]\\[u1F00] -\[aq]\[dq]\[ga]\[ha]\[rs]\[ti] .ec @
> @X#bogus2: esc @%man-beast@[u1F63C]@@[u1F00]
> -@[aq]@[dq]@[ga]@[ha]@[rs]@[ti]# .device bogus2: req
> @%man-beast@[u1F63C]@@[u1F00] -@[aq]@[dq]@[ga]@[ha]@[rs]@[ti]'
> 
> I know that looks hairy as hell.  I'm testing several things.
> 
> Here is what the output of that test looks like on groff 1.22.3 and
> 1.22.4.
> 
> x X bogus1: esc man-beast\[u1F00] -
> x X bogus1: req @%man-beast\[u1F63C]\[u1F00] -\[aq]\[dq]\[ga]\[ha]\[rs]\[ti]
> x X bogus2: esc man-beast@[u1F00] -
> x X bogus2: req @%man-beast@[u1F63C]@[u1F00] -@[aq]@[dq]@[ga]@[ha]@[rs]@[ti]
> 
> Observations of the above:
> 
> A.  When using `\X`, the escape sequences \%, \[u1F63c], \[aq], \[dq],
> \[ga], \[ha], \[rs], \[ti] all get discarded.
> 
> B.  When you change the escape character and self-quote it in the
> formatter, it comes out as-is in the device control command.  I
> found this absurd, since there is no such thing as an escape
> character in the device-independent output language, and whatever
> escaping convention a device-specific control command needs to come
> up with for things like, oh, expressing Unicode code points is
> necessarily independent of a random *roff document's choice of
> escape character anyway.
> 
> Here is what the test output looks like on groff 1.23.0.  It enabled a
> few more characters to get rendered in PDF bookmarks.
> 
> x X bogus1: esc man-beast\[u1F00] -'"`^\~
> x X bogus1: req @%man-beast\[u1F63C]\[u1F00] -\[aq]\[dq]\[ga]\[ha]\[rs]\[ti]
> x X bogus2: esc man-beast@[u1F00] -'"`^\~
> x X bogus2: req @%man-beast@[u1F63C]@[u1F00] -@[aq]@[dq]@[ga]@[ha]@[rs]@[ti]
> 
> Here is what the test output looks like on groff Git HEAD.  It was my
> first stab at solving the problem, the one I am now having partial
> second thoughts about.
> 
> x X bogus1: esc man-beast\[u1F00] -'"`^\~
> x X bogus1: req man-beast\[u1F00] -'"`^\~
> x X bogus2: esc man-beast\[u1F00] -'"`^\~
> x X bogus2: req man-beast\[u1F00] -'"`^\~
> 
> I was briefly happy with this, but I started wondering what happens when
> you interpolate any crazy old damned string inside a device control
> command and I rapidly became uncomfortable.  Because `\X` does not read
> its argument in copy mode, it can get exposed to "nodes" (and in groff
> Git, `device` can too)--this is that old incomprehensible nemesis that
> afflicted pdfmom users relentlessly before 1.23.0.[1][2][3][4][5][6]
> 
>   can't transparently output node at top level
> 
> But the reason 1.23.0 doesn't throw these errors is because I hid them,
> not because we fixed them.[7]

Hi Branden,

It might be worth clarifying what this caused this error to appear (before you 
suppressed it in 1.23.0). A particularly "fruity" bookmark appears in the mom 
example file mom-pdf.mom. It uses:-

.HEADING 1 \
"Comparison of \-Tps\*[FU4]/\*[FU2]\-mpdfmark with \-Tpdf\*[FU4]/\*[FU2]\-mom

Which after expansion becomes this:-

7. Comparison of \-Tps\h'(\En[.ps]u/\E*[$KERN_UNIT]u*4u)'/\h'(\En[.ps]u/
\E*[$KERN_UNIT]u*2u)'\-mpdfmark with \-Tpdf\h'(\En[.ps]u/
\E*[$KERN_UNIT]u*4u)'/\h'(\En[.ps]u/\E*[$KERN_UNIT]u*2u)'\-mom

And this passed to .pdfbookmark! In the version of pdf.tmac used until now, 
this monstrous string is run through .asciify to produce:-

7. Comparison of Tps/mpdfmark with Tpdf/mom

You can see that all the "\-" are missing, .asciify left them as nodes, and 
each of them would elicit the error. So under 1.22.4 this is what the overview 
bookmark in the pdf look

Re: Proposed: make \X read its argument in copy mode

[Deri]

On Saturday, 20 January 2024 01:39:21 GMT G. Branden Robinson wrote:
> [self-follow-up with correction]
> 
> At 2024-01-19T18:56:37-0600, G. Branden Robinson wrote:
> > This might be more accurately stated as:
> > 
> > 2) \X behaves like .device used to (in groff 1.23.0 and earlier).
> 
> [correction follows]
> And I repeat: this is _NOT_ a _hard_ prerequisite to expressing Unicode
> sequences in the output, but it seems useful so that authors of output
> drivers (and supporting macro files for them) can keep their sanity.
> 
> [elaboration]
> 
> What I mean is that we can pass Unicode between "pdf.tmac" and the
> output driver _today_.  Consider the following notional macro.
> 
> .de pdfmark2
> . nop \!x X ps:exec [\\$* pdfmark2
> ..
> 
> (The open bracket has something to do with PostScript syntax, I think.)
> 
> ...and it getting called by some other macro encoding the argument...
> 
> .de pdflink
> .  ds pdf*input \\$*\"
> .  encode pdf*input \" performs magic transformation, like "stringhex"
> .  pdfmark2 \\*[pdf*input]
> ..
> 
> ...and I have document using these.
> 
> .H 1 "This is my heading"
> .pdflink "HI DERI "
> 
> This ultimately would show up in the output as something like this.
> 
> x X ps: exec [4849204445524920F09F9888 pdfmark2
> 
> Something pretty close to that works on the deri-gropdf-ng branch today,
> as I understand it.

Hi Branden,

I'm afraid this is all wrong (or at least out of date, my private branch, 
which is rebased against a very recent HEAD, does not use stringhex as part of 
the interface with gropdf, it only uses it to build register names which need 
to include unicode characters with in the name). In fact you know all this 
since you recently wrote:-

"Deri's right that his `stringhex` solution, and the underlying problem it
solves, aren't fundamentally about how the formatter talks to the device
driver (though that is ultimately a necessary step)", the bit in brackets is 
wrong.

As an example, if this was in a file.mom:-

.HEADING 1 "Гуляйпольщина или Махновщина"

After running through preconv the resultant grout is:-

x X ps:exec [/Dest /pdf:bm24 /Title (8. \[u0413]\[u0443]\[u043B]\[u044F]\
[u0439]\[u043F]\[u043E]\[u043B]\[u044C]\[u0449]\[u0438]\[u043D]\[u0430] \
[u0438]\[u043B]\[u0438] \[u041C]\[u0430]\[u0445]\[u043D]\[u043E]\[u0432]\
[u0449]\[u0438]\[u043D]\[u0430]) /Level 2 /OUT pdfmark

And the entry in the pdf looks like this:-

99 0 obj << /Dest /pdf:bm24
/Next 100 0 R
/Parent 77 0 R
/Prev 98 0 R
/Title 
(\376\377\0\70\0\56\0\40\4\23\4\103\4\73\4\117\4\71\4\77\4\76\4\73\4\114\4\111\4\70\4\75\4\60\0\40\4\70\4\73\4\70\0\40\4\34\4\60\4\105\4\75\4\76\4\62\4\111\4\70\4\75\4\60)
>>
endobj

The preconv unicodes have been converted to octal bytes with a UTF-16 BOM on 
the front, and a pdf viewer will show the string with unicode characters in 
its bookmark panel. No stringhex involved, just passing preconv output 
straight to gropdf.

> But my _suggestion_ would be that we support something more like this.
> 
> x X ps: exec [HI DERI \[u00F0]\[u009F]\[u0098]\[u0088] pdfmark2
> 
> or this...
> 
> x X ps: exec [HI DERI \[uDE08]\[uD83D] pdfmark2
> 
> ...or even this...
> 
> x X ps: exec [HI DERI \[u1F608] pdfmark2
> 
> These are groffish ways of expressing UTF-8, UTF-16LE, and UTF-32,
> respectively.  The reuse of groff Unicode code point escape sequence
> syntax is, I would hope, more helpful than confusing.

This is exactly the technique I am now using. Whatever preconv produces, ends 
up as a UTF-16 string. You can mix normal text with the preconv output, (and 
groff characters like \[em]), but as soon as any character in the string 
requires unicode the whole string is converted.

Cheers

Deri
> My concerns are that (1) people don't have to use two different escaping
> conventions _within the formatter_ to get byte sequences to the output
> driver, and (2) that driver-supporting macro file writers don't have to
> handle a bunch of special cases in device control commands.
> 
> Those factors are what drive my proposal.
> 
> Regards,
> Branden

Re: Proposed: make \X read its argument in copy mode

[Deri]

On Friday, 19 January 2024 21:39:57 GMT G. Branden Robinson wrote:
> Hi Deri,
> 
> At 2024-01-19T21:16:54+0000, Deri wrote:
> > On Tuesday, 16 January 2024 19:22:48 GMT G. Branden Robinson wrote:
> > > Or: Should device control commands affect the environment?
> > > 
> > > I therefore propose to change this, and have the `\X` escape sequence
> > > read its argument in copy mode.  That will make it work like the
> > > `device` request in groff 1.23.0 and earlier[1].
> > 
> > This is not what I am seeing in current 'master/head'. [...]
> 
> Right.  Before I craft a lengthy response to this--did you see the
> footnote?

Hi Branden,

Yes, sorry, it didn't help. I'm just comparing output now with output in 
1.23.0 and what you claim you are doing is the reverse of what I'm seeing.

I hope I don't elicit a too lengthy response. There are 3 logical 
possibilities for the list to decide:-

1) .device behaves like \X.

This seems to be what Branden has done at the moment. Disadvantage is that as 
a by-product you can't send unicode to the output drivers using either method, 
and some escapes affect the text stream when the expectation is for things 
sent to the output driver should not affect text stream.

2) \X behaves like .device.

This is what Branden said was the intention. This allows pdf title (normally 
shown in the window header in a pdf viewer) to use unicode.

3) Leave things as they were prior to recent commits.

It will be interesting to hear from as many people as possible which they 
think is the best option. I definitely think we should not be making the use 
of unicode harder.

Cheers 

Deri

> 
> Regards,
> Branden

Re: Proposed: make \X read its argument in copy mode

[Deri]

On Tuesday, 16 January 2024 19:22:48 GMT G. Branden Robinson wrote:
> Or: Should device control commands affect the environment?
> 
...

> I therefore propose to change this, and have the `\X` escape sequence
> read its argument in copy mode.  That will make it work like the
> `device` request in groff 1.23.0 and earlier[1].

This is not what I am seeing in current 'master/head'. Using this as a test:-

===
.ds abc def
.br
black
\X'abc=\*[abc]\m[red]\(em\[u0431]'
red?\m[black]
.device device abc=\*[abc]\m[red]\(em\[u0431]
red?
===

With 1.23.0 it produces:-

x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s1
V12000
H72000
md
DFd
tblack
wh2500
V12000
H96160
mr 65535 0 0
x X abc=def
wh2500
tred?
wh5000
V12000
H120870
mr 0 0 0
x X device abc=def\m[red]\(em\[u0431]
tred?
n12000 0
x trailer
V792000
x stop

And the colour sequence of the words goes - black red black. You can also see 
the unicode character \[u0431] has been successfully passed to the 
postprocessor when using .device and also the \m[red] has not "leaked" into 
the text output stream but just passed to the postprocessor. The \X variant 
cleaned all the nodes before passing on what is left (and leaked red).

Now on current master which contains the changes on which you are asking us to 
comment, this is the result:-

x T ps
x res 72000 1 1
x init
p1
troff:X.trf:4: error: special character 'em' is invalid within a device 
control command
troff:X.trf:4: error: special character 'u0431' is invalid within a device 
control command
troff:X.trf:6: error: special character 'em' is invalid within a device 
control command
troff:X.trf:6: error: special character 'u0431' is invalid within a device 
control command
x font 5 TR
f5
s1
V12000
H72000
md
DFd
tblack
wh2500
V12000
H96160
mr 65535 0 0
x X abc=def
wh2500
tred?
wh5000
V12000
H120870
x X device abc=def
tred?
n12000 0
x trailer
V792000
x stop

Now we can see that both \X and .device are behaving the same way as \X used 
to (with the addition of a new error to document the facility to pass unicode 
characters, and others, has been withdrawn). Plus, both methods are now a 
leaky red!

You appear to have achieved the exact opposite of what you set out to achieve 
- "make it (\X) work like the device request in 1.23.0 and earlier". I think 
your instincts are correct, once you have completed your for loop the removal 
of unwanted nodes from a string will be simple, so it would not be necessary 
to rely on \X doing it for you. The device request currently operates as \X is 
documented in CSTR #54 so it makes sense to have our \X behave the same.

Usually it is better to preserve data rather than arbitrarily discard it so 
that it can't be recovered, so I agree with your desire to make \X behave like 
.device has always behaved, but possibly after your "for" request is ready so 
people have a simple way of choosing the current behaviour, i.e. removing 
nodes from a string or passing the string as a whole.

In https://savannah.gnu.org/bugs/?63074 which is titled "develop convention 
for encoding Unicode character sequences for passage to device control 
commands" shows you understand the necessity of having the ability to pass all 
unicode and other characters to postprocessors and are aware that .device was 
already capable of doing that, I have no objection to you extending this 
capability to \X if that is your wont, but the current state of master is the 
opposite.

Cheers

Deri

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[Deri James]

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

[comment #25 comment #25:]
> I hear your expression of urgency but I don't think "stringhex" is good
long-term solution to what ails us.  You are correct in comment #22 that I did
not correctly apprehend at first what it was for.  I thought you developed it
because we had no way to reliably transmit arbitrary byte sequences to device
control commands.  But we did, sort of--it just needed to be made consistent
and reliable.  That it wasn't is what my test case attempts to illustrate and
what the fix to bug #64484 attempts to prove.

Yes, I want .device to pass everything exactly "as-is" just as it does now,
all escapes left untouched. I don't understand your opposition to stringhex.
If I remember correctly you didn't like "shouty" capitals in .SH/Sh and people
generally agreed, so you added .stringup/down to enforce the case change -
fair enough. Similarly people on the list have asked for pdf support for
non-latin languages, and to support all the features currently supported for
latin languages I need stringhex or a suitable alternative. So far none of
your suggestions will solve the problem, which means that perhaps I have not
explained it well enough. Let's look at a real example in the file mom-pdf.mom
in the mom/examples directory, it contains:-

.HEADING 2 NAMED internal "Creating internal links"

.PP
Furthermore, \*[cod]NAMED\|\*[codx] stores the text of the
heading for use later on when linking to it (see
.PDF_LINK internal SUFFIX ). +
If headings are being numbered, the heading number is prepended.

Which produces what is shown in the attached png file. However, if this was
written by a greek person (or google translate!) it might look more like:-

.HEADING 2 NAMED εσωτερικό "Δημιουργία εσωτερικών
συνδέσεων"

.PP
Επιπλέον, \*[cod]NAMED\|\*[codx] αποθηκεύει το
κείμενο του επικεφαλίδα
για χρήση αργότερα κατά τη σύνδεση με
αυτήν (βλ
.PDF_LINK εσωτερικό SUFFIX ). +
Εάν οι επικεφαλίδες αριθμούνται,
προηγείται ο αριθμός της επικεφαλίδας.

In either case the string at the end of the HEADING line has to be available
(using the .PDF_LINK key) so that the "+" symbol can be replaced by the given
text. This means that whatever is given as the NAMED  has to be used as
part of the array which holds the heading strings and for text converted to
\[u] form this would not be a legal identifier name, hence the need to
munge it into something acceptable which can be reconstituted.

Your example using \A'' is not helpful since it would reject any non-latin
language being used as a NAMED .

> No, I accept your premise that the main driver behind "stringhex" was this:
>
> > The problem lies in the original pdfmark API, if you look at the
pdfmark.pdf you will see that in the sections describing .pdfhref M and
.pdfhref L which both refer to a "dest-name" and "descriptive text", it says
that if a dest-name is not given the first word in the description is used as
the dest-name.
>
> I appreciate your explanation.  If the problem was with the pdfmark API,
then let's fix the pdfmark API.
>
> In particular, this:
>
> > if a dest-name is not given the first word in the description is used as
the dest-name
>
> ...strikes me a short-sighted, especially without any validation going on. 
A textual description of a hyperlink/bookmark might contain all sorts of crazy
stuff.  (Like Cyrillic or CJK characters or, worse, motion or type-size or
font-selection escape sequences.)

The pdfmark API was around well before I wrote gropdf, so I just had to
support it.

What about embedded calls to macros (i.e. \*[macro arg]) I deal with that as
well. Here's an example from mom-pdf.mom again:-

.AUTHOR "Deri James" "\*[UP .5p]and" "Peter Schaffter"

Mom's AUTHOR macro predates pdf integration so it made sense to just add:-

.pdfinfo /Author \\$*

(or similar) to the macro. Which produces in the grout file:-

x X ps:exec [/Author (Deri James, \v'-.5p'and, Peter Schaffter,) /DOCINFO
pdfmark

(using the pdf.tmac on my branch) and if you look at the finished pdf you will
see a pristine author attribution in the document properties.

>Assuming that it was going to be a well-behaved sequence of ASCII bytes or
even that one could "sanitize" or "cln" one's way through was a hopeless
notion.  That won't be practical until we have a string iterator and more
conditional expressions that enable the user of an iterator to identify the
type of each item in an iterated string/macro/diversion.  But if I understand
you correctly, we don't need that fancy new stuff to solve the present
problem, with stringhex or without.

No such assumption is made, I expect the data to be dirty, I have removed
an*cln, asciify and never used sanitize. Stringhex is to make the NAMED 
acceptable to be used as a string name. I need none 

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

[Deri James]

Follow-up Comment #12, bug#64285 (group groff):


[comment #10 comment #10:]
> I see very little difference between PS and PDF output for your input
exhibit in comment #9, using bleeding-edge _groff_.

I agree.

> Regarding the topic at issue, I propose that the first and second paragraphs
should look the same, regardless of output device.  I am willing to undertake
the alternation of the "libdriver"-based output drivers to realize this
output, in coordination with changes in _gropdf_ to achieve the same.
> 
> What do you think?

If you think fixing a crazy (but well known and documented) "feature" is more
important than maintaining 30 years of groff compatibility, then it would
probably make sense for you to do the deed (to libdriver and gropdf) in the
same commit. Just comment out the two lines about 3916 (in section dealing
with "Line Thickness "):-

$poschg=1;
$xpos+=$lwidth;

And test with the code in comment #9. Both paragraphs should be the same, and
with no unusual gap later in the first lines.



___

Reply to this item at:

  

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

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[Deri James]

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

Bug #64484 is marked as fixed. I already have a reliable way to pass byte
sequences in device control commands, .stringhex. This bug was previously
named "warning messages when using special characters in TITLE or AUTHOR" and
the attached cyrillic.pdf shows both the pdf title and author shown with
cyrillics and no warnings. So I would say this one is dependent on bug #65098,
i.e. merge the rest of my branch.

(file #55567)

___

Additional Item Attachment:

File name: cyrillic.pdf   Size:27 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-3f5b69a3b837951a0e5c0b7730ee347c798a8844.tar.gz


___

Reply to this item at:

  

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

[groff] 01/01: Retain plain ascii labels when possible.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit e62b188aacb0669bf45628796dd543992e440047
Author: Deri James 
AuthorDate: Sun Jan 14 13:57:30 2024 +

Retain plain ascii labels when possible.

* src/devices/gropdf/gropdf.pl: Do not use hexed label unless
necessary.

Restores the ability for some pdf viewers to accept "#label" as
suffix to filename.
---
 src/devices/gropdf/gropdf.pl | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 870eca5e8..f0b04909a 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -2002,6 +2002,7 @@ sub Clean
 sub utf16
 {
 my $p=Clean(shift);
+my $label=shift;
 
 $p=~s/\\\[(.*?)\]/FindChr($1,0)/eg;
 $p=~s/\\C($parcln)/FindChr($1,1)/eg;
@@ -2014,6 +2015,8 @@ sub utf16
 unpack "C*", encode('utf16', $p);
 }
 
+return($p) if $label;
+
 $p=~s/(?https://lists.gnu.org/mailman/listinfo/groff-commit

Re: the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

[Deri]

On Thursday, 11 January 2024 23:04:02 GMT Tadziu Hoffmann wrote:
> > For people producing greek documents who wish to use eqn,
> > I did some testing, using the Tinos family of fonts (R, I,
> > B, BI) which include greek glyphs and SS font for gropdf.
> > The attached pdf shows the results with the different
> > fonts colour coded.
> 
> Nice!  How did you do the color coding?

Hi Tadziu,

Woe is me! masterpdfeditor, a lot of time mouse clicking (and 
missing) a drop down colour list.
> 
> > If you want to see the slanted versions for alpha and beta,
> > it is best to set the family to T and select TinosR as the
> > main font.
> 
> But this gives you the Greek characters of the Symbol font.
> Since Tinos also has Greek characters, it would be nice to
> use the italic Tinos Greek for the math.  Could you maybe
> try the trick of telling eqn
> 
>   chartype "letter" \[*a]\[*b]\[*g]\[*d]\[*e]\[*z]
>   chartype "letter" \[*y]\[*h]\[*i]\[*k]\[*l]\[*m]
>   chartype "letter" \[*n]\[*c]\[*o]\[*p]\[*r]\[*s]
>   chartype "letter" \[*t]\[*u]\[*f]\[*x]\[*q]\[*w]
> 
> at the beginning (in the first EQ/EN pair)?
> 
> 
> 
> Attached is my own experiment of using a different Greek font
> (GFS Didot) for the math.  Unfortunately I do not speak Greek,
> so I have no idea whether the text is typeset correctly,
> but I think the Greek typeface looks very nice.
> 
> I did the color coding by inserting color commands into
> the intermediate output wherever a font change occurred.

Brilliant, I wish I had thought of doing that, much easier after I wrote a 
little perl script. I ran it again with your suggestion, setting the greek 
symbols to "letter", (first formula only), looks good to me.

Cheers 

Deri


> The colors are:
> 
>   red:   Roman
>   blue:  Italic
>   green: Symbol
> 
> (The fraction bar is not from a font, but drawn as a line
> while the blue color was active.)



eqn.pdf
Description: Adobe PDF document

[bug #65097] gropdf: one 'ps:' tag is now not processed

[Deri James]

Update of bug#65097 (group groff):

  Status:   Need Info => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Yes. Bjarni's else clause does not catch valid errors, not all ps: tags can be
processed into valid pdf. I support the ones emitted by our pre-processors and
macros (apart from the postscript underline function from mom).


___

Reply to this item at:

  

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

Re: the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

[Deri]

On Thursday, 11 January 2024 00:31:18 GMT Tadziu Hoffmann wrote:
> > The ordering of the S and SS fonts is immaterial here because
> > the C/A/T _had_ no SS font.
> > Nor do I see any of evidence of an "SS" font for _any_ device
> > in Documenter's Workbench 3.3 troff.
> > Barring evidence of pre-groff usage, then, I submit that the
> > slanted symbol font must be a groffism.
> 
> No disagreement here.  Neither the C/A/T nor the APS 5 had an
> SS font.  But both had a symbol font containing upright Greek
> capitals and slanted Greek lowercase letters, specifically
> intended for typesetting mathematical expressions
> (based on a century of established mathematical typesetting
> conventions[*]).
> 
> The SS is a groffism introduced to replicate this behavior
> in a compatible manner without having a symbol font with
> the above properties, in such a way that eqn could simply
> request \(*A or \(*a and troff would automatically provide
> the correct character.
> 
> [*](I'm wondering whether these conventions might not have had
> much older roots, namely in the fonts (Garamond, Didot, Porson)
> historically used to typeset some of the Greek classics,
> which similarly had "roman" uppercase and "italic" lowercase
> Greek letters.)
> 
> > > and nothing needs to be changed.
> > 
> > I disagree, because nroff output is incorrect, failing to render
> > lowercase Greek letters in italics when troff output _does_.
> 
> I see.  Since groff does not provide a usable neqn, I had never
> considered using groff for typesetting math for the terminal.
> (But see below.)
> 
> > sin ( 2 theta ) ~ = ~ 2 ~ sin theta cos theta
> > (Note to self: an eqn full space should render as a space on
> > nroff devices.  File a bug.)
> 
> No bug, simply "set thick_space 100" in eqnrc for the terminal
> devices.
> 
> In addition to this, I'd suggest not to habitually try to
> override the default spacing rules of eqn,
> 
>   sin ( 2 theta ) = 2 sin theta cos theta
> 
> since eqn already inserts thick_space around relations.
> 
> > Further, nothing in eqn documents its sensitivity to the font
> > mounting order when determining the typefaces to be used.
> > In fact that sensitivity overrides explicit configuration!
> 
> I'd assume this is a good (= flexible) thing.  Eqn requests
> character "\(*h" (= theta), and troff provides this, from
> whatever font the user has supplied that contains this
> character.
> 
> > .\" "letter" means "slanted" in GNU eqn
> > .\" This is actually redundant with the default configuration.
> 
>   .EQ
>   chartype letter \(*h
>   sin ( 2 theta ) = 2 sin theta cos theta
>   .EN
>   \(*h
> 
> Interestingly enough, the "chartype letter \(*h" is already
> sufficient to switch the thetas from eqn into italic (or
> rather, underlined) on my terminal, while the \(*h from the
> last line remains normal, i.e., this simple change already
> achieves what your proposed modification is meant to do.  (?)
> 
> (I assume this is because on the utf8 device, the theta is
> provided by a normal text font, whereas in the postscript
> device it comes from the special font.)
> 
> > >   1-4: R, I, B, BI(standard text fonts)
> > >   5:   CW (computer/monospaced)
> > >   6-9: SS, S, ZD, ZDR (special)
> > 
> > Heavens no!  "CW" is a System-V-ism.  We have CR, CI, CB, and CBI.
> 
> Yes, but it explains why there are 5 empty positions in the
> "fonts" declaration before SS, S, ZD, and ZDR.  :-)

Hi Tadziu,

For people producing greek documents who wish to use eqn, I did some testing, 
using the Tinos family of fonts (R, I, B, BI) which include greek glyphs and 
SS font for gropdf. The attached pdf shows the results with the different 
fonts colour coded. If you want to see the slanted versions for alpha and 
beta, it is best to set the family to T and select TinosR as the main font.

Cheers 

Deri


eqn.pdf
Description: Adobe PDF document

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

[Deri James]

Follow-up Comment #22, bug#63074 (group groff):

Whew, rather a lot to cover!

First the original "bug" was "fixed" by including -f U-T in the command.

Next it became a wish to include non-latin character in the bookmarks. This is
now working on my branch, waiting for Branden's integration.

Then it became a discussion on Branden's for iterator being used as a
replacement for stringhex, and using it to send arbitrary bytes in device
control commands, and his recent discovery that you can already do this. My
statement in 2022 (see comment #11):-

"If I dropped the .asciify from pdf.tmac it would mean all the \[u]
strings would reach the post processor gropdf, which could then assemble a
UTF-16 string from the hex numbers."

Which is exactly what I have done in the new pdf.tmac/gropdf.

I think Branden has not fully grasped the reason why stringhex is required.
The problem lies in the original pdfmark API, if you look at the pdfmark.pdf
you will see that in the sections describing .pdfhref M and .pdfhref L which
both refer to a "dest-name" and "descriptive text", it says that if a
dest-name is not given the first word in the description is used as the
dest-name.

The macros create a string like:-

.ds pdf:look(\\*[dest-name]) descriptive text

Since descriptive text can include any groff escape this means that dest-name
may also include any groff escape occurring in the first word. The reason it
creates these string registers is to support mom features such as:-

.HEADING 1 NAMED Гуляйпольщина "Гуляйпольщина"
Гуляйпольщина (укр. Гуляйпольщина) или
Махновщина, также Вольная
Территория — повстанческий район в
Северном Приазовье в период
Гражданской войны 1918—1921 гг.
.PP
And so it goes on.
.PDF_LINK Гуляйпольщина PREFIX ( SUFFIX ) "see: +"

Where the "+" is replaced by the contents of the string register
pdf:look(Гуляйпольщина), which would actually be a string of
\[u] nodes, so would generate an error. This is what stringhex is for, to
hide the contents so that groff does not see it as a sequence of nodes. The
ideal solution would be to allow string registers to have an attribute (say
"glass") which signals that groff should never try to interpret its contents,
i.e. operate as if the escape mechanism was turned off just for the contents
of that register, and have a way of turning that attribute on/off or an escape
which sets the attribute for the enclosed string.

I don't know if this is helpful, and helps you understand why stringhex is
being used.


___

Reply to this item at:

  

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

Re: [groff] 04/08: ChangeLog: Add entries for Deri's recent changes.

[Deri]

On Monday, 8 January 2024 02:16:40 GMT G. Branden Robinson wrote:
> gbranden pushed a commit to branch master
> in repository groff.

Thank you.




___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

Re: [groff] 04/08: ChangeLog: Add entries for Deri's recent changes.

[Deri]

On Monday, 8 January 2024 02:16:40 GMT G. Branden Robinson wrote:
> gbranden pushed a commit to branch master
> in repository groff.

Thank you.

Re: deri-gropdf-ng branch dependency graph

[Deri]

On Monday, 8 January 2024 03:29:26 GMT G. Branden Robinson 
wrote:
> At 2024-01-07T10:13:44+0000, Deri wrote:
> > Now that Branden has started to incorporate the new gropdf, 
I
> > thought it may help to try to document the dependencies 
between
> > the different file changes. Although the document is 
produced by
> > groff it includes two dot digraph pdfs with just some groff 
text
> > over the top. The digraph data comes from an "in memory" 
database
> > I wrote once, very micky mouse, but useful for displaying
> > relationship in a small data set.
> 
> Thanks, Deri!  This is really helpful.  Of course the idea is 
to
> invalidate this graph as quickly as we can, but there is 
already one
> stale arc in it (or perhaps a missing arc and node).
> 
> The "pdf.tmac" changes necessary to support the 
`pdfpagenumbering`
> convenience macro _are_ merged to master as of a few days ago.  
I
> therefore cherry-picked "beneath the file level", if you will.  
Mainly
> because it made sense to do so for this feature.
> 
> This graph is really nice because it enables me to find the 
leaf nodes
> and therefore where the most tempting next candidates for
> merge/cherry-picking are.
> 
> And sure enough it appears that the "stringhex" feature is 
most remote
> leaf I need to be looking at, so I'll be needing to put some 
brain
> cycles into what I think a good alternative would be.
> 
> Regards,
> Branden

Hi Branden,

I have added a new table to give more merge information, the 
digraph now looks like the attached.

I will comment on your alternative in bug #65137.

Cheers 

Deri

PS This is what I feed to the program which produces the 
digraph:-

File{gropdf}.Provides:=[Font Subsetting More than 256 glyphs
Produces v1.7 PDF spec]
File{gropdf}.Merged:=Merge{7256dfb9f}
Merge{7256dfb9f}.Date:=04/01/2024
File{pdf.tmac}.Provides:=[.pdfpagenumbering 
UTF-16.Bookmarks]
File{pdf.tmac}.Merged:=[Merge{8dc1df406}]
File{pdf.tmac}.Depends:=[File{gropdf}   File{input.cpp}]
File{input.cpp}.Provides:=striinghex
File{input.cpp}.Merged:=No
Feat{UTF-16.Bookmarks}.Requires:=[File{pdf.tmac}File{om.tmac}   
File{afmtodit.pl}]
File{om.tmac}.Provides:=Mom CJK Bookmarks
File{om.tmac}.Merged:=No
File{om.tmac}.Depends:=File{input.cpp}
File{afmtodit.pl}.Provides:=Extra column for UTF-16 Bookmarks
File{afmtodit.pl}.Merged:=No
File{an.tmac}.Provides:=[MT/ME  UR/UE   UTF-16 Bookmarks]
File{an.tmac}.Merged:=No
Feat{groff-man-pages.pdf}.Requires:=[File{an.tmac}  
File{anmark.tmac}   File{GMPfront.t}File{doc.am}
File{pdfmom.pl}]
File{anmark.tmac}.Provides:=[PDF .MR (intra-page links)]
File{anmark.tmac}.Merged:=No
File{GMPfront.t}.Provides:=Front Page of Book
File{GMPfront.t}.Merged:=No
File{GMPfront.t}.Depends:=File{doc.am}
File{doc.am}.Provides:=Inter page links
File{doc.am}.Merged:=No
File{pdfmom.pl}.Provides:=--roff satisfy forward references for 
non mom scripts
File{pdfmom.pl}.Merged:=No
Feat{Font.Subsetting}.Requires:=File{gropdf}
File{gropdf.1}.Provides:=Gropdf man page
File{gropdf.1}.Merged:=Merge{8dc1df406}
File{gropdf.1}.Depends:=[File{gropdf}   File{pdf.tmac}]
Feat{PDF Page Numbering}.Requires:=[File{gropdf}File{gropdf.1}  
File{pdf.tmac}]
Merge{8dc1df406}.Date:=03/01/2024
Merge{8dc1df406}.Notes:=.pdfpagenumber only



Features.pdf
Description: Adobe PDF document

[groff] 02/02: Misplaced TOC in mom.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit d27c4644a098855051322a073a313fda165d4eaf
Author: Deri James 
AuthorDate: Sun Jan 7 20:14:34 2024 +

Misplaced TOC in mom.

See https://lists.gnu.org/archive/html/groff/2024-01/msg00015.html

* src/devices/gropdf/gropdf.pl: Remove incorrect line.
---
 src/devices/gropdf/gropdf.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 14b7b3312..79dde070a 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -1802,7 +1802,7 @@ sub do_x
else
{

($curoutlev,$curoutlevno,$thislev)=(@{$outlines[$pginsert]});
-   $curoutlevno--;
+#  $curoutlevno--;
}
}
}

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/02: Fix for including pdf v1.7 files.

[Deri James]

deri pushed a commit to branch master
in repository groff.

commit 7c0358816253817a3594be6402c4b9b7e68db01d
Author: Deri James 
AuthorDate: Sun Jan 7 19:51:35 2024 +

Fix for including pdf v1.7 files.

PDF 1.5 introduced object type ObjStm which can contain a bunch of
objects in its own compressed stream, but there is a restriction
that if an object has its own stream it cannot be included into
the ObjStm (i.e. no stream within stream). Gropdf has supported this
for some years, but it has come to light that some pdfs have a
"skeleton" object which contains the stream and the rest of the
object is held in the ObjStm stream.

Also fix incorrect application of patch in bug #65112.

* src/devices/gropdf/gropdf.pl: If a skeleton object exists at
the top-level and in an ObjStm stream, the two objects should be
merged.
---
 src/devices/gropdf/gropdf.pl | 57 +---
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 3f70a4263..14b7b3312 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -2413,6 +2413,7 @@ sub LoadPDF
 my (@pdfwds)=split(' ',$pdftxt);
 my $wd;
 my $root;
+my @ObjStm;
 
 while ($wd=nextwd(\@pdfwds),length($wd))
 {
@@ -2424,24 +2425,7 @@ sub LoadPDF
$pdf->[$curobj]->{OBJ}=ParsePDFObj(\@pdfwds);
my $o=$pdf->[$curobj];
 
-   if (ref($o->{OBJ}) eq 'HASH' and exists($o->{OBJ}->{Type}) and 
$o->{OBJ}->{Type} eq '/ObjStm')
-   {
-   LoadStream($o,$pdf);
-   my $pos=$o->{OBJ}->{First};
-   my $s=$o->{STREAM};
-   my @o=split(' ',substr($s,0,$pos));
-   substr($s,0,$pos)='';
-   push(@o,-1,length($s));
-
-   for (my $j=0; $j<=$#o-2; $j+=2)
-   {
-   my @w=split(' ',substr($s,$o[$j+1],$o[$j+3]-$o[$j+1]));
-   $pdf->[$o[$j]]->{OBJ}=ParsePDFObj(\@w);
-   }
-
-   $pdf->[$curobj]=undef;
-   }
-
+push(@ObjStm,$curobj) if (ref($o->{OBJ}) eq 'HASH' and 
exists($o->{OBJ}->{Type}) and $o->{OBJ}->{Type} eq '/ObjStm');
$root=$curobj if ref($pdf->[$curobj]->{OBJ}) eq 'HASH' and 
exists($pdf->[$curobj]->{OBJ}->{Type}) and $pdf->[$curobj]->{OBJ}->{Type} eq 
'/XRef';
}
elsif ($wd eq 'trailer' and !exists($pdf->[0]->{OBJ}))
@@ -2454,6 +2438,25 @@ sub LoadPDF
}
 }
 
+foreach my $ObjStm (@ObjStm)
+{
+LoadStream($pdf->[$ObjStm],$pdf);
+my $pos=$pdf->[$ObjStm]->{OBJ}->{First};
+my $s=$pdf->[$ObjStm]->{STREAM};
+$s=~s/\%.*?$//m;
+my @o=split(' ',substr($s,0,$pos));
+substr($s,0,$pos)='';
+push(@o,-1,length($s));
+
+for (my $j=0; $j<=$#o-2; $j+=2)
+{
+my @w=split(' ',substr($s,$o[$j+1],$o[$j+3]-$o[$j+1]));
+
$pdf->[$o[$j]]->{OBJ}=ObjMerge($pdf->[$o[$j]]->{OBJ},ParsePDFObj(\@w));
+}
+
+$pdf->[$ObjStm]=undef;
+}
+
 $pdf->[0]=$pdf->[$root] if !defined($pdf->[0]);
 my $catalog=${$pdf->[0]->{OBJ}->{Root}};
 my $page=FindPage(1,$pdf);
@@ -2530,6 +2533,22 @@ sub LoadPDF
 return([$xonm,$BBox] );
 }
 
+sub ObjMerge
+{
+my $o1=shift;
+my $o2=shift;
+
+return $o1 if !defined($o2);
+return $o2 if !defined($o1);
+
+foreach my $k (keys %{$o2})
+{
+$o1->{$k}=$o2->{$k};
+}
+
+return $o1;
+}
+
 sub LoadStream
 {
 my $o=shift;
@@ -4736,7 +4755,7 @@ sub subs_call
{
$c[$#c-4]->[0]=MarkSub("#$c[$#c-4]->[0]") if ($c[$#c-4]->[1]);
}
-   elsif ($n2==16)  # seac
+   elsif ($n2==6)   # seac
{
my $ch=$StdEnc{$c[$#c-2]->[0]};
my $chf;

___
Groff-commit mailing list
Groff-commit@gnu.org
https://lists.gnu.org/mailman/listinfo/groff-commit

deri-gropdf-ng branch dependency graph

[Deri]

Now that Branden has started to incorporate the new gropdf, I 
thought it may help to try to document the dependencies between 
the different file changes. Although the document is produced by 
groff it includes two dot digraph pdfs with just some groff text 
over the top. The digraph data comes from an "in memory" database 
I wrote once, very micky mouse, but useful for displaying 
relationship in a small data set.

Cheers

Deri

Features.pdf
Description: Adobe PDF document

Re: Auto-relocated TOC in wrong place in pdf outlines

[Deri]

On Saturday, 6 January 2024 19:19:59 GMT Peter Schaffter wrote:
> gropdf from groff 1.23.0.689-8d320-dirty breaks the mom macro
> AUTO_RELOCATE_TOC.  The physical page order and numbering are
> correct after relocation, but the pdf panel places the TOC at 
the
> top of the outline.  See attached .pdf and .mom files.  1.23.0 
works
> fine.  Not sure if mom needs tweaking or if it's a gropdf bug.

Mea Culpa. Here's the fix.

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/
gropdf.pl 
index e26bc6b43..601819c55 100644 
--- a/src/devices/gropdf/gropdf.pl 
+++ b/src/devices/gropdf/gropdf.pl 
@@ -1808,7 +1808,7 @@ sub do_x 
else 
{ 
($curoutlev,$curoutlevno,
$thislev)=(@{$outlines[$pginsert]}); 
-$curoutlevno--; 
+#$curoutlevno--; 
} 
} 
    }


Cheers

Deri

[bug #65115] [PATCH] BMI and BMR definitions are switched in Foundry.in for the U foundry

[Deri James]

Update of bug#65115 (group groff):

  Status:   Fixed => Need Info  
 Assigned to:    deri => gbranden   
 Open/Closed:  Closed => Open   

___

Follow-up Comment #6:

The fix which got pushed just swapped BMI/BMR, the patch in comment #1 is a
little more subtle - the final two entries on the two lines need to be
unswapped.


___

Reply to this item at:

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

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

[bug #65115] [PATCH] BMI and BMR definitions are switched in Foundry.in for the U foundry

[Deri James]

Follow-up Comment #4, bug#65115 (group groff):


> I can push this fix with others later today if Deri doesn't beat me to it.

I'm unlikely to win that race. I did take part in the UK National Spastic
Games, in my youth, representing the South-East region. Well before
paralympics. Won 3 golds and 6 silvers, which sounds unbelievably good until I
tell you another chap in my disability group got 6 golds and 3 silvers, and
the fact that the SE team lost by one gold medal caused the team manager to
blame the loss solely on me.


___

Reply to this item at:

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

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

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

[Deri James]

Update of bug#65112 (group groff):

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

___

Follow-up Comment #10:

No, it was not intentional. What sometimes happens is that I open the bug
page, then compose a reply in dasher (which could take quite a while) and
paste it to the open page, meanwhile someone changes the status fields and
when I submit my reply it uses the values they had when I opened the page.


___

Reply to this item at:

  

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

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

[Deri James]

Update of bug#65112 (group groff):

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

___

Follow-up Comment #8:

On Bookworm I did this:-

derij@raspberrypi5:~ $ dpkg -s fonts-urw-base35
Package: fonts-urw-base35
Status: install ok installed
Priority: optional
Section: fonts
Installed-Size: 15558
Maintainer: Debian Fonts Task Force 
Architecture: all
Multi-Arch: foreign
Version: 20200910-7
Replaces: gsfonts (<< 2:20200910-2~), gsfonts-x11 (<< 2:20200910-2~)
Depends: xfonts-utils
Suggests: fonts-freefont-otf | fonts-freefont-ttf, fonts-texgyre
Breaks: gsfonts (<< 2:20200910-2~), gsfonts-x11 (<< 2:20200910-2~)
Conffiles:
 /etc/X11/fonts/Type1/fonts-urw-base35.alias 32ee9a005b7c7a089bdd5a5c4ee19c89
 /etc/X11/fonts/Type1/fonts-urw-base35.scale 1027533ffa7574e6b30b528d72287445
 /etc/ghostscript/fontmap.d/10fonts-urw-base35.conf
a97fb8d980202e59cc253c9c21bb2d30
Description: font set metric-compatible with the 35 PostScript Level 2 Base
Fonts
 A commercial-quality set of PostScript Type 1 fonts, metric-compatible
 with the 35 PostScript Language Level 2 Base Fonts. This package contains
 outlines in .t1 format and metrics in .afm format of the following fonts:
 .
  C059
  D05L
  Nimbus Mono PS
  Nimbus Roman
  Nimbus Sans
  Nimbus Sans Narrow
  P052
  Standard Symbols PS
  URW Bookman
  URW Gothic
  Z003
 .
 This package also makes the fonts available to an X server under both
 their "urw" names and via fonts.alias under the official "adobe" names.
 .
 Extensive remakes of these fonts in the OpenType format are available in the
 GUST TeX Gyre collection in the fonts-texgyre package. The Cyrillic glyphs
 added to the now obsolete urwcyr fork of these fonts have been merged into
 the GNU FreeFont collection available in the fonts-freefont-otf or
 fonts-freefont-ttf packages.
Homepage: https://github.com/ArtifexSoftware/urw-base35-fonts




___

Reply to this item at:

  

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

[bug #65115] BMI and BMR definitions are switched in Foundry.in for the U foundry

[Deri James]

Update of bug#65115 (group groff):

  Status:None => Fixed  
 Summary: U-BMI and U-BMR show switched font names in 
fonts_{n,x}.pdf => BMI and BMR definitions are switched in Foundry.in for the
U foundry

___

Follow-up Comment #1:

Thanks for this Bjarni. Here's the fix:-

diff --git a/font/devpdf/Foundry.in b/font/devpdf/Foundry.in
index e5aba655e..ec10cbb0e 100644
--- a/font/devpdf/Foundry.in
+++ b/font/devpdf/Foundry.in
@@ -88,8 +88,8 @@
AI|N|i|text.map|text.enc|URWGothic-BookOblique.t1!URWGothic-BookOblique!URWGothi
 
AR|N|r|text.map|text.enc|URWGothic-Book.t1!URWGothic-Book!URWGothicL-Book!a010013l.pfb
 
BMB|N|r|text.map|text.enc|URWBookman-Demi.t1!URWBookman-Demi!URWBookmanL-DemiBold!b018015l.pfb
 
BMBI|N|i|text.map|text.enc|URWBookman-DemiItalic.t1!URWBookman-DemiItalic!URWBookmanL-DemiBoldItal!b018035l.pfb
-BMI|N|i|text.map|text.enc|URWBookman-Light.t1!URWBookman-Light!URWBookmanL-LighItal!b018032l.pfb
-BMR|N|r|text.map|text.enc|URWBookman-LightItalic.t1!URWBookman-LightItalic!URWBookmanL-Ligh!b018012l.pfb
+BMI|N|i|text.map|text.enc|URWBookman-LightItalic.t1!URWBookman-LightItalic!URWBookmanL-LighItal!b018032l.pfb
+BMR|N|r|text.map|text.enc|URWBookman-Light.t1!URWBookman-Light!URWBookmanL-Ligh!b018012l.pfb
 
CB|N|nr|text.map|text.enc|NimbusMonoPS-Bold.t1!NimbusMonoPS-Bold!NimbusMonL-Bold!n022004l.pfb
 
CBI|N|ni|text.map|text.enc|NimbusMonoPS-BoldItalic.t1!NimbusMonoPS-BoldItalic!NimbusMonL-BoldObli!n022024l.pfb
 
CI|N|ni|text.map|text.enc|NimbusMonoPS-Italic.t1!NimbusMonoPS-Italic!NimbusMonL-ReguObli!n022023l.pfb




___

Reply to this item at:

  

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

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

[Deri James]

Follow-up Comment #6, bug#65112 (group groff):

Apologies for the brevity, it was one of those "go to bed and wake up bolt
upright with the answer", just wanted you to confirm the fix was good. Now the
explanation:-

Type 1 fonts have a section of numbered subroutines which can be called from
the actual glyph definition, I have seen over 1000 in some large fonts. So,
when you are subsetting you need to subset (and renumber) any relevent
subroutines used by the glyph you are subsetting.

What went wrong (only with your version of the Symbol font) was that the
required subroutines were not making it to the subsetted font. Usually
including a subroutine is simple: a number is pushed onto the stack and
"callsubr" is called, but in this font it users this form:-

22 1 3 callothersubr
pop
callsubr

The number popped is actually 22 so it is this subroutine which needs to be
included.

It is interesting that of the 4 different versions of the Symbol font I looked
at, it is only the oldest (yours) which used this form:-

Your version:- (s05l.pfb)

%!PS-AdobeFont-1.0: StandardSymL 001.005
%%CreationDate: Thu Oct 21 1999
% Copyright URW Software, Copyright 1997 by URW
% URW Software, Copyright 1997 by URW
% See the file COPYING (GNU General Public License) for license conditions.

Bookworm:- (StandardSymbolsPS)

%!PS-AdobeFont-1.0: StandardSymbolsPS 2.00
%%CreationDate: Tue May 31 2016
% Copyright URW Software, Copyright 2015 by URW
% URW Software, Copyright 2015 by URW

Buster?:- (StandardSymbolsPS)

%!PS-AdobeFont-1.0: StandardSymbolsPS 2.00
%%CreationDate: Tue May 31 2016
% Copyright URW Software, Copyright 2015 by URW
% URW Software, Copyright 2015 by URW

Mageia 9:- (s05l.pfb)

%!PS-AdobeFont-1.0: StandardSymL 001.005_%{version}-%{release}
%%Title: StandardSymL
%Version: 001.005_%{version}-%{release}
%%CreationDate: Wed Mar 30 23:15:51 2022
%%Creator: Unknown
%Copyright: Copyright URW Software, Copyright 1997 by URW
% Generated by FontForge 20201107 (http://fontforge.sf.net/)

I don't know if this will make it onto the website, but it should send the
email. I hope this helps you write a commit message.


___

Reply to this item at:

  

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

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

[Deri James]

Follow-up Comment #5, bug#65112 (group groff):

Try this.

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index e26bc6b43..d55bc1e00 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -4733,7 +4733,11 @@ sub subs_call
 my $n2=$charstr->[++$j];
 push(@c,[$n2,0]);
 
-if ($n2==6) # seac
+if ($n2==16)# callothersub
+{
+$c[$#c-4]->[0]=MarkSub("#$c[$#c-4]->[0]") if
($c[$#c-4]->[1]);
+}
+elsif ($n2==6) # seac
 {
 my $ch=$StdEnc{$c[$#c-2]->[0]};
 my $chf;




___

Reply to this item at:

  

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

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

[Deri James]

Follow-up Comment #3, bug#65112 (group groff):

Ooh, a proper bug. Please can you look in font/devpdf/download file and send
me whichever file is assigned to the Symbol font. I can't duplicate the
problem with three different versions of the Symbol font file but you may have
a fourth. I have a suspicion of where the bug probably lies but I need a font
which causes it.


___

Reply to this item at:

  

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