[bug #60052] [tbl] want option to output HTML

[Dave]

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

[comment #0 original submission:]
> That would render groff_hdbtl(7) unnecessary

s/hdbtl/hdtbl/, to get to an existent man page.

But I wonder if there is also a thinko here: elsewhere (e.g., bug #63837) it
seems like tbl having this functionality is meant to obsolete pre-grohtml, not
groff_hdtbl.

(groff_hdtbl is controversial on its own merits anyway: see bug #64772.)


___

Reply to this item at:

  

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

[bug #63837] [grohtml] only the last page of multi-page tables is rendered

[Dave]

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

[comment #0 original submission:]
> That leaves _only_ tbl as a reason for pre-grohtml to exist.

Bug #60052 seeks to abolish that reason.


___

Reply to this item at:

  

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

[bug #63587] [troff] set .R register to maximum representable integer

[Dave]

Follow-up Comment #10, bug #63587 (group groff):

[comment #5 comment #5:]
> I can think of no situation where a user might need 10,001
> registers, so, despite this number having no clear connection to
> any internal groff limit, it's probably a reasonable limit to
> _claim_ to the user who asks.  It will enable the processing of
> any ancient roff documents that do test this register,

I have to backpedal on my own argument here: this point, as far as I can see
now, remains just as true no matter what big number .R holds.  Groff having no
fixed register limit, 10,000 and INT_MAX are equally wrong values to return,
but equally useful in terms of back compatibility to documents for ancient
troffs.


___

Reply to this item at:

  

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

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

[Morten Bo Johansen]

On 2024-06-20 Deri James wrote:

> 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.

I include it below, uuencoded.

Actually, it does show up in gv(1), but neither in zathura nor
mupdf.

Regards,
Morten


begin 644 ellipse-no-show.pdf
M)5!$1BTQ+C0*)>+CS],*,R`P(&]B:B`\/"`O0V]N=&5N=',@6S0@,"!2("!=
M"B]'U?&@&4P
M@5:G]233RB#$2?196C7K2FV5B#3(NAUL`:,
M5E<@9F&'(J,*@:+_<_PCTZJ0:?RRPS[K"F1:9*D,)L7J"F18O0.B;FA'>QX1
MF*,Q#W0M%(`Y\C5U(`PQ$!SM5M+@!S"N!.+J8`S,G0.KG``QA.$Q#VK0O`
M'`VM53<$`9BC.K,;IP#,T5B1W6`!R+-=/*.0"_#FHLC=PZ"YBCPSPBPP*T
MF_,$?E_:;M:1/B+P^:"VF<7ELX#+N76!C'SG?`+7K]8KE$YWOT[@^M[+#K
M^PG<_+3.4*V>`,XY7"@SKSETP,WS0(]Y/L%Y,NIB[`(WG<2E?K(GG<<-<01/*X+:]QBF1:ZYZ]!C.2:=4PXI$,ZVW[
M`\)$*.)E;F1S=')E86T*96YD;V)J"C$@,"!O8FH@/#P@+U!A9V5S(#(@,"!2
M(`HO5'EP92`O0V%T86QO9PH^/@IE;F1O8FH*-2`P(&]B:B`\/"`O0W)E871I
M;VY$871E("A$.C(P,C0P-C(P,C`S-C$Y*S`P)S`P)RD*+T-R96%T;W(@*&=R
M;V9F('9E')E9@HY.#D*)25%3T8*
`
end

[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 #65902] [grog] does not recognize chem preprocessor

[G. Branden Robinson]

Update of bug #65902 (group groff):

Severity:1 - Wish => 4 - Important  
  Item Group:  Feature change => Incorrect behaviour
  Status:   Confirmed => In Progress

___

Follow-up Comment #2:

Unfortunately this was something I broke when I pretty much rewrote _grog_(1)
for _groff_ 1.23.

I didn't think hard enough about the weirdness (in AT _troff_ input) of the
tokens used to mark _chem_(1) input.

Setting to important severity since it's a regression relative to a released
_groff_.

Here's a patch.


diff --git a/src/utils/grog/grog.pl b/src/utils/grog/grog.pl
index 4820c2b87..d7e623aac 100644
--- a/src/utils/grog/grog.pl
+++ b/src/utils/grog/grog.pl
@@ -38,6 +38,7 @@ my @inferred_main_package = ();   # full-service
package(s) detected
 my $main_package;  # full-service package we go with
 my $use_compatibility_mode = 0;# is -C being passed to groff?
 
+# See subroutine do_line below for chem(1) handling.
 my %preprocessor_for_macro = (
   'EQ', 'eqn',
   'G1', 'grap',
@@ -46,10 +47,6 @@ my %preprocessor_for_macro = (
   '[',  'refer',
   #'so', 'soelim', # Can't be inferred this way; see grog man page.
   'TS', 'tbl',
-  'cstart',   'chem',
-  'lilypond', 'glilypond',
-  'Perl', 'gperl',
-  'pinyin',   'gpinyin',
 );
 
 (undef, undef, my $program_name) = File::Spec->splitpath($0);
@@ -247,6 +244,15 @@ sub do_line {
 }
   }
 
+  # Handle "chem" as a special case, since its start/end tokens collide
+  # with AT troff request names in their first two characters.
+  if ($line =~ /^\.(cstart|cend)\b/) {
+my $preproc = 'chem';
+if (!grep(/$preproc/, @inferred_preprocessor)) {
+  push @inferred_preprocessor, $preproc;
+}
+  }
+
   # Normalize control lines; convert no-break control character to the
   # regular one and remove unnecessary whitespace.
   $line =~ s/^['.]\s*/./;




___

Reply to this item at:

  

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

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

[Morten Bo Johansen]

On 2024-06-20 Deri James wrote:

> Follow-up Comment #1, bug #65901 (group groff):
>
> After changing elipse to ellipse

That was a typo on my part. I did have "ellipse" in my source.

>  in the two code examples, I can't recreate the first problem.
>  The dots are visible in zathura.

Odd. The pdf on my end is simply broken. It doesn't show in
mupdf either.

Regards,
Morten

[bug #65894] [troff] certain man(7) input leads MTSM into deranged state, mismanaging memory

[G. Branden Robinson]

Update of bug #65894 (group groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.24.0 

___

Follow-up Comment #1:

This was a can of worms.

Here are the resolving commits in forward chronological order.


commit aab74ead30a3356252011314a2af1642e36653ad
Author: G. Branden Robinson 
Date:   Thu Jun 20 11:59:06 2024 -0500

[groff]: Add regression test for latent troff bug.

Add regression test for latent bug: surprising "grout" produced when
using "html" output device and a memory management bug is fixed.

* src/roff/groff/tests/html-does-not-fumble-tagged-paragraph.sh: Do it.
* src/roff/groff/groff.am (groff_TESTS): Run test.

commit b5513742757588e0cf9a043d16dbf06a424906bc
Author: G. Branden Robinson 
Date:   Wed Jun 19 10:38:43 2024 -0500

[troff]: Fix Savannah #65894.

Refactor troff's "mini-troff state machine" to use STL stack
implementation instead of a bespoke one, fixing a double-free error.

* src/roff/troff/mtsm.h: Include C++ standard library "stack" header.

  (struct stack): Drop.

  (class mtsm): Declare `stack` data member as a standard stack of
  `statem` objects instead of a pointer to local `stack` type.

* src/roff/troff/mtsm.h (statem::merge, statem::update):
* src/roff/troff/mtsm.cpp (statem::merge, statem::update): Take
  references instead of pointers to some `statem` arguments (those that
  will be accessed via the `stack` data member).

* src/roff/troff/mtsm.cpp (stack::stack, stack::~stack): Drop.

  (mtsm::mtsm): Drop initializer of `sp` data member.

  (mtsm::~mtsm): Drop (conditional) deletion of `sp`.

  (mtsm::push_state, mtsm::pop_state, mtsm::inherit): Use STL `stack`'s
  `push()`, `empty()`, and `pop()` instead of primitive operations.

  (statem::update): Access data members of `mtsm` class via references
  instead of pointers (using `.` instead of `->` operator).

  (statem::merge): Drop null pointer test of reference, which can't be
  null.

Fixes .  This was a latent bug
exposed by commit 0951ff53e4, 10 August (a change to the man(7) macro
package; such things should _never_ cause the formatter to crash).

Also drop old-style Emacs file-local variable setting.

The following test fails at this commit:
  src/roff/groff/tests/html-does-not-fumble-tagged-paragraph.sh

I attempted a less intrusive change, but did not succeed.  The copying
of pointers to groff strings as data members of objects using C++
default copy constructors that also get automatically cleaned up by
destructors also worried me--and the MTSM logic does this sort of thing
a lot--but delegating stack handling to the STL suffices to resolve this
concrete problem.  I continue to nurse reservations about the wisdom of
attempting to infer HTML structure from troff requests not designed for
that purpose, the necessity of state management that this approach
imposes, and the robustness of our implementation, which we documented
as being "beta code" about 25 years ago and have changed little since.

I welcome objections to and arguments against my opinion if they're
accompanied by code changes that improve the situation.

commit 2cfc5ddeec5d74109818cfefd7f3f29354f29545
Author: G. Branden Robinson 
Date:   Thu Jun 20 12:36:16 2024 -0500

[troff]: Fix failing test.

* src/roff/troff/mtsm.cpp (mtsm::inherit): Fix failing test.

I freely admit I don't completely understand why this works.  But it
restores correct man page formatting.

Complicating the problem is that grohtml/MTSM's support for centering
and right-alignment (the `ce` and `rj` requests) never really worked
anyway.

Try this with any version of groff supporting grohtml:

$ cat ATTIC/ce-rj-html.groff
.ce 1
This is centered.
This is not.
.rj 1
This is right-aligned.
This is aligned to the left.
$ ~/groff-1.22.3/bin/groff -Tascii ./ATTIC/ce-rj-html.groff | cat -s
This is centered.
This is not.
   This is right-aligned.
This is aligned to the left.
$ ~/groff-1.22.3/bin/groff -Thtml ./ATTIC/ce-rj-html.groff | grep 'This is centered. This is not.
This is right-aligned. This is aligned to the left.

Why were these features (in grohtml/MTSM) put in if they didn't work?




___

Reply to this item at:

  

___
Message sent via Savannah

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

Re: [gropdf] Unable to render ellipse with dashed/dotted atribute

[Morten Bo Johansen]

Hi Branden,

On 2024-06-20 G. Branden Robinson wrote:

> The bug-groff list is mainly a reflector for Savannah ticket activity
> conducted via the WWW.
>
> Please consider filing future tickets directly with that system.
>
> https://savannah.gnu.org/bugs/?group=groff=additem

I shall do so from here on.

Thanks,
Morten

[bug #65902] [grog] does not recognize chem preprocessor

[G. Branden Robinson]

Update of bug #65902 (group groff):

  Status:None => Confirmed  
 Assigned to:None => gbranden   

___

Follow-up Comment #1:

Assigning to self, as I'm the only person who works on _grog_.

I agree that _grog_ should detect the telltale _chem_(1) tokens and infer a
`-j` option to the _groff_ command-line therefrom.

For _lilypond_, _gperl_, and _gpinyin_, there is nothing for _grog_ to do
since it infers only *command-line* arguments, and there are none
corresponding to these preprocessors. Nor are there likely to be given the low
apparent level of usage of all 3 of these.

We don't often hear much about _chem_ either, but it (1) is of much longer
pedigree than Bernd Warken's aforementioned preprocessors and (2) already has
a _groff_ option assigned to it.


___

Reply to this item at:

  

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

[bug #65902] [grog] does not recognize chem preprocessor

[G. Branden Robinson]

URL:
  

 Summary: [grog] does not recognize chem  preprocessor
   Group: GNU roff
   Submitter: gbranden
   Submitted: Thu 20 Jun 2024 03:22:10 PM UTC
Category: Utilities
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 20 Jun 2024 03:22:10 PM UTC By: G. Branden Robinson 
[https://lists.gnu.org/archive/html/bug-groff/2024-05/msg00043.html Morten Bo
Johansen reported]:

Unless I misunderstand something, shouldn't grog detect e.g. a
.cstart macro in a document and then come up with a suggestion
that includes the "-j" argument for the chem(1) preprocessor?


  ~/ % echo .cstart | ./grog.pl
  groff -


These do not work either:


  'lilypond', 'glilypond',
  'Perl', 'gperl',
  'pinyin',   'gpinyin',


This is both with the git version of groff and with 1.23.0







___

Reply to this item at:

  

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

Re: [gropdf] Unable to render ellipse with dashed/dotted atribute

[G. Branden Robinson]

Hi Morten,

At 2024-06-20T15:52:41+0200, Morten Bo Johansen wrote:
> Trying to convert to pdf from this groff source:
[snip]

Thanks for the report.  I have filed it with the GNU Savannah ticket
tracker at:

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

The bug-groff list is mainly a reflector for Savannah ticket activity
conducted via the WWW.

Please consider filing future tickets directly with that system.

https://savannah.gnu.org/bugs/?group=groff=additem

Regards,
Branden


signature.asc
Description: PGP signature

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

[G. Branden Robinson]

URL:
  

 Summary: [gropdf] unable to render ellipse with dashed/dotted
atribute
   Group: GNU roff
   Submitter: gbranden
   Submitted: Thu 20 Jun 2024 03:15:55 PM UTC
Category: Driver gropdf
Severity: 3 - Normal
  Item Group: Incorrect behaviour
  Status: None
 Privacy: Public
 Assigned to: deri
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Thu 20 Jun 2024 03:15:55 PM UTC By: G. Branden Robinson 
[https://lists.gnu.org/archive/html/bug-groff/2024-06/msg00045.html Morten Bo
Johansen reported:]

Trying to convert to pdf from this groff source:


   .PS
   elipse dotted
   .PE


with the command:


   groff -Tpdf -p


yields a broken/empty pdf. Opening it in e.g. zathura gives
this error message:


  format error: cannot recognize version marker
  warning: trying to repair broken xref
  warning: repairing PDF document


This also applies to circles.

Trying to convert to pdf from this groff source:


   .PS
   elipse dashed width 6 height 3
   .PE


outputs a dashed ellipse with two unwanted vertical lines
running through it. It only happens if width >= 6. With e.g.
width = 5, it renders okay.

With groff -Tps, there is no problem.

~/ % groff --version
GNU groff version 1.23.0







___

Reply to this item at:

  

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

[gropdf] Unable to render ellipse with dashed/dotted atribute

[Morten Bo Johansen]

Trying to convert to pdf from this groff source:

   .PS
   elipse dotted
   .PE

with the command:

   groff -Tpdf -p 

yields a broken/empty pdf. Opening it in e.g. zathura gives
this error message:

  format error: cannot recognize version marker
  warning: trying to repair broken xref
  warning: repairing PDF document

This also applies to circles.

Trying to convert to pdf from this groff source:

   .PS
   elipse dashed width 6 height 3
   .PE
  
outputs a dashed ellipse with two unwanted vertical lines
running through it. It only happens if width >= 6. With e.g.
width = 5, it renders okay.

With groff -Tps, there is no problem.

~/ % groff --version
GNU groff version 1.23.0

Regards,
Morten