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

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

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

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