Re: uppercase german umlaut

[Dave Kemper]

On 1/8/24, hoh...@posteo.de  wrote:
> On Tue, 2 Jan 2024 11:04:25 -0600
> Dave Kemper  wrote:
>
>> > ECMA-48 says for 0x84:
>>
>> Also irrelevant to groff, as it doesn't use ECMA-48.  Groff tools
>> (including gpic) take input in Latin-1, period.
>
> I don't think so. ECMA-48 may be interpreted by terminals.

In the message to which I was replying, you were speaking of the
sequence of bytes that were part of the input to gpic; in this realm,
ECMA-48 is irrelevant.  And in any case, the 0x84 byte in question is
part of the UTF-8 encoding of Unicode character U+00C4 LATIN CAPITAL
LETTER A WITH DIAERESIS; if it's being interpreted by a terminal
somewhere as ECMA-48, something is going wrong.

What seems to be going wrong in this instance is that you're passing
UTF-8 directly to gpic without first running it through preconv or
iconv, resulting in a byte sequence gpic doesn't recognize.  You
haven't said whether you've tried converting the input before sending
it to gpic, or why you're avoiding preconv.

> In the case of terminal output, those characters if interpreted as
> control sequences would thrown the output into disarray. Therefore,
> if I'm right, it's rejected as invalid but not passed through.

Correct, gpic won't pass through bytes it considers invalid.

$ echo Ä | od -t x1
000 c3 84 0a
003
$ echo Ä | pic | grep -av '^\.' | od -t x1
pic::1: invalid input character code 132
000 c3 0a
002

gpic strips the 0x84 (decimal 132) byte, leaving you with invalid
UTF-8, or valid but erroneous Latin-1.

Re: [PATCH]: Set .lt to \n[.l] in papersize.tmac?

[Robert Thorsby]

On 9/1/24 16:10, Dave Kemper wrote:

On 1/8/24, Robert Thorsby  wrote:

My apologies to the list for the intemperance of my language, but this
has to stop.


"This" being novices posting suggestions without understanding every
nook and cranny of groff?  I couldn't disagree more.  If an idea has
problems, the way newbies learn is by having those problems pointed
out.  Railing against the mere temerity of proposing a change--without
even saying what's wrong with the proposal--is less helpful.  I'm not
a groff novice, and I can't make out what exactly you're objecting to,
since your one specific reference to a section of the manual doesn't
cover what you seem to think it does.

All knowledge levels should feel welcome here.



You are, of course, right Dave. I was railing against people 
automatically assuming that if they can't get things to work as they 
expect then it is "groff's fault" and can only be fixed by redefining 
something or other.


Newbies have always been welcome on this list but, until recently, 
newbies would post a problem they were having and the good folk on the 
list would show them the way, or suggest a workaround, or explain why 
the problem was currently unsolvable. I am always in favour of that 
approach, and have been on the receiving end of solutions and 
workarounds to my problems.


But, jumping in with "patches" without any understanding of groff is 
not, IMO, the way to do it. It is to this that I am vehemently opposed.


I apologize for not making myself clear in my earlier post.

Robert Thorsby

Re: [PATCH]: Set .lt to \n[.l] in papersize.tmac?

[Dave Kemper]

On 1/8/24, Robert Thorsby  wrote:
> I realize that man pages and info documents are not always the easiest
> material to read but, for $DIETY's sake, the info page even has a pretty
> little line-drawing image that shows the relationships between the
> various components that go into the sizing of a page.

Yes, and the components that diagram covers are po (page offset), in
(indent), and ll (line length).  The parameter this patch affects is
lt (title line length).

> My apologies to the list for the intemperance of my language, but this
> has to stop.

"This" being novices posting suggestions without understanding every
nook and cranny of groff?  I couldn't disagree more.  If an idea has
problems, the way newbies learn is by having those problems pointed
out.  Railing against the mere temerity of proposing a change--without
even saying what's wrong with the proposal--is less helpful.  I'm not
a groff novice, and I can't make out what exactly you're objecting to,
since your one specific reference to a section of the manual doesn't
cover what you seem to think it does.

All knowledge levels should feel welcome here.

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

[G. Branden Robinson]

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

Tricky.  By the time `encode_char` sees the input it has already been
tokenized.  This means that what is of interest for my approach is a "token"
node, and that in turn means that input that looks like


\X'\[u007E]'


has already effectively been rewritten as if it were


\X'\[ti]'


...so that sucks.  (AIUI, "uniglyph.cpp" does this remapping.)

More thinking required.  A different escape notation might be required after
all, but I'm not resigned to that possibility YET.


___

Reply to this item at:

  

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

[bug #64959] [troff] add unit tests for `device` and `output` requests

[G. Branden Robinson]

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

[comment #1 comment #1:]
> Being dealt with in bug #65118.

Nope.  Bug #65138.


___

Reply to this item at:

  

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

[bug #64959] [troff] add unit tests for `device` and `output` requests

[G. Branden Robinson]

Update of bug#64959 (group groff):

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

___

Follow-up Comment #1:


[comment #0 original submission:]
> There appears to be an undiagnosed issue with `device`.  You can invoke it
"too early", and it won't appear on the output.  This might be the case any
time the vertical drawing position is negative.  Investigate and document.

Being dealt with in bug #65118.
 
> You can invoke `output` wherever you want, but this can also break the
invariant claimed in "Document parts" [sic] of groff_out(5).  So something
documentary needs to be said about that too.

I think I was mistaken here.  While developing unit tests, I can't actually
get anything to appear ahead of the "grout leader" ("x T ps" and so forth).

The rest is in progress.


___

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

[G. Branden Robinson]

Update of bug#63074 (group groff):

  Status:None => In Progress
 Assigned to:None => gbranden   
 Summary: [troff] need a way to embed non-Basic Latin glyphs
in device control commands => [troff] support construction of arbitrary byte
sequences in device control commands

___

Follow-up Comment #18:

This is a skeleton of my proposal, an alternative to Deri's new `stringhex`
request in his branch, "deri-gropdf-ng".

Originally posted in a recent duplicate bug #65137.


diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index a0b987634..f6e5b1279 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -5571,7 +5571,7 @@ static node *do_non_interpreted()
   return new non_interpreted_node(mac);
 }

-static void encode_char(macro *mac, char c)
+static void encode_char_for_device_control(macro *mac, char c)
 {
   if (c == '\0') {
 if (tok.is_stretchable_space()
@@ -5600,6 +5600,13 @@ static void encode_char(macro *mac, char c)
   else if (strcmp("ti", sc) == 0)
mac->append('~');
   else {
+   // TODO: Support '\[u]' for all devices to support
+   // transmission of arbitrary data to the output device.  It's a
+   // misnomer--this doesn't necessarily represent a Unicode code
+   // point, but this syntax beats inventing a new one for this
+   // esoteric purpose.  Whether one sends \[uAABB],
+   // \[u00AA]\[u00BB], or the latter's byte-swapped counterpart is
+   // an interface detail that the output device must specify.
if (font::use_charnames_in_special) {
  if (sc[0] != (char)0) {
mac->append('\\');
@@ -5612,9 +5619,14 @@ static void encode_char(macro *mac, char c)
mac->append(']');
  }
  else
- error("special character '%1' cannot be used within"
-   " device control escape sequence", sc);
+   error("special character '%1' cannot be used within a"
+ " device control escape sequence", sc);
}
+   else
+ // TODO: Put '\[u]' support here.  Don't allow
+ // '\[u_]'.
+ error("special character '%1' cannot be used within a device"
+   " control escape sequence", sc);
   }
 }
 else if (!(tok.is_hyphen_indicator()
@@ -5668,7 +5680,7 @@ static node *do_special()
   c = '\b';
 else
   c = tok.ch();
-encode_char(, c);
+encode_char_for_device_control(, c);
   }
   return new special_node(mac);
 }




___

Reply to this item at:

  

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

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

[G. Branden Robinson]

Update of bug#65137 (group groff):

  Status:None => Duplicate  
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Duplicates bug #63074.  Will migrate comment #0 over there.


___

Reply to this item at:

  

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

[bug #65138] [troff] `device` request silently fails before first page begins

[G. Branden Robinson]

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

Trying again with the verbatim bit.


$ cat EXPERIMENTS/device-control-request-and-nothing-else.roff
.device ps: nop
$ groff -ww -Z EXPERIMENTS/device-control-request-and-nothing-else.roff
x T ps
x res 72000 1 1
x init
p1
x trailer
V792000
x stop
$ cat EXPERIMENTS/device-control-request-and-partially-collected-line.roff
.device ps: nop
.br
$ groff -ww -Z
EXPERIMENTS/device-control-request-and-partially-collected-line.roff
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X ps: nop
n12000 0
x trailer
V792000
x stop




___

Reply to this item at:

  

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

[bug #65138] [troff] `device` request silently fails before first page begins

[G. Branden Robinson]

Update of bug#65138 (group groff):

  Item Group: Warning/Suspicious behaviour => Documentation   
  

___

Follow-up Comment #1:

A partially collected line needs to exist at least once.  If it does, you can
issue a `device` request as early as you want.

So I am re-conceiving this as a documentation issue.

Exhibits:
$ cat EXPERIMENTS/device-control-request-and-nothing-else.roff
.device ps: nop
$ groff -ww -Z EXPERIMENTS/device-control-request-and-nothing-else.roff 
x T ps
x res 72000 1 1
x init
p1
x trailer
V792000
x stop
$ cat EXPERIMENTS/device-control-request-and-partially-collected-line.roff 
.device ps: nop
.br
$ groff -ww -Z
EXPERIMENTS/device-control-request-and-partially-collected-line.roff
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X ps: nop
n12000 0
x trailer
V792000
x stop
-verbatim-


___

Reply to this item at:

  

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

[bug #64484] [troff] .device and \X don't behave the same

[G. Branden Robinson]

Follow-up Comment #7, bug#64484 (group groff):

My last paragraph in comment #6 was a bit mangled.

Let me try that again.

The foregoing means that I should abandon my plan to make a new fatal error in
response to bug #65138 and also that the scenario in question is probably a
corner case.  Generally, you won't issue device control command with a request
but never even once have a partially collected line in your document.  A unit
test might do that, but a practical document likely will not.


___

Reply to this item at:

  

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

Re: uppercase german umlaut

[hohe72]

On Tue, 2 Jan 2024 11:04:25 -0600
Dave Kemper  wrote:

> > ECMA-48 says for 0x84:  
> 
> Also irrelevant to groff, as it doesn't use ECMA-48.  Groff tools
> (including gpic) take input in Latin-1, period.

I don't think so. ECMA-48 may be interpreted by terminals.

In the case of terminal output, those characters if interpreted as
control sequences would thrown the output into disarray. Therefore,
if I'm right, it's rejected as invalid but not passed through.


pgpUofz4DptYg.pgp
Description: OpenPGP digital signature

Re: [PATCH]: Set .lt to \n[.l] in papersize.tmac?

[Oliver Corff via]

Hi Alexis,

I admit that the source files of the whole groff system have a structure
that in theory allows for apparently easy modifications, but this is not
what they are meant to be. The transparent source code is not an
invitation to edit.

Your modifications, in themselves, are plausible, but my suggestion is
you put them in a local macro which you source with

.so my_title_adjustment.roff

(or whatever you think is a feasible file name).

Best regards,

Oliver.


On 08/01/2024 15:19, Alexis wrote:

Hi all,

I noticed that the default length of title lines (\n[.lt]) of 6.5i works
well for letter sized documents but looks off for other orientations and
paper sizes as the title left-part aligns with the page offset, but the
title right-part does not align with the right text margin.

Hopefully this example describes the issue technically well:

   % for p in letter letterl a4; do \
 echo -e ".tm paper: \*[paper]\n.tm .lt: \\\n[.lt]\n.tm .l:  \\\n[.l]\n.tm" 
\
 | groff - -dpaper=$p -Z >/dev/null; \
   done
   paper: letter
   .lt: 468000
   .l:  468000

   paper: letterl
   .lt: 468000
   .l:  648000

   paper: a4
   .lt: 468000
   .l:  451275

To me setting the length of title lines to the line length in
papersize.tmac (see attached patch) seems like a sensible solution to
provide a good looking default for page orientations and paper sizes
other than letter.

What are people's thoughts on this?
And what have I possibly overlooked that this isn't already the case?


Best
Alexis

--

Dr. Oliver Corff
Wittelsbacherstr. 5A
10707 Berlin
G E R M A N Y
Tel.: +49-30-85727260
Mail:oliver.co...@email.de

Re: [PATCH]: Set .lt to \n[.l] in papersize.tmac?

[Robert Thorsby]

On 9/1/24 01:19, Alexis wrote:

I noticed that the default length of title lines (\n[.lt]) of 6.5i works
well for letter sized documents but looks off for other orientations and
paper sizes as the title left-part aligns with the page offset, but the
title right-part does not align with the right text margin.
...
(see attached patch) seems like a sensible solution to
provide a good looking default for page orientations and paper sizes
other than letter.

What are people's thoughts on this?
And what have I possibly overlooked that this isn't already the case?


I am vehemently opposed to this so-called patch. In one hit you will 
have rendered twenty years of my documents, and the programs I use to 
produce them, unworkable. And all because you have failed to read the 
documentation that comes with every groff installation.


While I applaud the enthusiasm that newcomers bring to this list it 
deeply disturbs me when they find fault with groff that arises because 
they do not do any research into why such "fault" occurs.


I realize that man pages and info documents are not always the easiest 
material to read but, for $DIETY's sake, the info page even has a pretty 
little line-drawing image that shows the relationships between the 
various components that go into the sizing of a page.


I have been using groff with A4 paper, and sometimes with other A and B 
sizes, since I first started using groff.


My apologies to the list for the intemperance of my language, but this 
has to stop.


Robert Thorsby

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Tadziu Hoffmann]

> AT troff was engineered around the assumption that the
> lowercase Greek letters typically used for mathematical and
> scientific typesetting are slanted/italic rather than upright.
> This assumption is baked into the semantics of special
> character names *a, *b, *g, and so forth.
> [...]
> If you couldn't guess, I plan to change this in groff.

It is not, and nothing needs to be changed.

Which character (slanted or upright) groff uses simply depends
on the mounting order of the fonts S and SS.

Example:

  .fp 5 S
  .fp 6 SS
  \(*A\(*a --> upright lowercase alpha.
  .fp 5 SS
  .fp 6 S
  \(*A\(*a --> slanted lowercase alpha.

[bug #64484] [troff] .device and \X don't behave the same

[G. Branden Robinson]

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

[comment #5 comment #5:]
> Another oddity is that you can invoke the `device` request too early, and it
won't be honored, but can use `\X` anywhere you want.

This turns out to be due to the presence of a break on a line using the \X
escape sequence, because it's delimited.  That explanation may not be complete
because this succeeds regardless.


\X'ps: nop'\c


So I guess what's actually happened is that a partially collected line exists
and that's enough to make the output copasetic.

But that means that my plan to make a new fatal error consequent to bug #65138
and also that that is probably a corner case.  Generally, you won't issue
device control command with a request but never even once have a partially
collected line in your document. 


___

Reply to this item at:

  

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

[bug #64484] [troff] .device and \X don't behave the same

[G. Branden Robinson]

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

Another oddity is that you can invoke the `device` request too early, and it
won't be honored, but can use `\X` anywhere you want.


$ cat EXPERIMENTS/device-control-escape-sequence.roff
\X'ps: nop'
$ ~/groff-stable/bin/groff -Z EXPERIMENTS/device-control-escape-sequence.roff
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X ps: nop
n12000 0
x trailer
V792000
x stop
$ cat EXPERIMENTS/device-control-request.roff 
.device ps: nop
$ ~/groff-stable/bin/groff -Z EXPERIMENTS/device-control-request.roff 
x T ps
x res 72000 1 1
x init
p1
x trailer
V792000
x stop




___

Reply to this item at:

  

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

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

[Deri]

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

Thank you.




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

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

[Deri]

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

Thank you.

Re: deri-gropdf-ng branch dependency graph

[Deri]

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

Hi Branden,

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

I will comment on your alternative in bug #65137.

Cheers 

Deri

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

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



Features.pdf
Description: Adobe PDF document

Re: [ms] Add a standard glyph name for hooked o instead of relying on .AM

[G. Branden Robinson]

Hi Doug,

At 2021-01-05T16:19:12-0500, M Douglas McIlroy wrote:
> rfc1345.tmac is a great contribution. I hope to see
> 
> 1. inclusion in the standard groff distribution.

It shipped, eventually, in groff 1.23.0 six months ago.

> 2. the gitlab comment
>"Added \[Eu], \[=R], \[=P] from Vim digraph table."
>inserted in the file

Dorai Sitaram took care of this at the time.

In October of last year I added several more.

* rfc1345.tmac: Add Vim digraphs W`, w`, Y`, y`, oo, 4', and =e.

I reckon those will ship in groff 1.24.0.

> 3. A section groff_mrfc1245 in man7. It can be very short.
>Tell what it is; and refer readers to the file itself to
>see the 1696 glyphs it defines.

This is exactly the approach we took.  :)

Regards,
Branden


signature.asc
Description: PGP signature

Re: [ms] Add a standard glyph name for hooked o instead of relying on .AM?

[G. Branden Robinson]

Hi Doug,

Looks like today's my day to reply to years-old mails.

At 2021-01-03T17:26:35-0500, M Douglas McIlroy wrote:
> I like the idea of an rfc1345.tmac file, and would be happy to operate
> under the false assumption that it exists. I think it would be
> reasonable to abandon the old AT accent strings while we're at it,
> even though I have plenty of groff source that uses them.
> 
> Corollary 1: So that calls for abandoned strings don't just silently
> get ignored, warnings should be issued for unknown strings--preferably
> only once per distinct name.

groff has for many years issued such diagnostics when given the `-w mac`
option.  `-ww`, which turns on more-than-"all" warnings, implies it.

> Corollary 2: If Corollary 1 is adopted, then for consistency warnings
> should be issued similarly for undefined macro calls

Since the same dictionary is used for requests, strings, macros, and
diversions, `-w mac` works the same for all of these.  Regrettably, the
diagnostic itself calls them all "macros".

> and undefined escape sequences.

groff has also for many years issued such diagnostics when given the `-w
escape` option.  `-wall` implies it.

This stuff is documented in the troff(1) page.

$ printf 'hello\\= world \\*x\n' | groff -ww -z
troff::1: warning: ignoring escape character before '='
troff::1: warning: macro 'x' not defined

> Yours radically,
> Doug

I look forward to doing some radical things, but James Clark beat me to
these.

Regards,
Branden


signature.asc
Description: PGP signature

[PATCH]: Set .lt to \n[.l] in papersize.tmac?

[Alexis]

Hi all,

I noticed that the default length of title lines (\n[.lt]) of 6.5i works
well for letter sized documents but looks off for other orientations and
paper sizes as the title left-part aligns with the page offset, but the
title right-part does not align with the right text margin.

Hopefully this example describes the issue technically well:

  % for p in letter letterl a4; do \
echo -e ".tm paper: \*[paper]\n.tm .lt: \\\n[.lt]\n.tm .l:  \\\n[.l]\n.tm" \
| groff - -dpaper=$p -Z >/dev/null; \
  done
  paper: letter
  .lt: 468000
  .l:  468000

  paper: letterl
  .lt: 468000
  .l:  648000

  paper: a4
  .lt: 468000
  .l:  451275

To me setting the length of title lines to the line length in
papersize.tmac (see attached patch) seems like a sensible solution to
provide a good looking default for page orientations and paper sizes
other than letter.

What are people's thoughts on this?
And what have I possibly overlooked that this isn't already the case?


Best
Alexis
diff --git a/tmac/papersize.tmac b/tmac/papersize.tmac
index e10219ad5..e1eab7c03 100644
--- a/tmac/papersize.tmac
+++ b/tmac/papersize.tmac
@@ -126,11 +126,13 @@
 .ie '\*[paper-l]'l' \{\
 .  pl \*[paper-\*[paper-p]-width]
 .  ll (\*[paper-\*[paper-p]-length] - 2i)
+.  lt \n[.l]u
 .\}
 .el \{\
 .  ie '\*[paper-l]'' \{\
 .pl \*[paper-\*[paper-p]-length]
 .ll (\*[paper-\*[paper-p]-width] - 2i)
+.lt \n[.l]u
 .  \}
 .  el \
 .nr paper-w 1

Re: Macros for writing (German) letters?

[Alexis]

Thank you for the quick response, Branden, much appreciated!

> 1.  Meet a need that is shared by others.

  Hopefully Tim, Chris, and I are enough others to meet a need.

> 2.  Implement a solution of reasonable quality.

  Readers of this list shall be the judge of that.

> 3.  Affirm that the work is one's own, or derived from another work that
> is not copyright-encumbered.

  So far that is the case.

> 4.  Offer the contribution to the public under a well understood Free
> Software license.

  That is and was my intention all along.

> 5.  Ask the groff developers to incorporate it, either via a Savannah
> ticket or this mailing list.

  Will do

> If you read through the thread starting at
> https://lists.gnu.org/archive/html/groff/2021-01/msg4.html

That's very helpful!


Thanks,
Alexis

Re: Macros for writing (German) letters?

[G. Branden Robinson]

Hi Alexis,

At 2024-01-08T14:00:19+0100, Alexis wrote:
> A question for the groff maintainers:
> What does it take for a new macro package to be considered for
> inclusion in groff (e.g.: contrib), so folks like Tim feel the macro
> package is "integrated into the groff ecosphere?"

I reckon it's something like this.

1.  Meet a need that is shared by others.
2.  Implement a solution of reasonable quality.
3.  Affirm that the work is one's own, or derived from another work that
is not copyright-encumbered.
4.  Offer the contribution to the public under a well understood Free
Software license.
5.  Ask the groff developers to incorporate it, either via a Savannah
ticket or this mailing list.

This is pretty much what we did when Dorai Sitaram contributed
rfc1345.tmac.

If you read through the thread starting at

https://lists.gnu.org/archive/html/groff/2021-01/msg4.html

and click through the "Thread Next" links (ignoring emails where the
Subject line changes), then you'll get a pretty good view of how the
last new "contrib"-ution from someone who didn't already have commit
permission to our Git repository was made and incorporated.

Regards,
Branden


signature.asc
Description: PGP signature

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Mychaela Falconia]

G. Branden Robinson  wrote:

> This sort of broad, nonspecific, reflexive derogation of groff (or GNU
> generally) is unproductive and frequently indicative of ignorance.

I don't have enough spoons to engage in political fights any more, so
I'll just focus on technical aspects.

> The C/A/T's fonts did not even exist in the digital domain.  They were
> produced from photographic plates.  Their reproduction is consequently
> something of a pickle.

I am very keenly aware of this fact!

> But if you are going for pixel-perfect reproduction of documents that
> used fonts you don't have, you're going to need to recreate the fonts
> somehow--perfectly (at least for the glyphs that a given document uses).

The problem you are describing is one which I am *not* actively working
on presently.  I am _contemplating_ this problem, but not actively
working on it.  In my current stage of 4.3BSD document set reprinting,
I am willing to accept that hyphenations, line breaks and page breaks
will be different from the original because of slightly different font
metrics, and accept the use of only fi and fl ligatures (in running
text, outside of explicit demonstrations) because Adobe's version
dropped ff, ffi and ffl.  (In places where original troff docs
explicitly demonstrate the use of all 5 ligatures, I have a hack that
pulls the missing ligs from a different, not-really-matching font.)

I am willing to accept this imperfection because it is fundamentally
no different from what UCB/Usenix themselves did in 1986: they took
Bell Labs docs that were originally written for CAT and troffed them
on their APS-5 ditroff setup - but those two typesetters also had
slight diffs in their font metrics, causing line and page breaks to
move around!

OTOH I am very willing to entertain, as an intellectual exercise, what
would it take to produce a new font set that would *truly* replicate
the CAT font set at Bell Labs.  The spacing widths of the original
fonts (the key determinant of where breaks will land) are known, right
here:

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/tab3.c

Back in 2004 in one afternoon I threw together a quick-hack program
that takes the output of original troff (CAT binary codes) and prints
it in PostScript, using standard Adobe fonts.  The character
positioning is that of original troff, but because the actual font
characters don't perfectly match these metrics, the result is not
pretty - but the non-pretty result does show *exactly* where every
line and page break lands per original intent!

So what would it take to do such a re-creation properly?  My feeling
is that the task would require hiring a professional typeface designer
to produce a modified version of Times font family: modify the fonts
to produce good visual results (change actual characters as needed) to
fit the prescribed, unchangeable metrics as in spacing widths.  And
design all 5 f-ligatures while at it.

I have no slightest idea how much it would cost to hire a professional
typeface designer to do what I just described, hence I have no idea
whether or not it is something that the hobbyist community could
potentially afford, even collectively.  But it is an interesting idea
to ponder nonetheless - which is where I leave it for now.

> There is a third problem, whose resolution is in progress, when
> producing PDF output from this document; slanted Greek symbols are
> present but "not quite right".  This is because unlike PostScript, PDF
> font repertoires generally don't provide a "slanted symbol" face.

Can you please elaborate?  I personally hate PDF with a passion, but I
concede that in order to make my documents readable by people other
than me, I have to rcp my .ps file from the 4.3BSD machine to a
semi-modern-ish (Slackware) Linux box and run ps2pdf on the file.
But what "slanted symbol" font are you talking about that exists in
PostScript but not in PDF?  The only PostScript fonts whose existence
I take as a given (as opposed to downloading the font explicitly) are
the standard 14: 4 Times family fonts, 4 Helvetica family fonts, 4
Courier family fonts, Symbol and ZapfDingbats.  Which of these 14 is
missing in PDF, and how does "standard" ps2pdf (Ghostscript) handle it?

> Like AT troff, groff attempts to be a practical typesetting system.

I wrote *my* version of troff with exact same goals, and I've been
using it as my personal everyday TPS report formatter for the past 20 y.
It's just that for deeply personal reasons which I would rather not go
into on this list, I chose to develop my own tool instead of using one
that bears GNU branding.  I also wanted my troff to run under 4.3BSD,
using only K C, which I reason would probably be impossible with
groff.  (I recall reading somewhere that groff is written in C++ - so
it is completely out of consideration for something that needs to run
under 4.3BSD.)

> But there is room in the world for such things, particularly if they are
> Free Software.  I was unable to 

Re: Macros for writing (German) letters?

[Alexis]

Here's the din-5008-dimensions.roff I forgot
to attach in my previous mail.


Best Alexis
\# Use the following command to typeset this document:
\# groff -Tpdf -p -dpaper=a4 -P-pa4 din-5008-dimensions.roff > din-5008-dimensions.pdf
.nop \X'ps: exec 2 setlinecap'
.nop \X'ps: exec 0 setlinejoin'
.ft C
.po 1.75c
.sp |\n(.ou
.vs 0
.PS
# Defaults
lineheight   = 4.23 # default line height (12pt) in mm
###
# User configurable variables start here
define form { "A" } # Choose A or B
infoblock_width  = 75 # Set custom width for information block; must be <= 75
infoblock_height = 40 # Set custom height for information block; must be >= 40
footer_height= 2*lineheight # Set custom height of footer
show_dimensions  = 1   # 1: Print measurements; 0: Hide measurements
zoom = 100 # in- or decrease size of picture
   # NOTA BENE: Only a zoom of 100 will be displayed accurately,
   # i.e. other zoom levels may introduce false gaps or overlaps
# User configurable variables end here
###
if form!="A"&!="B" then {
  command ".tm Unknown form"
}
# map user variables to internal variables
lh=lineheight
ibw=infoblock_width
ibh=infoblock_height
fth=footer_height
lbls=show_dimensions
ibwd=75 # max width of information block
ibhd=40 # min height of information block
if ibw>ibwd then {
  command sprintf(".tm Using maximum width of %g for information block instead of requested %g", ibwd, ibw)
  ibw=ibwd
}
if ibh left maxpswid outline "orange" \
with .c at Header .b + (0, 5) sprintf("\h'-12'\v'-6p'%g", maxpswid)
}
{ # Draw height measurement
  line <-> up hl outline "orange" \
at Header .sw + (30, 0) aligned sprintf("\v'-6p'%g", hl)
}
{ # Draw top offset measure for information block
  line <-> up hl+5 \
at last box .ne - (10+ibw, hl+5) aligned sprintf("\v'-6p'%g", hl+5)
}
  }
}
define punchmark {
  {
move to Header .nw down maxpsht/2 right 10
{ line left 10 outline "pink2" }
if (lbls==1) then {
  line <-> up 148.5 outline "pink2" \
aligned sprintf("\v'-6p'%g", maxpsht/2)
}
  }
}
define foldmarks {
  hdo=60
  fmd=105
  fmw=5
  {
  if ($1=="top" || $1=="both") then {
move to Header .nw down hdo+hl right fmw
{ line left fmw outline "red" }
if (lbls==1) then {line <-> up hdo+hl outline "red" aligned sprintf("\v'-6p'%g", hdo+hl)}
  }
  if ($1=="bottom" || $1=="both") then {
move to Header .nw down fmd+hdo+hl right fmw
{ line left fmw outline "red" }
if (lbls==1) then {
  move down maxpsht-fmd-(hdo+hl);
  line <-> up maxpsht-fmd-(hdo+hl) outline "red" \
aligned sprintf("\v'-6p'%g", maxpsht-fmd-(hdo+hl))
}
  }
  if ($1=="both" && lbls==1) then {
line <-> up fmd outline "red" aligned sprintf("\v'-6p'%g", fmd)
  }
  }
}
paper
hdr
punchmark
foldmarks("both")
#PF Flyback to position where .PS started
.PF
.vs
.PS
define headerlabel {
  H: box invis wid 210 ht hl "\fRHeader\fP" "\f(TIDIN 5008\fP" "" ""
  if form=="A" then {
box invis at H.c - (0, .5*lh) "\fIForm A\fP"
  } else {
box invis at H.c - (0, .5*lh) "\fIForm B\fP"
  }
}
define addressfield {
  afh=45
  afw=80
  aoo=5
  aow=afw+aoo
  lhadjust=linethick/4
  # Fill
  {box wid afw ht afh color "grey90" with .nw at H .sw + (po, lh-lhadjust);}
  A: box wid aow ht afh with .nw at H .sw + (po-aoo, lh-lhadjust) "\fRAddressfield\fP";
  if (lbls==1) then {
{
  line <-> left aow with .c at A .s + (0, 10) outline "grey70" sprintf("%g", aow) "";
  line <-> up afh with .sw at A .sw + (10, 0) aligned sprintf("%g", afh) ""
}
{ line <-> left afw with .c at A .s + (2.5, 7.5) "" sprintf("%g", afw) }
{
  line <-> left po-aoo sprintf("%g", po-aoo) "" at A .l # distance to left page edge
  line <-> right aoo sprintf("%g", aoo) "" at A .l # inner addressfield padding
}
  }
}
define infoblock {
  ibwm=75
  ibhm=40
  I: box dashed wid ibw ht ibh shaded "grey90" with .ne at H .se + (-10 , lh-5) \
  "\fRInformationblock\fP" sprintf("%g\(mu%g", ibw, ibh) ""
  if (lbls==1) then {
{
  line -> dashed left ibw with .c at I .s + (0, 0) sprintf("\fRvariable <=\fP %g", ibwm) ""
  line <- dashed up ibh with .sw at I .sw + (0, 0) aligned "" sprintf("\fRvariable >=\fP %g", ibhm)
}
{ line <-> right 10 "10" "" at I .r} # distance to right page edge
  }
}
define textblock {
  ibho=0
  if ibh>40 then {
ibho=ibh-40
  }
  tbw=maxpswid-po-po+5
  blanks=4*lh # (2 blank lines between addressfield/information block, 1 blank to page, 1 blank to footer)
  tbh=maxpsht-hl-afh-blanks-fth-lh-10 # 10 = bottom page margin
  if ibh>afh then {
tbh=tbh-ibho
  }
  T: box wid tbw ht tbh dashed shaded "grey90" \
with .nw at A .sw + (5, -(lh*2+ibho)) "\fRContent\fP"
  if (lbls==1) then {
{
  line <-> right tbw sprintf("%g", tbw) "" at T .nw + (0, -10)
  line <-> dashed up tbh \
at T .sw + (0, 0) \
aligned "" "" sprintf("\fRvariable \(ti%.2g lines (%gmm), 

Re: Macros for writing (German) letters?

[Alexis]

Hi Tim,

funny you should ask.

I've been working on my own groff macro package to produce documents
that conform to DIN 5008 for quite some time now.
Just a few days ago I started with the implementation of yet another
generation of said macro package that includes the learnings from
previous generations and better understanding of DIN 5008:2020.

The motivation to write a new macro package from scratch rather than
integrate it into an existing one was to focus on and learn the details
of groff(7) while working through implementing the standard¹ and avoid
getting stuck on an issue with an existing macro package due to lack of
my understanding.

Would you and anyone else interested be willing to give feedback
on my macro package or even help with its implementation²?!
Although at this point I feel more comfortable to consider integrating
with an existing package.

A question for the groff maintainers:
What does it take for a new macro package to be considered for inclusion
in groff (e.g.: contrib), so folks like Tim feel the macro package is
"integrated into the groff ecosphere?"

To whet the appetite a bit please find attached a groff/gpic document
(din-5008-dimensions.roff) with which different variants (form a and b,
variable footer height and information block size) can be produced.
Simply change the "user configurable variables" like `form` or 
`informationblock_width`, `footer_height`, etc. and re-create the
document using:

  groff -Tpdf -p -dpaper=a4 -P-pa4 din-5008-dimensions.roff \
> din-5008-dimensions.pdf

I use a PDF version of din-5008-dimensions.roff to superimpose³
documents produced with my macro package onto it and verify that
the layout adheres to the dimensions given in the DIN 5008 standard.

Insight, advice, best-practices from long-term users and macro package
developers and maintainers is especially welcome and much appreciated!


Best
Alexis

¹ using the special print bundle of the DIN 5008
  https://www.beuth.de/de/publikation/paket-din-5008-das-praxispaket/321130650

² Also happy to share my previous generations

³ using pdfcpu (https://pdfcpu.io):
  pdfcpu watermark add -mode pdf -- \
"din-5008-dimensions.pdf" "sc:1 abs, rot:0" \
letter.pdf check.pdf

[bug #65138] [troff] `device` request silently fails before first page begins

[G. Branden Robinson]

URL:
  

 Summary: [troff] `device` request silently fails before first
page begins
   Group: GNU roff
   Submitter: gbranden
   Submitted: Mon 08 Jan 2024 10:37:59 AM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Warning/Suspicious behaviour
  Status: In Progress
 Privacy: Public
 Assigned to: gbranden
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 08 Jan 2024 10:37:59 AM UTC By: G. Branden Robinson 
Affects _groff_ 1.22.4.


$ /usr/bin/groff --version | head -n 1
GNU groff version 1.22.4
$ printf '.device pdf: foobar\n' | /usr/bin/groff -ww -Z
x T ps
x res 72000 1 1
x init
p1
x trailer
V792000
x stop


Situations like this seem to be handled in _div.cpp_ with a fairly casually
worded fatal error message.


$ git grep -C1 sorry src/roff/troff/div.cpp
src/roff/troff/div.cpp-  if (before_first_page && begin_page())
src/roff/troff/div.cpp:fatal("sorry, I didn't manage to begin the first
page in time: use an explicit .br request");
src/roff/troff/div.cpp-  vertical_size v(vs, post_vs);
--
src/roff/troff/div.cpp-// This can only happen with the .output request.
src/roff/troff/div.cpp:fatal("sorry, I didn't manage to begin the first
page in time: use an explicit .br request");
src/roff/troff/div.cpp-  const char *s = asciify(c);
--
src/roff/troff/div.cpp-  if (before_first_page && begin_page())
src/roff/troff/div.cpp:fatal("sorry, I didn't manage to begin the first
page in time: use an explicit .br request");
src/roff/troff/div.cpp-  the_output->copy_file(page_offset, vertical_position,
filename);


But it gives the user sound advice.


$ printf '.br\n.device pdf: foobar\n' | /usr/bin/groff -ww -Z
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X pdf: foobar
n12000 0
x trailer
V792000
x stop


I bet myself that `fl` would work, too, and I won!


$ printf '.fl\n.device pdf: foobar\n' | /usr/bin/groff -ww -Z
x T ps
x res 72000 1 1
x init
p1
V12000
H72000
x font 5 TR
f5
s1
V12000
H72000
md
DFd
x X pdf: foobar
n12000 0
x trailer
V792000
x stop









___

Reply to this item at:

  

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

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

[G. Branden Robinson]

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

This isn't a strict dependency, but see bug #64484.


___

Reply to this item at:

  

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

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

[G. Branden Robinson]

URL:
  

 Summary: [troff] support construction of arbitrary byte
sequences in device control commands
   Group: GNU roff
   Submitter: gbranden
   Submitted: Mon 08 Jan 2024 10:13:02 AM UTC
Category: Core
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: Mon 08 Jan 2024 10:13:02 AM UTC By: G. Branden Robinson 
This is my generalization of Deri's `stringhex` request in the deri-gropdf-ng
branch.

In my working copy, I embedded the idea where the code would go.


diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index a0b987634..f6e5b1279 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -5571,7 +5571,7 @@ static node *do_non_interpreted()
   return new non_interpreted_node(mac);
 }
 
-static void encode_char(macro *mac, char c)
+static void encode_char_for_device_control(macro *mac, char c)
 {
   if (c == '\0') {
 if (tok.is_stretchable_space()
@@ -5600,6 +5600,13 @@ static void encode_char(macro *mac, char c)
   else if (strcmp("ti", sc) == 0)
mac->append('~');
   else {
+   // TODO: Support '\[u]' for all devices to support
+   // transmission of arbitrary data to the output device.  It's a
+   // misnomer--this doesn't necessarily represent a Unicode code
+   // point, but this syntax beats inventing a new one for this
+   // esoteric purpose.  Whether one sends \[uAABB],
+   // \[u00AA]\[u00BB], or the latter's byte-swapped counterpart is
+   // an interface detail that the output device must specify.
if (font::use_charnames_in_special) {
  if (sc[0] != (char)0) {
mac->append('\\');
@@ -5612,9 +5619,14 @@ static void encode_char(macro *mac, char c)
mac->append(']');
  }
  else
- error("special character '%1' cannot be used within"
-   " device control escape sequence", sc);
+   error("special character '%1' cannot be used within a"
+ " device control escape sequence", sc);
}
+   else
+ // TODO: Put '\[u]' support here.  Don't allow
+ // '\[u_]'.
+ error("special character '%1' cannot be used within a device"
+   " control escape sequence", sc);
   }
 }
 else if (!(tok.is_hyphen_indicator()
@@ -5668,7 +5680,7 @@ static node *do_special()
   c = '\b';
 else
   c = tok.ch();
-encode_char(, c);
+encode_char_for_device_control(, c);
   }
   return new special_node(mac);
 }









___

Reply to this item at:

  

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

[bug #64071] [troff] support construction of proper C strings for request arguments destined for the shell or file system

[G. Branden Robinson]

Update of bug#64071 (group groff):

 Assigned to:gbranden => None   


___

Reply to this item at:

  

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

Re: [Groff] Proper Small Caps.

[Robert Thorsby]

On 8/1/24 19:49, G. Branden Robinson wrote:

Nine years seems like long enough to wait to resurrect this thread.

At 2015-01-20T19:57:25-0500, Doug McIlroy wrote:


> ...


I recoil from text infected with capital pox, and don't see small caps as
much improvement. They do make sense in all-caps text, but sporadic
S\s-2MALL\s0 C\s-2APS\s0 or anything like it is not a cure for the pox.


I agree with Branden, especially as there are a number of good quality 
type1 font families that have a "proper" small caps font.


I think that a long time ago groff moved on from being purely a method 
of typesetting technical documents. Why should we munge small caps from 
standard fonts (and earn Doug's ire) when there are genuine small caps 
that we should be using when we need them.


Of course, Gaius Mulley's superb dropcaps macro would need revision. :-)

Robert Thorsby

Re: [Groff] Proper Small Caps.

[G. Branden Robinson]

Nine years seems like long enough to wait to resurrect this thread.

At 2015-01-20T19:57:25-0500, Doug McIlroy wrote:
> [Ralph Corderoy wrote:]
> > Thought it might be of interest given troff's long-time S\s-2MALL\s0
> > C\s-2APS\s0, especially used in the formatting of Unix.  IIRC, Dennis
> > Ritchie said they did it because the CAT gave them the possibility, but
> > it was regretted for the UNIX/Unix confusion it caused.
> 
> I think this is urban legend. Small caps were not used in UNIX manuals or
> in the Bell System Technical Journal articles about UNIX. Fairly early on,
> we in the Unix lab began to treat Unix as a proper noun, but the lawyers
> had trademarked the uppercase name and got their way in many publications,
> including the books by Kernighan and Ritchie and Kernighan and Pike.
> U\s-2NIX\s0 was very rare, if it ever happened at all.

I have found a 48-year-old instance of it in the wild!

Al Kossow just this week uploaded his copy of a printed Sixth Edition
manual to Bitsavers.  The mixed-case-but-still-small-caps (mis-)usage occurs
in only place that I can see, on page 3.  This page of the manual was not
produced by the CSRC, but by "AT SPCS", and/or "the Unix Operating
System Generic, PGC-1C300, Issue 2".

So presumably C. D. Perez, who appears to claim responsibility for that
version of the document, was not familiar with the typographical
conventions of the Unix lab.

https://bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf

> I recoil from text infected with capital pox, and don't see small caps as
> much improvement. They do make sense in all-caps text, but sporadic
> S\s-2MALL\s0 C\s-2APS\s0 or anything like it is not a cure for the pox.

Regards,
Branden


signature.asc
Description: PGP signature