[bug #65910] [pic] some dashed ellipse sizes produce irregular dashes

[Deri James]

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

I've spent some time on this but I don't think I have got very far. I have
written some debug code in gropdf to try and show what is happening. Attached
are examples. I hope the patterns may mean something to someone more
mathematical than I.

command: test-groff -Tpdf -p -P-pa3 Morten/t2.t > 4x3-debug.pdf


(file #56206, file #56207, file #56208, file #56209)

___

Additional Item Attachment:

File name: 4x3-debug.pdf  Size: 6KiB


File name: 8x3-debug.pdf  Size: 7KiB


File name: 4x1.5-debug.pdfSize: 7KiB


File name: gropdf Size: 106KiB



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-ea9941c77950eae296736296815751ff89e2461c.tar.gz


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[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


File name: grog_U-TR.png  Size: 36KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at

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

  

___
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



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:

  

___
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

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

[Deri James]

Update of bug#64155 (group groff):

 Assigned to:deri => gbranden   

___

Follow-up Comment #21:

Hi Branden,

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

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

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

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

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




___

Reply to this item at:

  

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

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

[Deri James]

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

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

test-groff

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

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

after install (groff)

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

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




___

Reply to this item at:

  

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

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

[Deri James]

Update of bug#64155 (group groff):

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

___

Follow-up Comment #18:

Why is this happening?

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

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

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

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

+verbatim+



___

Reply to this item at:

  

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

[bug #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/

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

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

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

[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

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

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

[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

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

  

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

  

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

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

[Deri James]

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

Please can you attach the pdf produced, but first could you try the run with
-P-e. Without this, all the fonts used (except symbol slanted) are base fonts
so no fonts are embedded (so no subsetting either), and its pot luck if your
pdf viewer picks a font which contains all the glyphs required.

I have run groff_char.7 here:-

[derij@pip build (deri-gropdf-ng)]$ ./test-groff man/groff_char.7 -Tpdf -t
-man -P-e |okular -
troff:man/groff_char.7:1046: warning: special character '.j' not defined
troff:man/groff_char.7:1468: warning: special character 'vA' not defined
troff:man/groff_char.7:1598: warning: special character 'bs' not defined
troff:man/groff_char.7:1771: warning: special character '-+' not defined
troff:man/groff_char.7:1820: warning: special character 'coproduct' not
defined
troff:man/groff_char.7:1915: warning: special character '+e' not defined
/home/derij/groff-git/groff/build/gropdf:man/groff_char.7: warning: Using
nospace mode for font 'EURO'
/home/derij/groff-git/groff/build/gropdf:man/groff_char.7: warning: unable to
embed font file for 'Symbol-Slanted' (SS) (missing entry in 'download' file?)

Along with the known missing glyphs there is the warning about EURO (dealt
with separately) and I also have not added SlantedSymbol to the download file.
I've attached a png showing the fonts used by okular.

(file #55520)

___

Additional Item Attachment:

File name: Fonts.png  Size:96 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-739efcb88d2528965d3c4e746313c5dd0a172b9e.tar.gz


___

Reply to this item at:

  

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

[bug #65111] [gropdf] "warning: Using nospace mode for font 'EURO'"

[Deri James]

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

As I have documented elsewhere gropdf has to behave a little differently if a
particular font does not define a space glyph. This is because it can use a
slightly more compact format if the font defines "space" or "u0020" as a
glyph. In a "Hello World" example the difference is "(Hello World)" (glyph
defined) and "(Hello) move horizontal (World)" (glyph undefined). The distance
moved is set by troff, I assume this is the purpose of spacewidth in the groff
font. Some CJK fonts also don't have a space glyph. It is just a warning, and
was useful in debugging, to know gropdf had switched to a slightly less
efficient output format, the message could be removed, although knowing which
mode gropdf was operating in if I am debugging a user's issue could be useful.


___

Reply to this item at:

  

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

[bug #65098] merge branch deri-gropdf-ng to master

[Deri James]

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

Red Tree

I assume you have built my branch at some point, any Titian hues?

Special Pleading (MR)
=
You were correct I was bending a general case to try to fit a special case.

For Iterator

I can see many uses for this mechanism. One of my design goals for the new
gropdf was to allow non-latin languages to use groff to use all the pdf
features available to latin languages, particular using the currently
available fonts which cover a wide range of languages. The size of these fonts
are huge so the current practice of embedding the entire font is probably a
non-starter, hence the need for subsetting and being able to use more than 256
glyphs from the font.

Part of this requires unicode to be passed to gropdf, to cater for code such
as:-

.pdfbookmark 1 "Chinese text"

Preconv will have converted the chinese text to a group of \[u] which in
turn is converted by troff to nodes, so the for loop will set N for each
chinese character and I end up with an empty string. The same problem occurs
if chinese is used to set a named destination within the pdf, but it is worse
because the destination name is also used in the pdf:look array and if each
call results in the empty string, it will not work.

So, I have a few doubts it will completely remove the need for stringhex, but
you may find a way.

Cheers 

Deri



___

Reply to this item at:

  

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

[bug #65098] merge branch deri-gropdf-ng to master

[Deri James]

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

Dealing with gropdf.pl separately, I have cobbled together a document which
may help you in the task. It is a list of all the diffs with a following
comment which describes what the changes accomplish. One way of handling this
is to introduce each file as a separate commit and include a description of
what the changes in each file achieve (from the embedded comments). Note that
I have removed from the diff changes to master since deri-gropdf-ng was
branched.

Gropdf.pl is a slightly different kettle of fish, it has grown by over 25%
(over 1000 lines), and the number of new lines of code is more than that
because there has been significant code deletion as well. You may remember
there was a code freeze for over 6 months before 1.23.0 and after 3 months I
got an "itch" and wrote the new version, you then suggested I start a new
branch, so I slammed the new version into that. I have already written about
the two main drivers for the change: making gropdf subset fonts in the pdf,
and switching from a word based input model to an input stream of glyph names
(you said that my description  was helpful). So just as adding a new program
to a project does not lead to a raft of commits detailing every new function
in the code, but rather the commit would describe what new features the new
program adds to the project, it would probably be best to treat the new gropdf
in a similar way - describing what has been added to groff's capabilities.

I'm afraid I did not get your red tree reference, my only experience with
red/black trees is in "binary chop" and there is a self balancing algorithm
for that.

Maintainability is more concerned with understanding the code as it is, the
git log may help you understand how it got there but understanding what the
code actually achieves can only be understood by reading the code. For example
if I want to know what ps_output::put_string does then git log tells me that
isascii got changed to is_ascii in 1994, but it tells me nothing about what
the routine does. Maintainability of code is far more about the quality of
code and the knowledge and experience of the person looking at the code.

I've had a rethink about an.tmac and stripped out all the stuff added to MR,
since it was only there to support internal links to other pages within a man
page book (such as groff_man_pages.pdf), and I have found an alternative way
of achieving the same thing without touching an.tmac. All that is left is
stuff to make it work with the new gropdf, don't use \E* do use \\*, and add
support for UR/UE and MT/ME.

I know you are working on/planning your for iterator, but please don't hold up
merging my branch to wait for it, since in its current state it all works
without it. When your code is complete we can revisit which parts are helpful
for gropdf. Just out of interest: what does ch contain if N is set (i.e. it is
a node).



(file #55511)

___

Additional Item Attachment:

File name: diff.html  Size:59 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-2b478236128ba85c00d8a2ecb8cf6141b8b94a05.tar.gz


___

Reply to this item at:

  

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

[bug #65095] gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

[Deri James]

Update of bug#65095 (group groff):

  Status:None => Invalid
 Assigned to:None => deri   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

The difference in number of pages is because devpdf includes the "U" foundry
fonts. It is a pity the glyph listings don't include glyphs above 271!


___

Reply to this item at:

  

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

[bug #65098] Merging branch deri-gropdf-ng with master

[Deri James]

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

 Summary: Merging branch deri-gropdf-ng with master
   Group: GNU roff
   Submitter: deri
   Submitted: Sat 30 Dec 2023 11:01:14 PM UTC
Category: Core
Severity: 1 - Wish
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: gbranden
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Sat 30 Dec 2023 11:01:14 PM UTC By: Deri James 
I thought it might be helpful to have a place where we can see progress on
this.

I have noticed some cherry picking from the branch happening so I'm hopeful
there will be movement on the rest. If you are too snowed under at the moment
just assign it back to me and I can do the merge of the rest.







___

Reply to this item at:

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

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

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

[Deri James]

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

If I look at the output produced by:-

pdfmom ../doc/automake.mom -P-d | less

I can see:-

% x X ps: exec 0 setlinejoin
%% V12000
0 j
% V12000
% H72000
% x X ps: exec 0 setlinecap
%% wh2500
0 J

So the "0 j" has been emitted in response to the 0 setlinejoin, and "0 J" for
the 0 setlinecap. So the code is working as expected. Before the last change
to accomodate both on the same command the code was essentially one switch
statement dealing with all the \X'ps: ...' commands which gropdf is designed
to handle, documented in gropdf.1. Since the change, it is now two switch
statements, an else clause at the end of the second switch will fire even if
the command was handled as part of the first switch.

Even without the split into two switches, an else clause to trap unhandled
\X'ps: ...' commands is futile because the grops man page documenting the
device control commands would allow complete postscript programs to be passed
to the printer, which a pdf file would not understand.

An example is this (which mom passes as a \Y'ps: ...' command):-

% x X ps: def
%% +grops begin
%% +/decornone { grops begin /X { } def /Y { } def /y2 -1 def end } def
%% +/decorline { grops begin u neg /uld exch def u /ulw exch def
%% + /X { currentpoint /y0 exch def /x0 exch def } def
%% + /Y { currentpoint /y1 exch def /x1 exch def
%% +  drawline /x2 x1 def /y2 y1 def } def end } def
%% +/drawline { gsave ulw setlinewidth 0 setlinecap x1 y1 uld sub moveto
%% +y2 y0 eq { x2 y2 } { x0 y0 } ifelse uld sub lineto stroke
%% +grestore } def
%% +decornone
%% +/uld 0 def
%% +/ulw 0 def
%% +/A { X show Y } def
%% +/B { 0 SC 3 -1 roll X widthshow Y } def
%% +/C { 0 exch X ashow Y } def
%% +/D { 0 exch 0 SC 5 2 roll X awidthshow Y } def
%% +/E { 0 rmoveto X show Y } def
%% +/F { 0 rmoveto 0 SC 3 -1 roll X widthshow Y } def
%% +/G { 0 rmoveto 0 exch X ashow Y } def
%% +/H { 0 rmoveto 0 exch 0 SC 5 2 roll X awidthshow Y } def
%% +/I { 0 exch rmoveto X show Y } def
%% +/J { 0 exch rmoveto 0 SC 3 -1 roll X widthshow Y } def
%% +/K { 0 exch rmoveto 0 exch X ashow Y } def
%% +/L { 0 exch rmoveto 0 exch 0 SC 5 2 roll X awidthshow Y } def
%% +/M { rmoveto X show Y } def
%% +/N { rmoveto 0 SC 3 -1 roll X widthshow Y } def
%% +/O { rmoveto 0 exch X ashow Y } def
%% +/P { rmoveto 0 exch 0 SC 5 2 roll X awidthshow Y } def
%% +/Q { moveto X show Y } def
%% +/R { moveto 0 SC 3 -1 roll X widthshow Y } def
%% +/S { moveto 0 exch X ashow Y } def
%% +/T { moveto 0 exch 0 SC 5 2 roll X awidthshow Y } def
%% +end
%% +

This is pure postscript code which is not part of the pdf standard, so all
gropdf can do is consume it, on the assumption it will mean something if the
same document is run through grops.


___

Reply to this item at:

  

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

[bug #65094] gropdf: hdtbl, picture "gnu.eps" is now missing in "mixed_pickles.pdf"

[Deri James]

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

EPS files are not supported in pdf files, and gropdf only supports embedding
pdf files (in the same way as grops only supports embedding eps files). There
is a macro PDFPIC which does a similar job as PSPIC.

I changed the mixed-pickles.roff to this code:-

.PDFPIC -I -\\n[.l]u penguin.pdf
.sp .5
.nop pdf image with \fI.PDFPIC\fP

And used this command:-

./test-groff -Tpdf -mhdtbl -U -I ../contrib/mom/examples/
../contrib/hdtbl/examples/mixed_pickles.roff -pet

The result is attached.

(file #55491)

___

Additional Item Attachment:

File name: mixed-pickles.pdf  Size:21 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-ec09902a0a059b4d4d29a6c422be312926e7bc1e.tar.gz


___

Reply to this item at:

  

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

[bug #65095] gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

[Deri James]

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

I used this command:-

./test-groff -Tpdf -mhdtbl -U -dfontpath=font/ -dsopath=../contrib/hdtbl/ 
contrib/hdtbl/examples/fonts_x.roff

In the build directory. Seems to work. (I'm using the deri-gropdf-ng branch,
don't know about 1.23.0)


___

Reply to this item at:

  

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

[groff] 01/01: Bug #65092 rounded corners in hdtbl's color_boxes

[Deri James]

deri pushed a commit to branch deri-gropdf-ng
in repository groff.

commit 2e6d61716710aaca2fff9bf37747a455afff22a5
Author: Deri James 
AuthorDate: Fri Dec 29 23:28:11 2023 +

Bug #65092 rounded corners in hdtbl's color_boxes

The \X'ps: exec ...' for setlinejoin and setlinecap (which hdtbl.tmac
emits as one command) is documented as separate commands in gropdf.1.

* src/devices/gropdf/gropdf.pl: Allow both setlinecap and setlinejoin
to be combined in 1 command.

Thanks to Bjarni Ingi Gislason for the report.
---
 src/devices/gropdf/gropdf.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index e96a2059e..e26bc6b43 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -1382,13 +1382,13 @@ sub do_x
 $stream.="Q\n";
 $InPicRotate=0;
 }
-elsif ($par=~m/exec (\d) setlinejoin/)
+elsif ($par=~m/exec.*? (\d) setlinejoin/)
 {
 IsGraphic();
 $linejoin=$1;
 $stream.="$linejoin j\n";
 }
-elsif ($par=~m/exec (\d) setlinecap/)
+if ($par=~m/exec.*? (\d) setlinecap/)
 {
 IsGraphic();
 $linecap=$1;

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

[bug #62830] [PATCH] [grops] support CJK fonts encoded in UTF16

[Deri James]

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

Just a note to point out that gropdf (in the deri-gropdf-ng git branch)
already handles CJK documents. The attached pdf is an example, you should see
CJK in the pdf bookmarks as well.

(file #55489)

___

Additional Item Attachment:

File name: tanaka.pdf Size:32 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-ec09902a0a059b4d4d29a6c422be312926e7bc1e.tar.gz


___

Reply to this item at:

  

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

[bug #65052] [troff] `cf` behavioral anomalies

[Deri James]

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

The test you are using is a bit strange. The only proper use for these
commands are to include files which are independently movement agnostic. What
I mean is they contain grout which does something completely independent of
the document which calls it. Think of a set of grout commands which moves to
one corner and draws a logo.

The reason is because groff and whichever output driver is used must maintain
a consistent view of the current X/Y position, i.e. where the next glyph or
graphics command will start. If you send "tbaz" to the output driver its
notion of the current X position will be after the "z" but groff, which has
not seen the text "baz", will still think the current X position is where the
"b" starts. This way there be dragons, (and overwriting!).

For this reason, needing to maintain synchronicity with the output driver,
these commands are not very useful. I suspect they are only really meant for
passing stuff like postscript code to grops, but this can be easily achieved
with a \Y'' call.

Issue C/D

This is analogous to using \!, it does not cause a break so gets output
immediately, before whatever has been input for the current line, if you want
to retain proper sequence in the grout you need a .fl before the \!. The
reason baz is missing will become clear if you don't send stderr to
/dev/null.




___

Reply to this item at:

  

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

[groff] 01/03: pdfmarksuspend & pdfmarkresume only if -Tpdf

[Deri James]

deri pushed a commit to branch deri-gropdf-ng
in repository groff.

commit 7ac813810503f0a012767b38db0b769adeab03a0
Author: Deri James 
AuthorDate: Thu Nov 23 00:04:54 2023 +

pdfmarksuspend & pdfmarkresume only if -Tpdf

tmac/an.tmac: Fix for non pdf man use!!
---
 tmac/an.tmac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tmac/an.tmac b/tmac/an.tmac
index d66294873..e8655c0b5 100644
--- a/tmac/an.tmac
+++ b/tmac/an.tmac
@@ -602,7 +602,7 @@ contains unsupported escape sequence
 .  PT
 .  ev
 .  ns
-.  pdfmarkrestart
+.  if '\\*[.T]'pdf' .pdfmarkrestart
 ..
 .
 .\" Schedule a page break when the next output line is written (not
@@ -614,7 +614,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
-.  pdfmarksuspend
+.  if '\\*[.T]'pdf' .pdfmarksuspend
 .  ev an*env-header-and-footer
 .  ie \\n[cR] \
 .ds an*ofoot "\\*[an-pageref]\"

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

[groff] 02/03: Problem processing concatenated dit files (-Z)

[Deri James]

deri pushed a commit to branch deri-gropdf-ng
in repository groff.

commit aa1e2c70eba3fe7adb6cbddbf74764abc21578d1
Author: Deri James 
AuthorDate: Fri Nov 24 16:02:00 2023 +

Problem processing concatenated dit files (-Z)

Normally it is safe to pass concatenated dit files to gropdf,
typically this would be a separate source file which produces a
custom cover and a different source for the body (different macro
set?). Problem occurs if one of the dits uses the same fontno for
a different font. Normally troff allocates TR to #5, but if one
of the dits has been run with the flag "U-T" then U-TR is allocated
to #5.

* src/devices/gropdf/gropdf.pl: Check if "x font # name" has the
same number AND name as a previously registered font, otherwise
reload the font.
---
 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 27a0964f0..45e35d931 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -3140,7 +3140,7 @@ sub LoadFont
 my $fontnm=shift;
 my $ofontnm=$fontnm;
 
-return $fontlst{$fontno}->{OBJ} if (exists($fontlst{$fontno}));
+return $fontlst{$fontno}->{OBJ} if (exists($fontlst{$fontno}) and $fontnm 
eq $fontlst{$fontno}->{FNT}->{name}) ;
 
 my $f;
 OpenFile(\$f,$fontdir,"$fontnm");

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

[groff] 03/03: Fix arc drawing when flag -l used.

[Deri James]

deri pushed a commit to branch deri-gropdf-ng
in repository groff.

commit 5989eda83e6cc399988756ba163ad4c2ad1fc9d9
Author: Deri James 
AuthorDate: Sun Dec 10 20:05:43 2023 +

Fix arc drawing when flag -l used.

* src/devices/gropdf/gropdf.pl: When landscape flag (-l) is given
coordinates for arcs need rotation.
---
 src/devices/gropdf/gropdf.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 45e35d931..e96a2059e 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -3980,7 +3980,14 @@ sub PlotArcSegment
 my @mat=($cos,$sin,-$sin,$cos,0,0);
 my $lw=$lwidth/$r;
 
-$stream.="q $r 0 0 $r $transx $transy cm ".join(' ',@mat)." cm $lw w $x0 
$y0 m $x1 $y1 $x2 $y2 $x3 $y3 c S Q\n";
+if ($frot)
+{
+   $stream.="q $r 0 0 $r $transy $transx cm ".join(' ',@mat)." cm $lw w 
$y0 $x0 m $y1 $x1 $y2 $x2 $y3 $x3 c S Q\n";
+}
+else
+{
+   $stream.="q $r 0 0 $r $transx $transy cm ".join(' ',@mat)." cm $lw w 
$x0 $y0 m $x1 $y1 $x2 $y2 $x3 $y3 c S Q\n";
+}
 }
 
 sub DrawCircle

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

[bug #64592] [troff] registers .m and .M contain no initial value

[Deri James]

Follow-up Comment #11, bug #64592 (project groff):

After the change I ran the code in comment #1 and now the second line works
fine (the first line will never work properly because we don't stack colour
changes).

Interestingly the call to \m[\*[curcol]] where curcol contains the word
"default", causes groff to emit "mr 0 0 0". Tested on pdf, ps, dvi, html and
utf8 devices, so I would be happy with this fix to the problem.


___

Reply to this item at:

  

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

[bug #64592] [troff] registers .m and .M contain no initial value

[Deri James]

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

Sorry, my fault, I was not clear. My reference to the registers in comment #3
was intended to show that your statement "registers .m and .M don't behave
like other registers (containing the default values)" was the problem. I'm not
sure (2) can be successfully implemented for all devices, groff does not
"know" for certain the default colour. Groff outputs the command "DFd"
initially since it is up to the output device to decide the default colour and
groff does not know. This is why the fix for this anomalous behaviour is to
delegate the default colour decision to each output driver.

It is quite common for macros or string to change a text state and restore it
afterwards. One way is to note the current value using the documented state
variables and restore them afterwards, but because \n[.m] does not contain the
actual colour, this is not possible for colours.


___

Reply to this item at:

  

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

[bug #64592] [troff] registers .m and .M contain no initial value

[Deri James]

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

[comment #5 comment #5:]
> Is the problem that registers .m and .M don't behave like other registers
(containing the default values), or that the roff language offers no way to
retrieve these defaults?

See comment #3 which mentions two registers which reflect the default value.
The problem is that precise initial glyph and fill colours are probably only
relavent for X, dvi, ps and pdf. For tty and html initial colours are chosen
by the console/browser.

My proposed "fix" for this bug is to add:-

.gcolor black
.fcolor black

To the startup tmac for the 4 drivers mentioned above, e.g. pdf.tmac, and
document in gropdf.1 that the default colours are black. Which means that if a
user interogates \n[.m] they will find the value "black" rather than an
unhelpful null value.

While we are on the subject of colour, a little rant:-



For pdfs and probably postscript there are two drawing modes, stroke and fill.
For graphical objects, using \D commands \m is the stroke colour and \M is the
fill colour, but, for text \m is the fill colour, since the paths described by
font glyphs are always filled, not stroked. If glyphs were stroked rather than
filled you get hollow outlines of the letters. Of course, with pdf, you can
specify whether you want text glyphs to be filled or stroked or both, but the
default is filled only. This means I have to swap the meaning of \m depending
on whether gropdf is dealing with graphics or text.

This really has nothing to do with this bug, its really just a note to myself
that if I introduce a pdf extension to control fill/stroking glyphs, I need to
unswap the meaning of \m if the user asks  for stroking!!


___

Reply to this item at:

  

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

[bug #64728] diversion widths reported when using eqn mark/lineup feature inconsistent with Heirloom

[Deri James]

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


> Heirloom nroff reports the same zero width, so if this is indeed a bug, it's
a widespread one.

If you consider the width of a diversion is the horizontal displacement of the
longest line in the diversion, then the horizontal displacement in this single
line example is zero, after outputting this diversion the horizontal movement
is zero.


___

Reply to this item at:

  

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

[bug #64592] [troff] registers .m and .M contain no initial value

[Deri James]

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

Hi Branden,

Just a few thoughts really, I agree the registers are behaving as currently
documented, the question is whether the current behaviour makes sense.

Groff currently has no concept of opacity, gropdf allows pdfs included by
pdfpic to have objects which are not fully opaque, but that's as far as it
goes currently, so no, or null, colour can't mean transparent. Also, groff
uses the null string generally, to reset states to the previous value. So \m[]
resets stroke colour to its previous value. For these colour registers the
initial value is a null string but empirical testing shows this default colour
is black, in most cases but see below.

This is in contrast to other state variables where we document the default
value and the state variable reflects this, so the default pointsize is 10pt
and \n[.s] contains 10, the default font is Times-Roman and the initial value
of \n[.fn] is TR. Is there a reason why colour should be treated differently?

It could be argued that the default colour is in the purview of the output
driver, and in this case each device's tmac file should set the actual default
colour and document the choice in its man page. The odd man out is grotty
since the initial stroke/fill colours are probably set by the terminal
settings rather than groff, but you're more au-fait with terminal output. This
dichotomy is probably the reason for the copout about default colours in the
documentation without specifying what the actual colour would be. This may be
a strong argument for delegating the initial startup default colour to each
driver, rather than a one size fits all within groff.


___

Reply to this item at:

  

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

[groff] 04/05: Enable more hyperlinks in groff-man-pages.pdf

[Deri James]

deri pushed a commit to branch deri-gropdf-ng
in repository groff.

commit a2e72beef12ccc05a933493cfc3a9d6d9dde61c2
Author: Deri James 
AuthorDate: Wed Sep 6 22:44:57 2023 +0100

Enable more hyperlinks in groff-man-pages.pdf
---
 doc/doc.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/doc.am b/doc/doc.am
index f6e40bff3..c139452c1 100644
--- a/doc/doc.am
+++ b/doc/doc.am
@@ -262,7 +262,7 @@ man-clean:
 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_PDFMOM) -pet -mandoc -manmark -dHF=HB -rC1 \
- -rCHECKSTYLE=3 -rIN=7.2n -Tpdf -P-e \
+ -rCHECKSTYLE=3 -rU=1 -rIN=7.2n -Tpdf -P-e \
  $(top_srcdir)/doc/GMPfront.t \
  $(GROFF_MAN_PAGES1) \
  $(tmac_srcdir)/sv.tmac $(GROFF_MAN_PAGES2) \

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

[groff] 01/05: Add missing 'tmac' flag

[Deri James]

deri pushed a commit to branch deri-gropdf-ng
in repository groff.

commit 2b3f346ce6ff2e195903cbfb00df66307c65f35a
Author: Deri James 
AuthorDate: Fri Sep 1 12:03:52 2023 +0100

Add missing 'tmac' flag

Allows gropdf to know this papersize change came from -dpaper=
---
 tmac/papersize.tmac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tmac/papersize.tmac b/tmac/papersize.tmac
index 57d763a9f..ffba019f1 100644
--- a/tmac/papersize.tmac
+++ b/tmac/papersize.tmac
@@ -144,7 +144,7 @@
 .  ie '\*[paper-l]'' \{\
 .pl \*[paper-\*[paper-p]-length]
 .ll (\*[paper-\*[paper-p]-width] - 2i)
-.if '\*[.T]'pdf' .device 
papersize=\*[paper-\*[paper-p]-width],\*[paper-\*[paper-p]-length]
+.if '\*[.T]'pdf' .device 
papersize=\*[paper-\*[paper-p]-width],\*[paper-\*[paper-p]-length] tmac
 .  \}
 .  el \
 .nr paper-w 1

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