[bug #64624] [grotty] some pic actions make following text illegible

[Dave]

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

[comment #3 comment #3:]
>   Using "naked" diff does not provide the surroundings to pinpoint the
> place where the difference occurs.

A bare diff does lack context but shows line numbers.  But in the comment #2
case, the location of the one line of difference is not terribly relevant,
given that the differing line (a grout "x F" command) has no effect on
rendered output.

>   So you have an extra line with three zeros.

No, the three zeroes are the output of "wc", indicating that that "diff"
produced no output.  I added "| wc" to try to be clear that there were no
differences (rather than seeming perhaps I had truncated the copy/paste), but
that seems to have backfired. (:

>   Output of "pic test.pic" (I use a different file name) is in the
> attachment, use "diff -u".

$ pic test.pic | diff - 64624.pic.out
5c5
< .lf 1 test.pic
---
> .lf 1 /home/bg/testen/prof.pic

Still only a difference in filename.

>   My input file "prof.pic" is in the attachment, compare with yours.

Your attached prof.pic is identical to the test.pic I originally posted
inline.

What are your attachments trying to illustrate?


___

Reply to this item at:

  

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

Re: [groff] 05/16: doc/meref.me.in: Update and revise.

[Dave Kemper]

Hi Branden,

I have comments on two of the numerous changes of this commit.

>  this material can then be resequenced
> +by the
> +.b pdfswitchtopage
> +macro (for PDF output),
>  by a tool that processes the output format,
>  or physically moved
>  to the beginning of the printed document.

Before this insertion, this was two verb phrases joined by an "and";
now it's written as a series of three items, but two are prepositional
phrases and one is a verb phrase, which is not a grammatical series.

> -Useful for forcing out footnotes,
> -but other than
> -that hardly ever used.
> -Must be followed by a
> +.\" Useful for forcing out footnotes,
> +.\" but other than
> +.\" that hardly ever used.

I sympathize with wanting to save "page" space (and, more generally,
striving for concision), but completeness and clarity ought to take
priority, and I feel this deletion reduces those.

A .bp or end of input are typically satisfactory ways to end a page or
a document, so a macro that ends a page but can only precede one of
those two things sounds nigh useless; the removed sentence was the
only thing that motivated the macro's use.  Conversely, users who find
a footnote missing in their document will no longer be able to
discover the macro that will restore it by searching the -me manual
for the word "footnote."  And even if they happen across .ep in the
manual, without that sentence there's still little clue this is the
solution they were looking for.

[bug #64639] [mom] odd output with #64421 reproducer

[G. Branden Robinson]

Update of bug #64639 (project groff):

  Status:   Confirmed => In Progress

___

Follow-up Comment #6:

Works for me!  Thanks as always for your swift attention to the report.

Updating status.


___

Reply to this item at:

  

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

Re: 1.23 prints some strange error

[G. Branden Robinson]

Hi Walter,

At 2023-09-11T19:45:30+0200, Walter Alejandro Iglesias wrote:
> On Mon, Sep 11, 2023 at 07:18:59PM +0200, Walter Alejandro Iglesias wrote:
> > I normally use OpenBSD in my desktop, which still comes with groff
> > 1.22.4.  Today I booted an old laptop with Debian testing (Devuan to
> > be more precise) and, after updating it, I could finally test groff
> > 1.23.
> > 
> > Lately, as I mentioned in this same list months ago, instead of the
> > conventional hyphenation method (my documents are in UTF-8 Spanish),

This suggests to me that preconv(1) _must_ be run before you try to
process your documents with this technique.

> > I've been using an application I wrote myself to generate a file
> > with entries like this:
> > 
> >   .hw a-ba-co
> >   .hw ár-bol
> >   .hw ca-ba-ña
> >   [...]
> > 
> > Also UTF-8 encoded.
> > 
> > I save those entries to a file called "hyphen.tr" and I source it
> > from my groff document:
> > 
> >   .mso hyphen.tr
> > 
> > 1.23 output (under Debian) seems to be identical to 1.22 (under
> > OpenBSD), I see no issue in the PDF, both have the same words broken
> > in the same syllables, that's why I don't understand why 1.23 throws
> > me hundreds of lines of error like the following:
> > 
> >   troff:/home/morlock/Documents/Roquesor/Groff/tmac/hyphen.tr:8777:
> >   error: expected ordinary or special character, got an escaped '%'
> > 
> > I took a look to the hyphen.tr file and didn't find no '%'
> > character.
> > 
> > Someone have any idea what happens here?
> 
> If instead of sourcing hyphen.tr from my macros with .mso I source it
> directly from the roff document with .so those error messages desapear.

Please share input file(s) that reproduce the problem, and a command
line that produces the diagnostic message you quoted above.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Long Heading lines using mom

[Heinz-Jürgen Oertel]

Am Montag, 11. September 2023, 20:47:29 CEST schrieb Peter Schaffter:
> Heinz-Jürgen --
> 
> On Tue, Aug 29, 2023, Peter Schaffter wrote:
> > On Tue, Aug 29, 2023, Heinz-Jürgen Oertel wrote:
> > > I'm translating from English to German so I have to overtake more
> > > ore less the long heading lines from a book.  Using mom i can
> > > split the text like
> > > 
> > > .HEADING 2 "Splitting this very long heading" "in two or more parts"
> > > 
> > > So far this works within the text part of the PDF document.  But
> > > if generating the TOC, the long lines will not break.
> > > What can I do?
> > 
> > This is something I didn't take into account when setting up the
> > formatting for TOC heading entries in mom.  For very long titles
> > there's TITLE_SHORT, but nothing equivalent for headings.
> > 
> > I'm working on a solution.
> 
> I believe the problem of super-long TOC entries is solved.  We can
> thank Tadziu for that.  Who'd'a thunk you needed to stick leaders in
> a diversion in order to tack them onto filled copy?
> 
> There is a lot of checking that has to be done with TOCs--they're
> tricky beasts--but the changes should be in the repo and on mom's
> web page within the next couple of days.  I've a few other issues
> to take care of beforehand.

Thanks Peter, Thanks Tadziu

Grüße
Heinz

Re: Long Heading lines using mom

[Peter Schaffter]

Heinz-Jürgen --

On Tue, Aug 29, 2023, Peter Schaffter wrote:
> On Tue, Aug 29, 2023, Heinz-Jürgen Oertel wrote:
> > I'm translating from English to German so I have to overtake more
> > ore less the long heading lines from a book.  Using mom i can
> > split the text like
> > 
> > .HEADING 2 "Splitting this very long heading" "in two or more parts"
> > 
> > So far this works within the text part of the PDF document.  But
> > if generating the TOC, the long lines will not break.
> > What can I do?
> 
> This is something I didn't take into account when setting up the
> formatting for TOC heading entries in mom.  For very long titles
> there's TITLE_SHORT, but nothing equivalent for headings.
> 
> I'm working on a solution.

I believe the problem of super-long TOC entries is solved.  We can
thank Tadziu for that.  Who'd'a thunk you needed to stick leaders in
a diversion in order to tack them onto filled copy?

There is a lot of checking that has to be done with TOCs--they're
tricky beasts--but the changes should be in the repo and on mom's
web page within the next couple of days.  I've a few other issues
to take care of beforehand.

-- 
Peter Schaffter
https://www.schaffter.ca

[bug #64639] [mom] odd output with #64421 reproducer

[Peter Schaffter]

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


[comment #4 comment #4:]

> Nevertheless Bjarni seems to have found a footgun.  (Perhaps he has a big
gun...or big feet.)
> 
> Could we use more input validation in `DRH`?

Not necessary, really.  I preferred to use mom's COLOR macro in the graphical
objects macro, but it's not essential.  This patch to DRH should clear up any
concerns Bjarni envisages.  The same change will be applied to the remaining
graphical object macros if it passes muster.

--- om.tmac.working.copy.bak02  2023-09-08 21:01:23.606662237 -0400
+++ om.tmac 2023-09-11 13:58:17.269063693 -0400
@@ -1934,7 +1934,6 @@
 .ds BLACK   \m[black]
 .ds white   \m[white]
 .ds WHITE   \m[white]
-.ds default black
 \#
 \# =
 \#
@@ -2844,17 +2843,12 @@
 .ds $RL_WEIGHT \\$1
 .ds $RL_INDENT \\$2
 .ds $RL_LENGTH \\$3
-.ie !'\\$4'' .ds $RL_COLOR  \\$4
-.el \{\
-.   ie '\\n[.m]'' .ds $RL_COLOR \\*[default]
-.   el .ds $RL_COLOR \\n[.m]
-.\}
 .nr #SAVED_WEIGHT \\n[#RULE_WEIGHT]
 .nr #SAVED_WEIGHT_ADJ \\n[#RULE_WEIGHT_ADJ]
 .di NULL
 .   if \\n[#NUM_ARGS]>=1 .RULE_WEIGHT \\*[$RL_WEIGHT]
 .di
-.COLOR \\*[$RL_COLOR]
+.if !'\\$4'' .gcolor \\$4
 .ie \\n[#NUM_ARGS]=0 \{\
 .   ie \\n[#INDENT_ACTIVE] \{\
 .  nr #RESTORE_L_LENGTH \\n[.l]
@@ -2899,7 +2893,7 @@
 .   if \\n[#NOFILL_MODE]=3 .CENTER
 .   if \\n[#NOFILL_MODE]=5 .RIGHT
 .\}
-.gcolor
+.gcolor default
 .nr #RULE_WEIGHT \\n[#SAVED_WEIGHT]
 .nr #RULE_WEIGHT_ADJ \\n[#SAVED_WEIGHT_ADJ]
 .rr #SAVED_WEIGHT


___

Reply to this item at:

  

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

Re: 1.23 prints some strange error

[Walter Alejandro Iglesias]

On Mon, Sep 11, 2023 at 07:18:59PM +0200, Walter Alejandro Iglesias wrote:
> Dear groff users and developers,
> 
> I normally use OpenBSD in my desktop, which still comes with groff
> 1.22.4.  Today I booted an old laptop with Debian testing (Devuan to be
> more precise) and, after updating it, I could finally test groff 1.23.
> 
> Lately, as I mentioned in this same list months ago, instead of the
> conventional hyphenation method (my documents are in UTF-8 Spanish),
> I've been using an application I wrote myself to generate a file with
> entries like this:
> 
>   .hw a-ba-co
>   .hw ár-bol
>   .hw ca-ba-ña
>   [...]
> 
> Also UTF-8 encoded.
> 
> I save those entries to a file called "hyphen.tr" and I source it from
> my groff document:
> 
>   .mso hyphen.tr
> 
> 1.23 output (under Debian) seems to be identical to 1.22 (under
> OpenBSD), I see no issue in the PDF, both have the same words broken in
> the same syllables, that's why I don't understand why 1.23 throws me
> hundreds of lines of error like the following:
> 
>   troff:/home/morlock/Documents/Roquesor/Groff/tmac/hyphen.tr:8777: error: 
> expected ordinary or special character, got an escaped '%'
> 
> I took a look to the hyphen.tr file and didn't find no '%' character.
> 
> Someone have any idea what happens here?

If instead of sourcing hyphen.tr from my macros with .mso I source it
directly from the roff document with .so those error messages desapear.


-- 
Walter

1.23 prints some strange error

[Walter Alejandro Iglesias]

Dear groff users and developers,

I normally use OpenBSD in my desktop, which still comes with groff
1.22.4.  Today I booted an old laptop with Debian testing (Devuan to be
more precise) and, after updating it, I could finally test groff 1.23.

Lately, as I mentioned in this same list months ago, instead of the
conventional hyphenation method (my documents are in UTF-8 Spanish),
I've been using an application I wrote myself to generate a file with
entries like this:

  .hw a-ba-co
  .hw ár-bol
  .hw ca-ba-ña
  [...]

Also UTF-8 encoded.

I save those entries to a file called "hyphen.tr" and I source it from
my groff document:

  .mso hyphen.tr

1.23 output (under Debian) seems to be identical to 1.22 (under
OpenBSD), I see no issue in the PDF, both have the same words broken in
the same syllables, that's why I don't understand why 1.23 throws me
hundreds of lines of error like the following:

  troff:/home/morlock/Documents/Roquesor/Groff/tmac/hyphen.tr:8777: error: 
expected ordinary or special character, got an escaped '%'

I took a look to the hyphen.tr file and didn't find no '%' character.

Someone have any idea what happens here?


-- 
Walter