[bug #60930] Integrate Peter Schaffter's font installer script into groff

[Dave]

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

[comment #11 comment #11:]
> There's no copyright affixed to the script, but I can add one and
> slap on a GPL notice if that would help.  Let me know.  There'll
> probably have to be a copyright assignment to the Free Software
> Foundation as well.  I don't keep up with the legalities, I'm afraid.

Nor I; someone more conversant with licensing will have to address this.  I
only brought it up as part of a list of potential obstacles I could see to
getting it into the package.  I don't know what if anything needs to be done
here.  My naïve assumption would be that whatever was done to get -mom in
would be sufficient.

> FWIW, a manpage is already written as a heredoc in the script.
> All it needs is to be marked up.

More good news!


___

Reply to this item at:

  

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

Re: uppercase german umlaut

[Dave Kemper]

On 2/5/24, hoh...@posteo.de  wrote:
> On Tue, 9 Jan 2024 01:13:45 -0600
> Dave Kemper  wrote:
>
>> 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.
>
> I quote myself:
> "The character emerges from a input file name. So it is missed by
> preconv somewhere, ..."

Since you haven't said what your pipeline is, I can't debug what
preconv is missing or why.  But in general if you're doing something
like:

someprog | gpic

where "someprog" is outputting UTF-8, then you should change the pipeline to:

someprog | preconv -eutf8 | gpic

Like all groff tools, gpic will not recognize UTF-8 input.  The
encoding has to be converted before gpic sees it.

> You completely miss the point of the utf8 sequence "ä" passes while
> "Ä" issues.

I didn't miss this.  Lennart explained this in his December 28 reply
in this thread, and I reiterated it in my December 29 reply, and again
in my January 2 reply.  In short: UTF-8 "ä" in a Latin-1 context is
interpreted as two Latin-1 characters whereas UTF-8 "Ä" in a Latin-1
context is one Latin-1 character and one invalid (to groff tools)
control character.

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

[G. Branden Robinson]

Update of bug#64155 (group groff):

 Assigned to:gbranden => deri   

___

Follow-up Comment #20:

Hi Deri,

[comment #19 comment #19:]

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

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


Before we go down a rabbit hole of instrumentation and/or GDB backtracing, I
noticed something there.

These file sizes are the same except for U-TR.  What's going on there?  Is the
U-TR in _/usr/share/groff/1.23.0/font/devpdf/_ a valid font file?  If so, how
does it differ from the one in
_/home/derij/groff-git/groff/build/font/devpdf/_?


___

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/

Re: [PATCH v3] [grotty]: Use terminfo.

[Lennart Jablonka]

Quoth G. Branden Robinson:

ACK.  I've gotten a bit sidetracked learning more about terminfo and
ncurses...and a dreaded, predictable thing happened.

I found the existing ncurses documentation frustrating and started
rewriting it.  (This is how groff got stuck with me.)

https://lists.gnu.org/archive/html/bug-ncurses/2023-09/index.html

Fortunately, ncurses is attentively maintained.  So instead of sucking
up a whole bunch of oxygen there as I did with groff, I found that it
behooves me to actually read the X/Open Issue 7 standard for curses.

That is a 420-page document, so it's taking some time to absorb.


Since you wrote this, every now and then I’ve looked at the 
ncurses-bug archives, scrolling through some of your patches.  
That’s a little fun.


If you haven’t finished rewriting the ncurses manual yet, are you 
perchance done absorbing X/Open Curses?  You know, just in case 
you want to take another look at that patch I sent a while ago.  
For grotty.  To use terminfo.

Re: Configuring groff 1.23.0 on Fedora 39 fails to find the URW base 35 fonts

[T . Kurt Bond]

On Mon, 05 Feb 2024 15:19:41 -0500,
Deri  wrote:
> Have you tried running configure with the flag:-
> 
> --with-urw-fonts-dir=/usr/share/fonts/urw-base35

As was mentioned in my original message to the list, I did use that
option to successfully configure groff which lead to a successful
build and install.

I'll note that the urw-base35 fonts are *not* part of the Fedora
ghostscript package.  It depends on the libgs package, which depends
on the urw-base35-fonts package, which depends on 11 other packages
that contain the various urw-base35 fonts.  There are a few other
other urw-base35-* packages, including one that provides legacy X11
fonts.

I'll also note that the Fedora packages for groff provide version
1.23, but I always install my own copies of of groff, and usually have
several different versions installed at the same time.

-- 
T. Kurt Bond, tkurtb...@gmail.com, tkurtbond.github.io  

Re: Configuring groff 1.23.0 on Fedora 39 fails to find the URW base 35 fonts

[Deri]

On Monday, 5 February 2024 16:51:29 GMT T.  Kurt Bond wrote:
> On Wed, 20 Dec 2023 04:52:31 -0500,
> 
> "G. Branden Robinson"  wrote:
> > Do any of the following directories exist on Fedora 39 and contain .afm
> > files alongside the fonts proper?
> > 
> >   _list_paths="\
> >   
> > /usr/share/fonts/type1/gsfonts/ \
> > /usr/share/fonts/default/Type1/ \
> > /usr/share/fonts/default/Type1/adobestd35/ \
> > /usr/share/fonts/type1/urw-base35/ \
> > /opt/local/share/fonts/urw-fonts/ \
> > /usr/local/share/fonts/ghostscript/"
> 
> No, none of those directories exist.
> 
> However, /usr/share/fonts/urw-base35 does exist and does contain .afm files.

Hi,

Have you tried running configure with the flag:-

--with-urw-fonts-dir=/usr/share/fonts/urw-base35

Cheers 

Deri

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

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[Dave Kemper]

On 2/5/24, G. Branden Robinson  wrote:
> As far as I know, groff has never extended AT troff syntax in _this_
> respect.
>
> The argument count to requests (unlike macros) is seemingly sacrosanct.

Groff extended the .ss request by adding an optional second parameter
where AT's took only one.  It's not exactly the same situation, but
would seem to cross the same minefield.

Re: Configuring groff 1.23.0 on Fedora 39 fails to find the URW base 35 fonts

[T . Kurt Bond]

On Wed, 20 Dec 2023 04:52:31 -0500,
"G. Branden Robinson"  wrote:
> Do any of the following directories exist on Fedora 39 and contain .afm
> files alongside the fonts proper?
> 
>   _list_paths="\
> /usr/share/fonts/type1/gsfonts/ \
> /usr/share/fonts/default/Type1/ \
> /usr/share/fonts/default/Type1/adobestd35/ \
> /usr/share/fonts/type1/urw-base35/ \
> /opt/local/share/fonts/urw-fonts/ \
> /usr/local/share/fonts/ghostscript/"

No, none of those directories exist.

However, /usr/share/fonts/urw-base35 does exist and does contain .afm files.
-- 
T. Kurt Bond, tkurtb...@gmail.com, tkurtbond.github.io  

[bug #65232] Russian hyphenation is not working

[Robin Haberkorn]

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

[comment #4 комментарий №4:]
> 
> [comment #3 comment #3:]
> > After switching from pdfroff (-Tps) to pdfmom (-Tpdf), hyphenation
suddenly works fine.
> 
> Glad to hear it.
>  
I forgot to mention, I also had to install a new version of the
LiberationSerif fonts as the previous ones I was using, apparently weren't
fully compatible with gropdf. There were for instance some space characters
that were not displayed correctly.

> > Moreover, it will even work with UTF8 input (-Kutf-8), even though that
causes other glitches.
> 
> What glitches are you seeing?
> 
With -Kutf-8, link texts generated by .pdfhref were sometimes missing -
seemingly random - characters.

> The input is coverted from UTF-8 to KOI8-R.  The hyphenation patters are
defined in terms of KOI8-R code points.  The formatter (GNU _troff_) decides
where the hyphens should go and performs the breaks.  The formatter converts
the input characters into internal data structures called "nodes" that do not
use an externally visible encoding.  Then, when generating device-independent
output, each glyph nodes is converted to a device-independent special
character command _if_ the output device supports its code point.  (If it
doesn't, you get a warning like "special character 'u0413' not defined".)
> 
Are you telling me that pdfmom is actually internally converting my text to
KOI8-R after noticing I did -mru?
This is obviously not the case as I tried to print some Cyrillic using .tm and
it comes out as Unicode escapes as would be expected after the sources are ran
through preconv.



___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

Re: .bp not working in groff 1.23.0 when it worked fine in 1.22.4

[G. Branden Robinson]

At 2024-01-23T22:13:26-0600, Dave Kemper wrote:
> On 1/23/24, G. Branden Robinson  wrote:
> > At 2024-01-23T20:52:34-0600, Dave Kemper wrote:
> >> However, .bp arguably shouldn't have been affected by the change,
> >> since it probably wasn't subject to the same historical ambiguity.
> >
> > I agree, and I wasn't happy about it.
> 
> I wonder if the proper way to address this lies in core groff.
> 
> Having no-space mode suppress .bp seems quirky, and at odds with the
> info manual's stated use case for the mode: "A paragraphing macro
> might ordinarily insert vertical space to separate paragraphs.  A
> section heading macro could invoke 'ns' to suppress this spacing for
> the first paragraph in a section."  (CSTR #54, befitting its terser
> nature, suggests no usage for .ns.)  But of course this behavior
> cannot be overturned unilaterally.
> 
> However, .ns currently takes no arguments -- but it could, a value to
> specify "suppress only vertical space, but not page breaks."  The
> behavior with no argument would be unchanged, so historical usage
> would work as it always has.
> 
> There are probably down sides to this I haven't thought of.

I wonder the same thing.  Similar extensions to specific AT request
syntax have occurred to me before as well, but every time I've looked
into the issue, I've noticed something...

As far as I know, groff has never extended AT troff syntax in _this_
respect.

The argument count to requests (unlike macros) is seemingly sacrosanct.

I'm unaware of any explicit exhortation against doing this, but having
seen AT troff source and GNU troff's own, I'm going to
venture a guess that the manually-constructed recursive descent parsers
that both use make this a dangerous frontier to cross.  If the
formatter's grammar had been expressed formally, say with Yacc, it might
be a different story.  But there is no general request argument parser.
When the formatter decided it has seen a request, it hands control off
to a function which has total discretion to do whatever it wants with
the input stream; the parser's input reader is global state, no less.

The problem here isn't that we can't do this in GNU troff; the problem
is that if another formatter is given input for GNU troff that exercises
such an extension, the result may be worse than simply not supporting
the extension, or snarling an error message, or ignoring input until the
next line--we might instead kick that formatter into an undefined state.

One of my first lessons in this area was discovering that I had to call
`skip_line()` at the end of the logic implementing every GNU troff
request.  What this does is eat up white space and comments and position
the input cursor at the start of the next input line.[1]  In other
parsers, a command handler might be handed "a line" or an argument list.
In troff, you get the original input stream.  The world is yours.

So I'm uneasy with solving the problem this way because the language is
so ill-defined in this respect.

Because macro calls are interpreted in a general manner, they don't have
this problem.  But a macro can't solve this problem in the formatter.

Regards,
Branden

[1] _If_ you could count on every *roff to do the equivalent of
`skip_line()` in _every_ request handler, then my concern is
misplaced.  Personally, I don't trust C programmers anywhere near
enough to rely on such an assumption.


signature.asc
Description: PGP signature

Re: More on Tibetan, or rather: ligatures

[G. Branden Robinson]

At 2024-01-24T19:39:25-0600, Dave Kemper wrote:
> On 1/22/24, Oliver Corff  wrote:
> > yes, I did have a look at that section of the groff documentation,
> > and I must confess that I read the text as non-exhaustive, meaning
> > the five specific ligatures are built-in, with the option to
> > increase the repertoire of ligatures.

An unhappy fact is that James Clark put "generalized ligatures" on the
GNU troff TODO list in 1991 (or earlier) and we still don't have 'em.

https://git.savannah.gnu.org/cgit/groff.git/tree/troff/TODO?h=1.02#n113

> You're right, the wording there isn't as clear as it could be.  The
> sentence "Some fonts may include 'ft' and 'ct' ligatures; they are
> archaic and GNU 'troff' does not (yet) support them" is misleading in
> its specificity.  I submit that "Some fonts may include other
> ligatures; GNU 'troff' does not (yet) support them" is both terser and
> clearer.

I'll keep this mind for the the next time I whack on that part of the
manual.

> It could even add a clause about how certain languages (such as
> Tibetan) rely on these ligatures not just for typographic aesthetics,
> as with the English-language ones, but to render the language
> correctly.  I'm not sure that communicates any additional information
> to the reader, but I know zilch about Tibetan, so you might better be
> able to suggest a wording that makes the situation clear.

Regards,
Branden


signature.asc
Description: PGP signature