[bug #63827] withdraw contrib/pdfmark

[Keith Marshall]

Follow-up Comment #12, bug #63827 (project groff):

[comment #11 comment #11:]
> [comment #10 comment #10:]
> > Should the 1.23 announcement/news mention that:
> > * the pdfmark bundled with this release of groff is not the latest code
(and provide a pointer to that code)?
> 
> I don't think they've diverged all that much.  ...
Sorry, but I beg to differ.  Since I forked it, I have added quite a
significant amount of new content to pdfmark.ms, (and hence to pdfmark.pdf). 
I've also improved, and sometimes corrected, a few features of pdfroff.sh
operation, corrected some issues which I've identified in pdfmark.tmac, and
added the new toc.tmac facility, to improve table of contents generation
capabilities.

I no longer maintain a free-standing ChangeLog file, within my repository, but
can generate one on demand, from the mercurial log; I've attached a copy of
that, spanning the period from the time of the fork, up to the latest
published commit, from which you should be able to glean some idea of the
changes I've already published.

In addition to my published changes, I have a queue of some 16 local patches,
yet to be finalized, but I anticipate fairly imminent publication of several
of them.

(file #54446)

___

Additional Item Attachment:

File name: ChangeLog  Size:17 KB




___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[G. Branden Robinson]

Follow-up Comment #10, bug #63812 (project groff):

[comment #9 comment #9:]
> [comment #8 comment #8:]
> > This would be a simple iterator.  The string named "s" takes on the value
of each item in string-expr from left to right.
> How is string-expr tokenised?

Sorry, I wasn't thinking properly when I typed that.  (Haven't actually tried
to implement this yet.)

The second argument would need to be a "name", so a string/macro/diversion. 
Attempting to iterate over an undefined one would probably throw a "mac"
warning.  Attempting to iterate over a request would be rejected with an
error.

> What do you mean by contrivance? AFAIK, most of the characters documented by
groff_char(7) have corresponding entries in the UCD.

I'm starting to remember what I wanted the really-a-glyph predicate for.

See bug #63354.  There's a lot to it.

> No no, I only mentioned that to elucidate my remark about "too many hours
coding in PostScript".

Ahhh.  No worries.  :)


___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[John Gardner]

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

[comment #8 comment #8:]
> This would be a simple iterator.  The string named "s" takes on the value of
each item in string-expr from left to right.
How is string-expr tokenised? Is its value treated like a whitespace-delimited
list (following the same rebarbative logic as Roff's argument
quoting/escaping), or is it closer to Awk and the Bourne shell in that an
(internal) field separator can be specified?

> some contrivance in the *roff language?"
What do you mean by contrivance? AFAIK, most of the characters documented by
groff_char(7) have corresponding entries in the UCD.

> > (This corresponds to PostScript's `where` operator, which locates the
entry on the dictionary stack which defines an entry with the given key. I'll
shut up now)
> By the time a request can process something in *roff, there aren't many
stacks of interest to look at.  Just a node list.
No no, I only mentioned that to elucidate my remark about "too many hours
coding in PostScript".


___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[G. Branden Robinson]

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


[comment #7 comment #7:]
> [comment #6 comment #6:]
> > Long stories short, I want a `for` request that will iterate over
macros/strings/diversions
> Interesting. Does it resemble this
?

Not closely.

What I had in mind was this.


.for s string-expr \{\
.  whatever
.  you
.  want
.\"  break
.\"  continue
.\}


This would be a simple iterator.  The string named "s" takes on the value of
each item in string-expr from left to right.
 
> > and new conditional operators to test for "nodes"
> YES. PLEASE. The whole "nodes versus strings" semantic is what led me down
the aforementioned rabbit hole. The fact I even got it working (without GNU
extensions, no less) is a testament to my neurotic stubbornness.

Yes.  People keep doing complicated, wacky things to work around this.  Keith
Marshall has his "sanitize.tmac".  I have two different instances of loony
shit in an.tmac and doc.tmac to abbreviate overlong material for placement in
headers/footers.

It's incredibly tedious and bug-prone.
 
> > and for glyphs that are actually defined in the current font
> I've probably spent too many hours coding in PostScript, but wouldn't an
escape sequence that expands to the name of the font containing the requested
glyph be more useful?

Maybe.  But the question I've found myself needing to answer recently was "is
this REALLY a glyph the font will provide, or some contrivance in the *roff
language?".  I forget now where this came up but it's in a Savannah ticket. 
Dave might remember.

> At least that way you'll be able to compare the output against the name of
the current font.

Not saying this isn't worth doing, but it's not one of the two big changes
mentioned above, and which I would like to do soon.
 
> (This corresponds to PostScript's `where` operator, which locates the entry
on the dictionary stack which defines an entry with the given key. I'll shut
up now)

By the time a request can process something in *roff, there aren't many stacks
of interest to look at.  Just a node list.

*roff was written for small systems. There's no Document Object Model.  The
formatter has no view of the whole document at any time.  It keeps track of as
little as possible; enough to spit out the next output line and a few other
bits of state demanded by features required to typeset conventional works.


___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[John Gardner]

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

[comment #6 comment #6:]
> Long stories short, I want a `for` request that will iterate over
macros/strings/diversions
Interesting. Does it resemble this
?

> and new conditional operators to test for "nodes"
YES. PLEASE. The whole "nodes versus strings" semantic is what led me down the
aforementioned rabbit hole. The fact I even got it working (without GNU
extensions, no less) is a testament to my neurotic stubbornness.

> and for glyphs that are actually defined in the current font
I've probably spent too many hours coding in PostScript, but wouldn't an
escape sequence that expands to the name of the font containing the requested
glyph be more useful? At least that way you'll be able to compare the output
against the name of the current font.

(This corresponds to PostScript's `where` operator, which locates the entry on
the dictionary stack which defines an entry with the given key. I'll shut up
now)


___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[G. Branden Robinson]

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


[comment #5 comment #5:]
> The projected likelihood of introducing such a backwards-incompatible
feature is marginal at best, and indicative of feature creep at worst.

Muahahahaha.  You don't know of my plans for groff 1.24.

Long stories short, I want a `for` request that will iterate over
macros/strings/diversions, and new conditional operators to test for "nodes"
and for glyphs that are _actually defined_ in the current font, as opposed to
interposed via character definitions.


___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[John Gardner]

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

[comment #4 comment #4:]
> Here's what I have at the moment.
Looks good. One nanoscopic nitpick, which borders on bikeshedding:

> and GNU @code{troff} may provide additional operators in the future.
The projected likelihood of introducing such a backwards-incompatible feature
is marginal at best, and indicative of feature creep at worst. I wouldn't rule
the possibility out completely, but it's still not likely enough to warrant
mentioning in Groff's documentation.

(I told you it was a nitpick…)


___

Reply to this item at:

  

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

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

[G. Branden Robinson]

Update of bug #63812 (project groff):

  Status:None => In Progress

___

Follow-up Comment #4:

I'm working on this on a (so far, local only) post-1.23.0 branch.

Here's what I have at the moment.


diff --git a/doc/groff.texi b/doc/groff.texi
index 15b3cd8a3..ae5645c63 100644
--- a/doc/groff.texi
+++ b/doc/groff.texi
@@ -12571,8 +12571,19 @@ certain other @code{troff}
implementations.@footnote{This refers to
 @code{vtroff}, a translator that would convert the C/A/T output from
 early-vintage @acronym{AT} @code{troff} to a form suitable for
 Versatec and Benson-Varian plotters.}
+@end table
+
+If the first argument to an @code{if}, @code{ie}, or @code{while}
+request begins with a non-alphanumeric character apart from @code{!}
+(see below); it performs an @slanted{output comparison test}.
+@footnote{Strictly, letters not otherwise recognized @emph{are} treated
+as output comparison delimiters.  For portability, it is wise to avoid
+using letters not in the list above; for example, Plan@tie{}9
+@code{troff} uses @samp{h} to test a mode it calls @code{htmlroff}, and
+GNU @code{troff} may provide additional operators in the future.}
 
 @cindex output comparison operator
+@table @code
 @item @code{'}@var{xxx}@code{'}@var{yyy}@code{'}
 True if formatting the comparands @var{xxx} and @var{yyy} produces the
 same output commands.  The delimiter need not be a neutral apostrophe:
diff --git a/man/groff.7.man b/man/groff.7.man
index 0d0539a98..dec4deefd 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -2099,9 +2099,20 @@ T}
 .
 .
 .P
-The first of the above,
+If the first argument to an
+.BR .if ,
+.BR .ie ,
+or
+.B .while
+request begins with a non-alphanumeric character apart from
+.B !\&
+(see below);
+it performs an
+.I "output comparison test" .
+.
+Shown first in the table above,
 the
-.I "output comparison operator,"
+.I "output comparison operator"
 interpolates a true value if formatting its comparands
 .I s1
 and



___

Reply to this item at:

  

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

[bug #63827] withdraw contrib/pdfmark

[G. Branden Robinson]

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

[comment #10 comment #10:]
> Should the 1.23 announcement/news mention that:
> * the pdfmark bundled with this release of groff is not the latest code (and
provide a pointer to that code)?

I don't think they've diverged all that much.  (Time will of course tell how
much they have done in a year or so.)  pdfroff(1) will continue to exist in
groff 1.23.0 distributions and point readers to Keith's site.

> * this is the last groff release that will have pdfmark bundled with it?

No, I don't care to give a hostage to fortune in that matter.  As it happens
I'm looking at withdrawing contrib/pdfmark on a branch right now, but I might
not finish that work or it might end up not happening for whatever reason.

I'd prefer the news and announcement files to state things that are known as
of the time of release, rather than risking baking inaccuracies in them. 
(Beyond those errors that inevitably arise after 20 people have proofread
something 20 times but only rear their heads after going to press.)


___

Reply to this item at:

  

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