[Groff] me macros, page break too early : was Re: mm-macros, page break too early

[Deri James]

On Tuesday 05 Mar 2013 15:26:01 Dave Kemper wrote:
> > I have sometimes the problem, that a list triggers a page break too early,
> > e.g. when a list or a picture would easily fit onto the page.
> 
> I reported a similar bug in the -me macros (at
> http://lists.gnu.org/archive/html/bug-groff/2012-12/msg00011.html),
> though no one has debugged it yet.  If similar things happen in more
> than one macro set, I wonder if there's some root cause in groff itself.
> 
> One curious thing about my bug is that it's not triggered with ASCII
> output, just with PostScript.  Does your happen this way also?

I'm afraid I can't duplicate the problem given the example in your post at the 
URL above. The postscript/pdf produced by groff starts page 2 with 53 (not 
54), and if I add a line before the block the whole block moves to the top of 
page 2. (groff 1.22.2 - papersize A4)

Deri

Re: [Groff] need help with composite glyphs

[Deri James]

On Monday 29 Jul 2013 09:27:05 Heinz-Jürgen Oertel wrote:
> Am Sonntag 28 Juli 2013, 22:24:03 schrieb Werner LEMBERG:
> > > If I code the text with \[u u030A] I expect it to be in the PDF.
> > 
> > This glyph is only contained in the URW fonts.  For example, try this
> > 
> > with the PDF backend:
> >   .fam U-T
> >   uring: \[u u030A]
> >   
> > Werner
> 
> Thanks Werner
> I now use -Tpdf and "Latin small letter u with ring above"
> and most others work.
> I still have sometimes problems with the special glyphs.
> It seems that it depends on the order they are called.
> At the moment I'm not able to reproduce it clearly with a small example.
> Attached is a part of the generated PDF (as png, it is smaller)
> and the generated HTML.
> 
> The word is written as groff test "\[vs]\[n ah]\[u016F]ra"
> 
> As said it does work mostly, but not always.
> And it happens, whether i use \[u u030A] or \[u016F].
> 
> 
> best regards
> Heinz

The problem you are seeing may well be a bug with the new pdf driver, 
particularly as 
you only see it in certain circumstances, if you can send me an example of the 
troff 
source which exhibits the problem, I will be able to debug if it is a problem 
with the 
driver.

One workaround, if it is indeed a bug in gropdf, is to copy all the U- fonts 
from devpdf 
to devps and copy the relevent lines from devpdf/download to the devps/download 
file. 
This will mean you can process the input with the traditional grops | ps2pdf 
method (to 
see if the issue goes away!).

Cheers 

Deri

Re: [Groff] Firt letters overlapping with MOM

[Deri James]

On Saturday 05 Oct 2013 12:34:33 Blake McBride wrote:
> Greetings,
> 
> I installed 1.22.2 and current on my Mac with:
> 
> ./configure --prefix=/usr --mandir=/usr/share/man
> make
> sudo make install
> 
> (My Mac has GCC 4.2.1)
> 
> t.mom contains:
> 
> Now is the time for all good men to come to the aid of their party.
> Now is the time for all good men to come to the aid of their party.
> 
> 
> 
> I tried:
> 
> groff -T pdf t.mom >t.pdf
> 
> and it worked perfectly.  But when I do:
> 
> groff -T pdf -mom t.mom >t.pdf
> 
> The "o" and "w" of the first word only partially overlap.  Interestingly,
> the second copy of the sentence displays perfectly.
> 
> As I stated, I tried 1.22.2 and the current snapshot.  Same result.  I did
> try to check to be sure there isn't another copy in /usr/local or
> /opt/local.
> 
> I have no idea what to do, or why the -mom would have this effect.
>  Appreciate any help!
> 
> Blake McBride

Hi BlaKe,

One fix for this is to locate the two lines in om.tmac which start:-

.if '\\*[.T]'pdf' \X'papersize=

and add "\c" to the very end of both lines.

Cheers

Deri

Re: [Groff] Firt letters overlapping with MOM

[Deri James]

On Saturday 05 Oct 2013 17:30:13 Blake McBride wrote:
> Thanks.  That does fix the problem.
> 
> Why wouldn't this (perhaps with a condition) not be in mom by default?

I think it will be. (When Peter sees this) :-) 

The problem is only visible when you include the mom macro set but the 
file (t.mom) does not include any mom specific commands, so mom itself 
should do nothing. Without the \c on the end of those two lines it was 
actually adding a single space which was being printed before the "No".

Cheers

Deri

Re: [Groff] The future redux

[Deri James]

I have, so far, kept silent on future direction for groff, since my own use for 
groff is probably very rare, so my opinion should not carry much weight. I 
use groff as a typesetting engine called from a front end which produces a 
troff file which is then passed to groff to produce output. The troff file uses 
just the basic troff commands, no macro calls. For this reason I am only 
interested in the presentation side of the argument.

I completely agree with the separation of style content and logic, but I do 
this in the front end rather than in the troff file. The front end is designed 
to produce high quality custom reports, the sort of thing you receive from 
your bank showing performance of investments or pension pot, so every 
report is different for each person because the investments are different, 
and potentially this report may go to thousands of customers, each one 
different.

There are many packages in the report production arena, and I know of 
many large companies who have discovered that they do not scale well to 
large volumes, whereas groff has a linear speed based on the size of the 
troff file.

The front end I have written, which sits in front of groff, takes 3 types of 
information:-

A csv type file, this is the content, i.e. the data which will appear in the 
report,
A template file which specifies the style of the report, and
A program file which is my own report definition language, which supplies 
the logic for moving the content to the template.

The template file has similarities to a css file (this was developed before 
css came out as a standard), plus a bit of a little known desktop 
publishing program for the Acorn Archimedes (Ovation) in the late 80s.

The program file would look quite familiar to anyone who knows "filetab" 
(RPL-3 on IBM). This is a decision table based language. 
(http://en.wikipedia.org/wiki/Filetab

These three elements are combined to produce a troff file which is then 
run through groff.

Since this system is purely intended to produce files for printing (pdf or 
postscript) or viewing (pdf locked to prevent editing). There is no semantic 
markup required, all I want is a fast engine which handles the typography.

If you are interested in looking at an example of a single page produced 
by the front end system using groff there is an example in the tar archive 
at:-

http://chuzzlewit.co.uk/Example.tgz

Deri

Re: [Groff] The future redux

[Deri James]

On Wed 26 Feb 2014 11:46:32 Ralph Corderoy wrote:
> Hi jkl,
> 
> > > man pages don't really need expressive typography.
> > 
> > Man pages are constrained by xterm.  A better display system would
> > invite tables, graphs, equations, and links.
> 
> I don't think they are.  Or they didn't used to be.  It was common to
> see man pages with `.if n' and `.if t', with the troff presenting the
> same data in better form, e.g. ASCII art versus pic(1).  man pages used
> to be commonly printed and high-quality output desired, screen devices
> were glass TTYs, and Sun would ship printed paper man pages in 
folders.
> I still check the PDF of a man page I alter as it shows flaws that
> grotty(1) can't.
> 
> Cheers, Ralph.

I hardly ever use "man command", nearly always do "man -t command" 
because I have changed /etc/man.config to have the line:-

TROFF   groff -Tpdf -mandoc | /usr/bin/okular -

So when I issue that command the page shows up in an okular window, a 
much easier read, adjust zoom for comfort and great searching.

Cheers 

Deri

Re: [Groff] The future redux

[Deri James]

On Wed 26 Feb 2014 13:46:22 Walter Alejandro Iglesias wrote:
> What do you want in a man page?  Videos?  3D holograms?

Only if they would help give an answer to the question you are trying to 
answer!

> XTerm does not constrain nothing.  It does what is expected from a 
terminal.
> Do you think your lawnmower needs a fix because you can take a ride on 
it?
> It's not a motorcycle.

It probably depends on the size of the lawn.

> Man pages are not tutorials or complete manuals, they're just an
> aide-mémomire. It takes more time to open Okular than reading what 
you
> need!

A simple, but completely unreliable, test, just opening a man page with 
and without okular:-

[derij@pip ~]$ time man df

real0m1.577s
user0m0.033s
sys 0m0.008s

[derij@pip ~]$ time man -t df

real0m1.863s
user0m0.483s
sys 0m0.064s

The unreliability is down to the speed I can press Q or Alt-F4, but it does 
show that you are correct that okular is slower to start, by about .3 of a 
second. Of course, if you are not already in a KDE environment, then the 
start time for okular would include the whole kde stack, making it very slow 
indeed. If such is the case, and, since you are using xterm rather than 
konsole, it probably is, then perhaps using xpdf rather than okular would 
improve your experience.

> Seriously guys, you need a big dose of Common Sense.

My post was intended to point out that groff (rather than nroff) is still 
useful for man pages, for people who find it easier to read if the content is 
typographically superior to reading terminal text. My mistake was to not 
mention that other pdf readers may be more suitable for individual 
setups.It may be necessary to alter the man.config command I gave for 
other pdf readers.

Cheers 

Deri

Re: [Groff] The future redux

[Deri James]

On Wed 26 Feb 2014 10:19:07 Mike Bianchi wrote:
> I cannot find  man.config  or any reference to it in Debian 7.4 (wheezy).
> 2.6.2   2012-06-18   MAN(1)
> Only  manpath.config .
> 
> What am I missing?
> 
> -- 
>  Mike Bianchi
>  Foveal Systems
> 
>  973 822-2085

It looks like on debian the answer is to create a shell script called 
"mandb_tfmt" to do exactly what you want when man -t is used. Unfortunately my 
only version of debian is on a sheevaplug which is not up to running an X 
server, but the man page says:-

   A formatting pipeline is formed from the filters and the primary 
formatter (nroff or  [tg]roff  with  -t)  and  executed.
   Alternatively,  if  an  executable program mandb_nfmt (or mandb_tfmt 
with -t) exists in the man tree root, it is executed
   instead.  It gets passed the manual source file, the preprocessor 
string, and optionally the device specified with -T  or
   -E as arguments.

So it should be possible to achieve the same sort of thing. I believe the 
difference is that my Mageia uses man version 1.6g and debian (6.0.3) uses 
man-db 2.5.7. 


I also found this:-

5.5. Format scripts
It is very likely that alternate systems manual pages may require non-standard 
macro packages or possibly
even special pre-processors. To tackle such problems, special format scripts 
may be created on a per man-
ual hierarchy basis.

If the file
/mandb_nfmt
exists and is executable, it is expected to be able to correctly format a 
manual page originating from  to its standard output. It will be supplied with either two or 
three arguments:

• manual page filename
• pre-processor string
• ouput device (optional)

Similarly, if the option −T or −t was supplied to man and the file
/mandb_tfmt
exists and is executable, it will be used in the same way.

An example of such a script, supplied by Markus Armbruster 
, who provided sup-
port for external formatter scripts, can be found as tools/mandb_[nt]fmt
The script can be used as both a NROFF and TROFF/GROFF format script and can be 
installed as
mandb_nfmt and hard linked to mandb_tfmt after modification appropriate for 
your particular site.

Re: [Groff] The future redux

[Deri James]

On Tue 25 Feb 2014 13:24:15 Eric S. Raymond wrote:
> No, no, *no*.  PDF on the Web is evil and must die.
> 
> Here's why.  It breaks the flatness of URL-space.  HTML documents can 
point
> at PDFs, but not *into* PDFs.

I get slightly different results.

If I use the url:-

http://chuzzlewit.co.uk/eric.pdf#eric2

In a browser. The pdf opens at the named destination eric2. It works both 
with rekonq (kde browser) which passes the url to okular, and firefox 
configured to use embedded adobe reader. I know there are other 
readers/browsers which do not support this, but that's part of choosing 
the right browser for an individual.

Cheers 

Deri

Re: [Groff] man pages (tangential to Future Redux)

[Deri James]

On Fri 28 Feb 2014 21:16:37 Walter Alejandro 
Iglesias wrote:
> When people is lazy to read no formating is 
enough to
> make them happy

The reason I prefer a typeset man page is 
because it aids comprehension of what I am 
reading. I'm all for an easy life me, anything 
which smooths the stormy seas of life is a 
boon.

Re: [Groff] The future redux

[Deri James]

On Sat 01 Mar 2014 11:29:08 Ralph Corderoy wrote:
> Then there's Dale Dougherty and Tim O'Reilly's _Unix Text Processing_.
> http://home.windstream.net/kollar/utp/  Given they were using troff to
> produce their books, and continued to use groff for a long time to do
> the production even when they moved to XML mark-up, they knew the
> subject.
> 
> Cheers, Ralph.

Or the version with the "clickable" index at:-

http://chuzzlewit.co.uk/utp_book-1.1.pdf

(Larry has not integrated my patch yet).

Cheers 

Deri

Re: [Groff] Groff to pdf/Windows

[Deri James]

On Thu 06 Mar 2014 09:21:57 Keith Marshall wrote:
> A further advantage of using pdfroff is that it will automatically
> handle the multiple groff passes required to resolve pdfmark cross
> references, if you use the -mpdfmark macro set.  I don't know if -Tpdf
> will provide a similar level of support; perhaps Deri could comment?

If you are using mom the pdfmom command will do the forward references for you. 
If you are not using mom the actual command is:-

groff -Tpdf -dPDF.EXPORT=1 -z $cmdstring 2>&1 | grep '^.ds' | groff -Tpdf - 
$preconv $cmdstring

(NB Note the single hyphen '-' before $preconv).

$cmdstring should be replaced with any groff params and your filename, and
$preconv is any particular -k or -K switches you need.

Keith, is there any chance I could add something along these lines to pdfroff 
if the -T pdf switch is passed to pdfroff?

Deri

Re: [Groff] Groff to pdf/Windows

[Deri James]

On Thu 06 Mar 2014 18:08:10 Keith Marshall wrote:
> On 06/03/14 16:21, Deri James wrote:
> > If you are not using mom the actual command is:-
> > 
> > groff -Tpdf -dPDF.EXPORT=1 -z $cmdstring 2>&1 \
> > 
> >   | grep '^.ds' | groff -Tpdf - $preconv $cmdstring
> 
> So, you're assuming that just one preliminary pass is sufficient to
> resolve the cross references?  That may not be so, and pdfroff is not so
> naive; it performs at least two such passes, and then as many more as
> may be necessary, until two consecutive passes generate identical
> reference dictionaries, (or until it becomes clear that no ultimately
> stable layout is achievable).

It's a bit simpler for me because part of the logic is in the output driver 
(gropdf). All I need are the tag names and the descriptive text associated 
with them. The positioning of hot spots is done with these calls to gropdf:-

\X’pdf: markstart /ANN definition’

and

\X’pdf: markend’

So if the hotspot "moves" due to previously unfound references which are 
expanded on the second run, the markers also move. (There are also a 
pair of other commands - \X’pdf: marksuspend’ and \X’pdf: markrestart’ 
which are intended to be used in page trap macros to prevent 
headings/footings being included in the hot spotting when the hotspot 
crosses a page boundary).

I had it much easier than you having to do the hotspot location 
calculations in a groff macro.


> > Keith, is there any chance I could add something along these lines to
> > pdfroff if the -T pdf switch is passed to pdfroff?
> 
> Sure.  You have the source, to modify as you see fit, (or, are you
> asking me to help you with that?)

No, I'm happy to suggest a patch, it's just that your scripting 
style/knowledge is far superior so I would welcome the opurtunity to send it 
to you for perusal first.

Deri

Re: [Groff] Groff to pdf/Windows

[Deri James]

On Thu 06 Mar 2014 21:47:15 Ralph Corderoy wrote:
> I'm guessing that
> 
> grep '^\.ds'
> 
> might be the intent.
> 
> Cheers, Ralph.

Yes, indeed! Thanks.

Re: [Groff] Back to the future]

[Deri James]

On 06/03/14 16:35, Eric S. Raymond wrote:
> No, what I want is for all Unix documentation to be properly wenbbed 
and 
> crosslinked.

I find it difficult to understand why groff needs a .hygiene, maybe it's 
because I'm a dirty rascal! It seems to be a switch which is designed to 
stop naughty man pages from working, in the hope this will prompt the 
man page authors into changing them. But these are only "naughty" 
because they don't play nicely with Eric's tool set, not that there is 
anything wrong with them from the groff typesetting perspective.

So we are pondering whether to create this work for an unknown number 
of man page authors. The reason for doing this should be defensible, but I 
wonder whether it is?

The stated reason for this is the desire to make the man pages 
browseable, which requires semantic markup of the document in order to 
produce decent html. However, there are other routes to this goal, which 
do not require the participation of recalcitrant man page authors, nor 
patches to documents.

All browsers will happily display pdf documents, and since groff can easily 
produce pdf documents which include embedded URLs, is there any 
reason why they should not be the medium for having browseable man 
pages. A little bit of work today has got me to a working solution.

First you need a protocol for man pages. My linux already has the protocol 
"man:/" (which is tied into use some form of "man2html" which produces 
less than beatiful results), so I hijacked that protocol by changing it to call 
a program (pdfmansec) which takes the URL "man:/section/name" and calls 
"man -t -S section name". Meanwhile, the man config file is changed to use 
the pipeline "pdfman | groff -T pdf -mandoc | okular -". The program pdfman 
simply adds the required calls to pdfhref etc. The results of this are in can 
be seen here:-



It contains a few random pdf man pages, as examples, the two programs I 
added to my system, and the kde protocol file. The links to other man 
pages in the pdf examples will not work unless you have configured the 
"man:/" protocol for your system, but any links to the web will work. It even 
worked in the url bar for firefox, when it asks for what to use for this 
protocol enter 'pdfmansec'. Or you can still use 'man -t cmd' from the 
console to get the clickable pdf.

It is still in need of some work and if you explore your man pages using the 
clickable links, I'm absolutely sure you will find some which break the pdf, 
but I've only spent a day and a half so far. Any comments or suggestions 
gratefully received.

When my wife enquired "What have you been up to in the office?" and my 
reply was "Playing with my man pages.", I don't think she quite understood 
what I meant.

Deri

Re: [Groff] Groff to pdf/Windows

[Deri James]

On Thu 06 Mar 2014 17:24:09 Peter Schaffter wrote:
> > Keith, is there any chance I could add something along these lines
> > to pdfroff if the -T pdf switch is passed to pdfroff?
> 
> I'm all for this.  pdfmom performs splendidly.  Nary a hitch with
> forward references.  Non-mom users could really benefit from the
> convenience.

Keith is correct. There is an occasion where three passes are needed. 
When a hot link description includes a page number (\n[%]) if the 
expansion to the text before this point causes it to move to the next page 
the descriptive text, collected on the first pass, will be out of date. So a 
third pass is necessary.

And the command becomes:-

groff -Tpdf -dPDF.EXPORT=1 -z $cmdstring 2>&1 | grep '^\.ds' | \
groff -Tpdf -dPDF.EXPORT=1 -z - $cmdstring 2>&1 | grep '^\.ds' | \
groff -Tpdf - $preconv $cmdstring

Cheers 

Deri

Re: [Groff] : New groff preprocessor for Perl parts in groff files.

[Deri James]

On Mon 10 Mar 2014 16:30:13 Ingo Schwarze wrote:

> Besides, enforcing build order by ordering directories/files
> in list variables does not work at all in parallel builds.
> I definitely know that this caused fallout in the past, even
> before Bernd's commit, at exactly the place Bernd is now fiddling
> with.
> 
> So once i get my stuff going, expect a patch to Makefile.in
> from me in any case.  It is broken either way, Bernd just made
> it worse, i suspect.
> 
> Yours,
>   Ingo

I think you might be referring to Mike Frysingers fix to correct a problem 
with the generation of mom-pdf.pdf:-

commit 290eaaac6cfc33856cd683838accc72ccf3e5a84
Author: Mike Frysinger 
Date:   Sun Dec 22 08:28:16 2013 +0100

Fix parallel build with gropdf and mom examples.

The `contrib/mom/examples/' directory uses the helper script from
`src/devices/gropdf/'.  Currently though, parallel builds might fail
like so:

  ...
  make[2]: Entering directory `.../groff-1.22.2/contrib/mom'
   examples/letter.mom >examples/letter.pdf
   examples/mom-pdf.mom >examples/mom-pdf.pdf
  /bin/sh: .../groff-1.22.2/src/devices/gropdf/pdfmom: No such file or 
directory
  make[2]: *** [examples/letter.pdf] Error 127
  /bin/sh: .../groff-1.22.2/src/devices/gropdf/pdfmom: No such file or 
directory
  make[2]: *** [examples/mom-pdf.pdf] Error 127
  make[2]: Leaving directory `.../groff-1.22.2/contrib/mom'
  make[1]: *** [contrib/mom] Error 2
  ...
  make[2]: Entering directory `.../groff-1.22.2/src/devices/gropdf'
  sed -f .../groff-1.22.2/arch/misc/shdeps.sed \
  -e "s|@VERSION@|1.22.2|" \
  -e "s|@PERLPATH@|/usr/bin/perl|" ./pdfmom.pl >pdfmom

The top level makefile tries to account for this in general with
OTHERDIRS, but looks like `src/devices/gropdf/' was added to this
variable (which holds `contrib/mom/' too) because gropdf installs a
shell script, and the other prog vars require it to be a dir of
things to compile.

  URL: http://crbug.com/324116
  URL: https://bugs.gentoo.org/487276

* Makefile.in (SHPROGDIRS): Declare.
(PROGDIRS): Add $(SHPROGDIRS).
(OTHERDIRS): Delete src/devices/gropdf.
($(SHPROGDIRS):): Add to existing rule.
($(OTHERDIRS):): Depend on $(SHPROGDIRS).

I'm not sure whether Bernd's amendment affects this, the parallel build 
problem was intermittent, depending on the speed of the server, number 
of parallel streams, etc..

Cheers 

Deri

Re: [Groff] Mission statement

[Deri James]

On Fri 14 Mar 2014 23:26:46 Eric S. Raymond wrote:
> > Manpages
> >
> > 
> >
> > - improve the semantic usefulness of manpage markup; groff currently
> >
> >   formats manpages for TTYs and PostScript from largely
> >   presentational markup, however increased use of browsers
> >   necessitates parsing source files for semantic markup in order to
> >   simplify their conversion to presentationally-indifferent xml
> 
> I think we can be a little more specific here:
> 
> - Increased use of browsers shifts the commonest use cases for man 
pages
>   in a direction that rewards structural rather than presentational
> markup.   The future direction for the man macros is to (a) decouple 
them
> as much as possible from low-level troff requests and (b) semantically
> enrich the markup, while (c) maintaining backwards compatibility of the
> macro set.
> 
> I think that lays out a good direction (parallel to where mdoc(7) has
> gone, but simpler) without committing us to anything grandiose that we
> can't deliver on.

The problem with this is (a) because it seems that Eric's way to this goal is 
to make low level troff calls fail when used in man pages (see discussion 
on the .hygiene requestion). So, in the quest for semantics, presentation 
could suffer.

What is more important for the reader of a man page? I would think that it 
is that the information is presented in an easy to understand way, and, if 
the man page author resorts to using some low level troff commands, it 
may be to improve the presentation and readability of the information. Do 
we have to lose this?

The stated goal for this is to enable doclifter to be able to work better, so 
that manual pages are on the web, can be browsed and navigated by 
clicking on links. Does it require doclifter to achieve this? What if we come 
from the other direction and ask "How can we make groff produce output 
with these desirables". I know Eric's opinion on the PDF standard, but it is 
the best form of output, with web type navigation, to faithfully maintain the 
output as the author intended.

As an example, compare these two pages in a browser:-

http://manpages.ubuntu.com/manpages/trusty/man7/groff_mdoc.7.html
http://chuzzlewit.co.uk:8080/cgi-bin/WebManPDF.pl/man:/groff_mdoc

The first is from an Ubuntu site which has used doclifter to produce some 
nice html versions of man pages (not sure if it using the latest version of 
doclifter so this may not be fair). The second is just using groff to produce 
pdf pages. You will see small errors in both, but I'd be interested to hear if 
either is easier to read/understand. I know most will say "I prefer my 
terminal output" but this is just an experiment where the requirement is to 
produce documents for the web.

You will probably notice a speed difference because the doclifter version is 
using stored copies of the doclifted material, whereas groff is doing its job 
"on the fly".


Cheers 

Deri

Re: [Groff] Mission statement

[Deri James]

On Mon 17 Mar 2014 19:11:50 Werner LEMBERG wrote:
> > http://chuzzlewit.co.uk:8080/cgi-bin/WebManPDF.pl/man:/groff_mdoc
> 
> This is amazing!  Wonderful!  I like it a lot.  Indeed, viewing man
> pages this way makes fun.
> 
> What software is this?  I've never seen before such a system.  Can you
> give more details?
> 
> 
> Werner

Hi Werner,

Thanks. All I wrote was a little preprocessor for groff which uses Keith 
Marshalls pdfmark calls in the appropriate places then pump it through 
gropdf. The pre-process is less than 500 lines of code, it'll probably take 
me longer than ten years to get it completely Ok!

The web front end is currently a tiny cgi program which calls "man -t" which 
I've configured to call the preprocessor and groff -T pdf. When I've battle 
hardened it a bit I'll make it available.

I also plan to expand the web part. I plan to parse the whatis file to 
produce a html index, to give the web crawlers something to bite into.

Cheers 

Deri

Re: [Groff] Mission statement

[Deri James]

On Tue 18 Mar 2014 12:58:09 Ingo Schwarze wrote:
>  Security-wise, PDF is
> one of the most dangerous file formats, nowadays.

That is true if the pdf reader you are using is configured to action all the 
extra bits which Adobe added to the standard (i.e. forms, flash and 
javascript). Without these "extras" it has the same risks as any other 
application consuming input from the web with regard to buffer overflows 
etc.

I certainly would not use Adobe's Reader, slow and dangerous.
 
Without these extras it is simply instructions to place marks on a canvas, 
much like svg, except that allows javascript. If you use gv to view postscript 
from the web you are actually running a postscript program in ghostscript 
so the attack surface is likely to be larger.

Cheers 

Deri

Re: [Groff] Mission statement, second draft

[Deri James]

On Wed 19 Mar 2014 15:22:42 Eric S. Raymond wrote:
> > SO: Supposing that this proposed enterprise goes ahead, WILL WE
> > STILL BE ABLE TO USE GROFF AS WE ALWAYS HAVE DONE?
> 
> Yes.

Except if you are a man page author who wants to use all the troff syntax, 
in which case you will find that "some things" will no longer work, or a 
consumer of man pages who values presentation rather than the ability to 
look at man pages on small phone screens (one of the cited advantages 
of using html).

NB We have not yet been told which things will stop working. The reason 
for deliberately breaking certain troff commands (only when used in man 
pages), seems quite similar to what W3C tried to do with XHTML1.1 and 
2.0, if there is an "error" in the input, refuse to display it, with the 
intention 
that all markup would become perfect.

This seems to be the difference between Ingo and Eric's approach. Ingo is 
correct in saying we should be trying to win hearts and minds of man page 
authors to use macros which include semantic information, but Eric says 
we must stop any man pages which include presentation markup which 
Doclifter specifically can't handle, from being displayable by groff. The 
choice then is either those naughty man pages get re-written, or they die 
since neither groff, Doclifter nor mdoc can display them. Either way, 
Doclifter can then claim to be 100% compatible with all man pages which it 
is possible to display.

If I have misunderstood Eric's intentions with regard to the purpose of 
introducing the .hygiene command, then it would be very helpful if he could 
elucidate further.

Deri

Re: [Groff] Mission statement, second draft

[Deri James]

On Wed 19 Mar 2014 20:29:12 Eric S. Raymond wrote:
> > If I have misunderstood Eric's intentions with regard to the purpose of 
> > introducing the .hygiene command, then it would be very helpful if he
> > could  elucidate further.
> 
> The reason to write .hygiene isn't doclifter, it's to allow other people
> to write specialized man page renderers that could be two orders of 
> magnitude *simpler and faster* than doclifter.  That can't happen now
> because every viewer has to be nearly a full troff emulator.

So, this change won't just affect the very small number of pages which 
doclifter can't cope with, but a much larger percentage in order to be of 
use to other renderers which will not have the AI that is built into Doclifter. 
Any feel for how many man pages would be affected by the .hygiene 
command? If you supplied a list of which groff commands you would expect 
to turn off for man pages, we could do the research ourselves, to save 
putting work on you.

Deri

Re: [Groff] Using non-ASCII characters in mom

[Deri James]

On Fri 25 Apr 2014 11:35:42 Peter Schaffter wrote:
> On Thu, Apr 24, 2014, Per Edin wrote:
> > I'm having some trouble getting non-ASCII characters to work in my
> > mom-based documents. With pdfmom -k I get them to work without problem
> > in running text, but, when I use them inside quotes in .HEADING and
> > .TITLE I receive errors similar to:
> > 
> > noname.mom:60: can't translate character code 229 to special character
> > `oa' in transparent throughput
> > noname.mom:60: can't translate character code 229 to special character
> > `oa' in transparent throughput
> > noname.mom:60: can't translate character code 246 to special character
> > `:o' in transparent throughput
> > 
> > I'm lost, ideas to fix this are welcome. :)
> 
> The error messages are a by-product of PDF processing (TITLE and
> HEADING assign PDF bookmarks) and can safely be ignored--unless your
> output is incorrect.  If that's the case, post again with whatever
> additional details will help figure out what's going on.

I believe the problem is that groff has already converted the non-ascii to a 
"node" and 
it is this which causes the problem. If you can provide an example I can 
investigate 
further.

Cheers 

Deri

Re: [Groff] lacking characters in groff_char.man

[Deri James]

On Tue 27 May 2014 19:55:34 Bernd Warken wrote:
> The following characters can't be shown with groff_char.man:
> 
> \[.j] \e[.j]  dotlessju0237   j without a dot
> \[vA] \e[vA]  uni21D5 u21D5   vertical double arrow in 
both directions
> \[-+] \e[-+]  uni2213 u2213   minus-plus
> \[coproduct]  \e[coproduct]   uni2210 u2210   
coproduct
> \[u2661]  \e[u2661]   uni2661 u2661   white heart suit
> \[u2662]  \e[u2662]   uni2662 u2662   white diamond suit
> 
> The other characters seem to work.
> 
> Bernd Warken

You will get a different list with -Tdvi.

Re: [Groff] `fi' makes trouble in pdf

[Deri James]

On Sat 31 May 2014 19:29:32 Bernd Warken wrote:
> You are right.  The error come from my OS.  The viewers okular and evince in
> Kubuntu 14.04 (actual) and 14.10 (instable) produce the lacking ligature
> `fi', but 13.04 (old long-term LTS) is fine.  That is independent from
> `groff'.
> 
> Bernd Warken

I've tested on okular 0.17.4 and 0.19.0, both seem Ok.

If you'd like to send me the pdf which won't display on your ubuntu, I might be 
able to 
see what is wrong. You could also try:-

echo file | groff -Tpdf -P-y -PU | okular -

To use an alternative font, which will actually be embedded in the pdf, rather 
than the 
pdf viewer substituting what it thinks is the closest font (which may not 
contain the 'fi' 
glyph).

Cheers 

Deri

Re: [Groff] `fi' makes trouble in pdf

[Deri James]

On Sun 01 Jun 2014 18:40:58 Bernd Warken wrote:
> `ttf-mscore-install' did not work for me.
> 
> Von: "Deri James" 
> 
> > I've tested on okular 0.17.4 and 0.19.0, both seem Ok.>
> > If you'd like to send me the pdf which won't display on your ubuntu, I
> > might be able to see what is wrong.
> ligature-error_$ echo filefile | groff -Tpdf > file.pdf   # see appendix
> 
> > You could also try:-
> 
>  
> 
> > echo file | groff -Tpdf -P-y -PU | okular -
> 
>  
> That works very fine for me.  Thanx.
> 
> > To use an alternative font, which will actually be embedded in the pdf,
> > rather than the pdf viewer substituting what it thinks is the closest
> > font (which may not contain the 'fi' glyph).
> I will use something like that for `groffer'.
> 
> 
> Bernd Warken

As Tadziu says this pdf works fine if the pdf viewer uses a font which contains 
the 
glyph, but it seems that your ubuntu is choosing a font which does not contain 
the 
glyph. You could try:-

fc-match Times-Roman

To find out what font okular/evince are aliasing to Times-Roman, and compare 
this with 
the older ubuntu.

Deri

Re: [Groff] `fi' makes trouble in pdf

[Deri James]

On Mon 02 Jun 2014 11:55:32 Ralph Corderoy wrote:
> Hi Tadziu,
> 
> > However, it does not embed the font (it contains an encoding vector
> > and only a reference to "Times-Roman") so it is up to the viewer to
> > provide the requested font.
> 
> How do you recommend `disassembling' a PDF to inspect its contents?  I'm
> happy grokking PostScript but want to see the PDF's structure so
> pdf2ps's output, for example, isn't suitable.
> 
> Cheers, Ralph.

Hi Ralph,

The most useful tool for working with pdfs is pdftk. One of its uses is to 
decompress 
the pdf, so you can at least "read" it in an editor. However, this does not 
help with the 
actual structure of the pdf, so I wrote a utility (PL-show.pl and it's module 
ParsePDF.pm)  to display the structure as a mindmap. Run PL-show.pl with the 
filename of the pdf file and save stdout to a file, then use a program called 
"freemind" 
to view this file. In the mindmap click on nodes to view dependent nodes.

Bernd-mm.pdf is an example of what the mindmap looks like (with all nodes 
open), 
and you can see the first kid of the pages entry has a "Contents" entry which 
points to 
object 4. Looking at object 4 in the uncompressed pdf shows:-

stream
q 1 0 0 1 0 0 cm
1 J
1 j
0 G
0 g
q BT
1 0 0 1 72 780 Tm
/F5 10 Tf
0 Tc
0 Tw (<8c>le<8c>le) Tj
1 0 0 1 97.56 0 Tm
0 Tc
ET Q
Q

endstream 

>From this you can see a character <8C> is used, which corresponds to the glyph 
>"fi" in 
the "/Differences" table in the encoding object (6 0 R). You need to use an 
editor to 
look at the uncompressed pdf as well as the mindmap since it does not display 
the 
contents of streams and truncates big arrays, it is just meant as a sort of map 
of the 
structure.

I wrote it while writing the gropdf driver to see how others had created pdfs!

Cheers 

Deri



Bernd.mm.pdf
Description: Adobe PDF document


PL-show.tar.gz
Description: application/compressed-tar

Re: [Groff] `fi' makes trouble in pdf

[Deri James]

On Mon 02 Jun 2014 14:22:48 Tadziu Hoffmann wrote:
> > How do you recommend `disassembling' a PDF to inspect
> > its contents?  I'm happy grokking PostScript but want to
> > see the PDF's structure so pdf2ps's output, for example,
> > isn't suitable.
> 
> There is a wonderful program called "qpdf" that converts a
> PDF file into an equivalent PDF file optionally performing a
> number of conversions, such as uncompressing the contents
> (then it's called a "QDF file", but it's still legal PDF).
> It has a companion program "fix-qdf" that updates the internal
> pointers in case the byte-offsets of the objects shift around
> when you edit the file.

Hi Tadziu, 

Just looked at qpdf. It seems more useful than pdftk, thanks for the heads up.

Deri
 

Re: [Groff] Are your gropdf and pdfmom man pages installed?

[Deri James]

On Tue 01 Jul 2014 17:41:24 Dale Snell wrote:
> On Tue, 1 Jul 2014 19:20:57 -0500
> 
> Dave Kemper  wrote:
> > I finally updated my system-wide groff installation from 1.21 to
> > 1.22.2.  I notice that two man pages new in 1.22.2, those for gropdf
> > and pdfmom, were not installed in the upgrade.
> > 
> > I don't know if this omission is due to a problem in groff itself, or
> > in Gentoo Linux's groff package.  If you have a non-Gentoo Linux box
> > on which you've installed groff 1.22.2 with your distro's package
> > manager, can you tell me whether "man gropdf" works?
> 
> I'm running Fedora 19, and I have man pages for both gropdf and
> pdfmom.  The man command displays them both just fine.  My groff
> version is 1.22.2.
> 
> Sounds to me like a packaging error in Gentoo Linux.
> 
> --Dale
> 
> --
> "A proper saute pan should cause serious head injury if brought
> down hard against someone's skull.  If you have any doubts about
> which will dent -- the victim's head or your pan -- then throw
> that pan right in the trash."
>-- Anthony Bourdain, _Kitchen Confidential_

I know some distributions split groff into multiple packages, sometimes they 
separate 
out parts of groff which require perl into a separate package. Gropdf and 
pdfmom 
may be in another package.

Deri

Re: [Groff] {Groff] underlining

[Deri James]

On Tue 08 Jul 2014 09:10:05 Doug McIlroy wrote:
> As has been pointed out, underlining by macro is at best inconvenient
> in filled text. Thus it was proposed that underline, and perhaps
> strike-through might be a groff primitive like .bd. All these capabilities
> may be understood as ways to decorate individual characters.
>  There are other
> such things one might want to do, such as strike-through with /.
> 
> Maybe we need a more general facility, in terms of which a whole
> array of effects can be defined. One possibility is a primitive,
> say .decorate m, which applies macro m to every text character
> until .decorate with no argument. Several decorations could be
> applied to every character.
> 
> The proposal raises some questions. (1) Does white space get decorated?
> (2) How about punctuation? (3) Do multiple decorates terminate together,
> or do they nest? One can come up with answers to these quesions, but
> the first issue is whether this is an idea worth pursuing.
> 
> Doug

One wrinkle with this approach is when traps are invoked, if a particular 
decoration is in 
effect when a trap is sprung, it is unlikely the decoration is wanted for any 
text output 
during that trap. This may be solved by making .decorate private to an 
environment 
but there is no requirement that traps have to use a separate environment.

Deri

Re: [Groff] More referenceability for -mdoc would be an improvement!?

[Deri James]

On Mon 15 Sep 2014 16:24:32 Ingo Schwarze wrote:
> I fear that may be the wrong tool for the job.  This is all about
> local jumping within one single page,



I have posted this link before, so apologies if you have already seen it - 
this is an example of an mdoc type man page with forward referencing (as a 
pdf).

Unfortunately, I have not had time to complete the work on this yet.

Cheers 

Deri

Re: [Groff] PDFPIC macro

[Deri James]

On Thu 18 Sep 2014 09:42:23 Peter Schaffter wrote:
> On Thu, Sep 18, 2014, Keith Marshall wrote:
> > > On 17/09/14 22:22, Peter Schaffter wrote:
> > > Yes.  The way groff stands now, I'm uneasy relying on external tools
> > > and .sy for anything but local, user-written macros.  There's precedent,
> > > though, in www.tmac (PIMG), and this seems to be the best solution
> > > for PDF images.
> > 
> > Do note, however, that this will compromise portability; e.g. pdfinfo is
> > unlikely to be supported on MS-Windows hosts.  Also, since .sy is an
> > intrinsically unsafe request, any macro which relies on it *must* be
> > invoked in unsafe mode, and users should rightly be wary of enabling
> > that, for untrusted sources.
> 
> Are there any tools that can be used in place of pdfinfo that are
> Windows safe?  Sorry, I haven't done Windows since...well...ever. :)
> 
> Would an addition to the warning emitted by the macro be sufficient
> to alert users to the potential dangers of -U?

I do have a perl program which extracts the relevent MediaBox ArtBox TrimBox 
BleedBox CropBox, it uses the same code as the gropdf driver uses to actually 
action the:-

\X’pdf: pdfpic file alignment width height line-length’

So it has a similar chance of working as the driver! I will send you a copy, 
see what you think.

Re: [Groff] PDFPIC macro

[Deri James]

On Thu 18 Sep 2014 19:13:44 Keith Marshall wrote:
> Hmm.  Perl.  I've always shied away from it, particularly on MS-Windows.
>  I know there are implementations available, but my experience of
> attempting to deploy them has always been extremely unpleasant and
> discouraging.
> 
> I'd much rather have seen an implementation of gropdf in C/C++; I'd even
> be willing to attempt a translation, but I'd need guidance because my
> knowledge of perl, as a language, is absolutely non-existent.
> 
> -- 
> Regards,
> Keith.

I think that perl projects which rely on complex module interrelationships, do 
struggle on windows platforms, particularly where there are underlying C 
libraries with perl bindings, but if you are just using perl as a scripting 
language with no external dependencies, I can't see a difference to other 
scripted languages such as the Bourne shell.

Certainly I have seen gropdf being used in a windows environment and I have no 
reason to believe the subset of the code used to retrieve the MediaBox of a 
pdf document would not work equally well.

I'd be very happy to give assistance in understanding the perl code, if you 
want to give it a go in C++. 

Deri

Re: [Groff] PDFPIC macro

[Deri James]

On Sun 21 Sep 2014 06:38:42 Werner LEMBERG wrote:
> >> A good starting point may be to implement a C/C++ library function,
> >> to extract the MediaBox properties; that would open the gate to a
> >> possible pdfbb request, which gtroff.exe could process internally.
> > 
> > 
> > Alternatively, we could modify the existing implementation of .psbb,
> > such that it will discriminate on `%!PS-Adobe-´ or `%PDF-´ as
> > initial file content, then DTRT wrt parsing a `%%BoundingBox:´ or
> > `/MediaBox´ record accordingly.
> 
> 
> Good idea!
> 
> 
> Werner

Yes, it is. Someone on the list has contacted me, with a view to writing the 
code, and I have provided the perl version.

It is a bit more complex than psbb, which is essentially a grep for 
%BoundingBox in the first part of the postscript file. This is because 
MediaBox can appear in multiple object types in a hierarchical fashion. Unlike 
postscript, each page in a pdf document can be a different size. So to be sure 
of the correct MediaBox to use it is necessary to parse the complete document, 
find the page you are interested in (page 1 in the case of PDFPIC) and then 
search for the MediaBox in the page object or any of its ancestors.

Cheers 

Deri

Re: [Groff] PDFPIC macro

[Deri James]

On Sun 21 Sep 2014 15:29:18 Keith Marshall wrote:
> >> Good idea!
> >
> > 
> >
> > Yes, it is. Someone on the list has contacted me, with a view to writing
> > the  code,
> 
> Who might that be?  If it was off-list, then we have a problem -- we all
> need to be kept in the picture, with this sort of stuff.  I ask because...

I'm glad that Ulrich has answered you, it was not my place to identify the 
person as they contacted me privately, but I felt the list should be aware 
something was in the wind.

> > and I have provided the perl version.
> 
> I have not seen this, nor any pointer to it, yet I have already begun to
> explore possibilities at the C/C++ level.  I don't want to waste my time
> duplicating someone else's effort, but I would need some help to find my
> way through perl code.
> 

I thought I'd mentioned that my perl pdfbb program used the same code as in 
gropdf, and I assumed you already had that. I'd be happy to send you the same 
email I sent to Ulrich but the email address;-

Keith Marshall 

Bounces my emails and I don't think it would be of much interest to many if I 
sent it to the list.

Cheers 

Deri

> --
> Regards,
> Keith.

Re: [Groff] PDFPIC macro

[Deri James]

On Sun 21 Sep 2014 20:50:37 Keith Marshall wrote:
> On 21/09/14 20:04, Deri James wrote:
> > I'm glad that Ulrich has answered you, it was not my place to
> > identify the person as they contacted me privately,
> 
> Sure, but we must strenuously discourage such private communications;
> how on earth can we expect to effectively co-ordinate development, if
> potential developers are left in the dark, regarding what each other is
> doing?
> 
> > but I felt the list should be aware something was in the wind.
> 
> Right.  Not just "should"; it is imperative.
> 
Keith,

I hope you agree that what I did was correct. If someone asks to look at my 
code, it does not mean they are definitely going to write something, so its 
not my part to announce their definite involvement, since the final decision 
is theirs. However, I wanted to inform the list in case someone else was 
working on the same thing. Have I breached etiquette by dealing with the 
circumstances in this way?

> > I thought I'd mentioned that my perl pdfbb program used the same code
> > as in gropdf, and I assumed you already had that.
> 
> I will have, if it's in the groff repository, but since I don't know
> perl, I'll need some help to locate the pertinent code.
> 
Gropdf, in git, contains the same code as pdfbb, except I pulled out the pdf 
loading/saving code into a separate module, since I have since used this in 
other projects. 

> > I'd be happy to send you the same email I sent to Ulrich but the
> > email address;-
> > 
> > Keith Marshall 
> > 
> > Bounces my emails
> 
> Strange.  It is working, but may be faulting intermittently; I'll log an
> issue with SourceForge.  Meanwhile, you might try the alternative, from
> which I've posted this.

I am about to send the email I sent to Ulrich to your email address, and it 
includes the smtp rejection received from Sourceforge.

Cheers 

Deri

Re: [Groff] release ready

[Deri James]

On Sun 12 Oct 2014 13:43:28 Axel Kielhorn wrote:
> While the grops man page says:
> 
>   fields may be separated by tabs or spaces;
> 
> This is slightly inconsistent.
> (Of course you can argue that these are different programs 
> and expecting them to use the same syntax is naïve. I wouldn't disagree.)
> 
> > Deri can certainly give more details why spaces are not allowed,
> > contrary to grops.
> 
> Axel

The reason is because the gropdf download file can include directory/filenames 
which 
may include spaces (this is especially true for windows installation). So it 
does not 
make a good choice as a field separator.

Cheers 

Deri

Re: [Groff] Introduction to groff in french

[Deri James]

On Thu 11 Dec 2014 00:43:18 Bertrand Garrigues wrote:
> I was about to commit my example, however I ran into a problem.  When I
> generate the pdf with pdfmom -k, I have a few "can't translate character
> code 233 to special character `'e' in transparent throughput" errors but
> the output is fine.

Generally these warnings can be ignored, I believe they occur when groff is 
trying to 
"asciify" the HEADING text, but what results is the char code 233 anyway, which 
is the 
desired character in the PDFencoding used for the pdfmark entries used for the 
document outline. This should not affect the normal page text and is only to do 
with 
the text used in the document outline. 

> However, the .mom files in contrib/mom/examples are generated with
> LC_ALL=C; this causes more "can't translate character code[...]"
> errors and this time the output is incorrect (é and è letters are not
> correctly displayed).
> 
> I've noticed that the example letter.mom -- that also contains
> accentec letters -- is correctly generated.  The difference is that my
> doc has accented letters in HEADINGS or other macros.

I believe some of the example files are pure ascii rather than UTF-8 so build 
without 
the -k flag. Your example is UTF-8 so does need the -k flag.

Cheers 

Deri
 
> Attached my original .mom file.
> 
> Thanks for your help,
> 
> Regards,
> mon_premier_doc.mom
> 
> --
> Bertrand Garrigues

Re: [Groff] ASCII dash in UTF-8 locale

[Deri James]

On Fri 23 Jan 2015 08:39:20 Anthony J. Bentley 
wrote:
> Heirloom troff and groff both render \- as en dash, 
not minus sign,
> in PDF output.

If you use groff's native pdf driver (-Tpdf) I believe 
minus is rendered, can be searched for and 
copy/pasted. The postscript driver also outputs a 
"minus" so I suspect it is the ghostscript conversion 
to pdf which is changing it.

Re: [Groff] Blast from the past

[Deri James]

On Tue 10 Feb 2015 20:53:42 Jones, Larry wrote:
> "ROFF is a program which generates microfilm and 7-track binary 
magnetic
> tape for off line processing on an IBM Magnetic Tape / Selectric
> Typewriter..."

I loved my selectric. IBM donated it to me when I was at school since 
no one, including me, could easily read my handwriting! Up until my 
first electric  typewriter, an Olivetti, all my school work was written on 
A3 1 inch lined paper. but was very slow if it was to be legible! The 
selectric was much better, I could correct mistakes with the 
integrated correction tape. Nowadays I use the dasher program for 
all writing, except coding.

Re: [Groff] gropdf ellipsis (u+2026) breaks with several fonts

[Deri James]

On Wed 11 Mar 2015 09:36:15 Ellam ByDefault wrote:
> I'm writing a document parser which outputs to groff to be processed with
> gropdf.
> When the parse document contains unicode ellipsis (u+2026), it goes fine
> with few groff fonts, namely Times, Helvetica, Courier.
> But with Palatino and the rest, the document breaks when processed with
> gropdf, emits this message:
> 
> Use of uninitialized value $fld in concatenation (.) or string at
> usr/local/bin/gropdf line 1923, <> line 6838.
> 
> While with grops everything is OK.
> 
> What happens?
> 
> Cheers from Indonesia,
> Ellam ByDefault

It is a bug. The attached patch should update gropdf 1.22.2 to the latest. 
Please can 
you test.

Cheers 

Deri

diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 9a8288c..8103914 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -467,7 +465,7 @@ sub GetObj
 sub PDFDate
 {
 my $dt=shift;
-return(sprintf("D:%04d%02d%02d%02d%02d%02d% +02d'00'",$dt->[5]+1900,$dt->[4]+1,$dt->[3],$dt->[2],$dt->[1],$dt->[0],( localtime time() + 3600*( 12 - (gmtime)[2] ) )[2] - 12));
+return(sprintf("D:%04d%02d%02d%02d%02d%02d%+03d'00'",$dt->[5]+1900,$dt->[4]+1,$dt->[3],$dt->[2],$dt->[1],$dt->[0],( localtime time() + 3600*( 12 - (gmtime)[2] ) )[2] - 12));
 }
 
 sub ToPoints
@@ -711,6 +709,7 @@ sub do_x
 	{
 		my $pdfmark=$1;
 		$pdfmark=~s((\d{4,6}) u)(sprintf("%.1f",$1/$desc{sizescale}))eg;
+		$pdfmark=~s(\\\[u00(..)\])(chr(hex($1)))eg;
 
 		if ($pdfmark=~m/(.+) \/DOCINFO/)
 		{
@@ -768,7 +767,10 @@ sub do_x
 		}
 		elsif ($pdfmark=~m/(.+) \/OUT/)
 		{
-		my @xwds=split(' ',"<< $1 >>");
+		my $t=$1;
+		$t=~s/\\\) /\) /g;
+		$t=~s/\\e//g;
+		my @xwds=split(' ',"<< $t >>");
 		my $out=ParsePDFValue(\@xwds);
 
 		my $this=[$out,[]];
@@ -1125,6 +1127,7 @@ sub PutHotSpot
 $l=~s/Color/C/;
 $l=~s/Action/A/;
 $l=~s'/Subtype /URI'/S /URI';
+$l=~s(\\\[u00(..)\])(chr(hex($1)))eg;
 my @xwds=split(' ',"<< $l >>");
 my $annotno=BuildObj(++$objct,ParsePDFValue(\@xwds));
 my $annot=$obj[$objct];
@@ -1622,7 +1625,7 @@ sub nextwd
 
 return('') if !defined($wd);
 
-if ($wd=~m/^(.*?)(<<|>>|\[|\])(.*)/)
+if ($wd=~m/^(.*?)(<<|>>|(?:(? '/Font',
 			'Subtype' => '/Type1',
 			'BaseFont' => '/'.$fnt{internalname},
+			'Widths' => $fnt{WID},
+			'FirstChar' => 0,
+			'LastChar' => $lastchr,
 			'Encoding' => BuildObj($objct+1,
 {'Type' => '/Encoding',
 'Differences' => $fnt{GNO}
 }
-)
+),
+			'FontDescriptor' => BuildObj($objct+2,
+	{'Type' => '/FontDescriptor',
+	'FontName' => '/'.$fnt{internalname},
+	'Flags' => $t1flags,
+	'FontBBox' => \@fntbbox,
+	'ItalicAngle' => $slant,
+	'Ascent' => $ascent,
+	'Descent' => $fntbbox[1],
+	'CapHeight' => $capheight,
+	'StemV' => 0,
+	'CharSet' => "($charset)",
+	}
+	)
 			}
 			);
-	$objct+=1;
+
+	$objct+=2;
 	$fontlst{$fontno}->{NM}='/F'.$fontno;
 	$pages->{'Resources'}->{'Font'}->{'F'.$fontno}=$fontlst{$fontno}->{OBJ};
 	$fontlst{$fontno}->{FNT}=\%fnt;
@@ -2326,6 +2346,7 @@ sub do_p
 $cpage=$obj[$cpageno]->{DATA};
 $pages->{'Count'}++;
 $stream="q 1 0 0 1 0 0 cm\n$linejoin J\n$linecap j\n";
+$stream.=$strkcol."\n", $curstrk=$strkcol if $strkcol ne '';
 $mode='g';
 $curfill='';
 #@mediabox=@defaultmb;
@@ -3028,6 +3049,7 @@ sub TextWid
 my $txt=shift;
 my $w=0;
 my $ck=0;
+$txt=~s/^\\(\d\d\d)/chr($1)/e;
 
 foreach my $c (split('',$txt))
 {
@@ -3068,7 +3090,7 @@ sub do_t
 $xpos+=($pendmv-$nomove)/$unitwidth;
 
 $stream.="% == '$par'=$wid 'xpos=$xpos\n" if $debug;
-$par=~s/\\//g;
+$par=~s/\\(?!\d\d\d)//g;
 $par=~s/\)/\\)/g;
 $par=~s/\(/\\(/g;
 
@@ -3198,7 +3220,7 @@ sub FindChar
 	my $ch=$fnt->{GNM}->{$chnm};
 	$ch=RemapChr($ch,$fnt,$chnm) if ($ch > 255);
 
-	return(chr($ch),$fnt->{WID}->[$ch]*$cftsz);
+	return(($ch<32)?sprintf("\\%03o",$ch):chr($ch),$fnt->{WID}->[$ch]*$cftsz);
 }
 else
 {
@@ -3222,7 +3244,7 @@ sub RemapChr
 {
 	$fnt->{GNM}->{$chnm}=$unused++;
 	$fnt->{GNO}->[$unused]=$fnt->{GNO}->[$ch+1];
-	$fnt->{WID}->[$unused]=$fnt->{WID}->[$ch+1];
+	$fnt->{WID}->[$unused]=$fnt->{WID}->[$ch];
 	$ch=$unused-1;
 	return($ch);
 }
@@ -3274,3 +3296,11 @@ sub do_n
 @lin=();
 PutHotSpot($xpos) if defined($mark);
 }
+
+
+1;
+
+### Emacs settings
+# Local Variables:
+# mode: CPerl
+# End:

Re: [Groff] Problem with tables changing setting.

[Deri James]

On Mon 20 Apr 2015 22:31:03 Radek wrote:
> Hi Ralph,
> 
> Relevant part of Makefile is
> 
> PREPROC = -pt
> %.pdf: %.tr
> groff -U $(PREPROC) -Tpdf -m spdf $< >$@
> 
> So the command is: groff -U -pt -Tpdf -mspdf table.tr >table.pdf

The code snippet you provided does not seem to require the ms macro. If you 
drop the -mspdf it behaves better. If you need the ms macro then Tadziu has 
given the answer.

Cheers 

Deri

Re: [Groff] Business Graphics

[Deri James]

On Sat 23 May 2015 10:53:49 Clarke Echols wrote:
> Sounds interesting.  Will there be an ability to fill the pie-chart
> segments with color so the PostScript output from groff can be converted
> to .jpg files for inclusion in HTML web pages?
> 
> That would be useful.
> 
> Clarke

Yes, it works with -T ps as well as -T pdf. 

Cheers 

Deri

Re: [Groff] Business Graphics

[Deri James]

On Sun 24 May 2015 12:53:07 Ralph Corderoy wrote:
> Hi Deri,
> 
> > Its purpose is to provide inline "business type" graphs for groff. I
> > know we have grap which seems to be aimed at the more mathematical end
> > of graphs, I'm aiming for the sort of graphs which a typical office
> > spreadsheet might produce.
> 
> Interesting.  I dislike 3D-ness being added as it seems fluff and
> clutter to me, but I realise it's sought after by some (hind) quarters.
>   Keeping it on topic, Bell Labs were amongst those to criticise pie
> charts generally compared to other representations.
> https://en.wikipedia.org/wiki/Pie_chart#Use.2C_effectiveness_and_visual_perc
> eption

Hi Ralph,

You don't need to tell me about dodgy statistics, very early in my career I 
used to work for the UK Civil Service in a Statistics Research branch of what 
was then the Department of Health and Social Security. The games those 
statisticians tried to pull!

The problem with perception with pie charts, particularly 3D, is the reason I 
have the default set to sort the segments into size order, and provide the 
keybox which can hold the actual data rather than just the name of the 
segment.

There is a place for 3D piecharts, but not if you are trying to give 
scientific accuracy, it is more for business presentations where you are just 
touting for work! And they can look quite nice.

> > If you have time please have a look and if you have any good ideas for
> > improvements or additions, post them back to the list.
> 
> I think most preprocessors pass on their bracketing pseudo macros to
> their output so the author has the option of defining them?

Yes, that's a good idea, I think I will output, .BGS X Y width depth, so that 
authors can, if they want overprint text on the graph. For example on a bar 
chart, one bar may be exceptionally long, caused by some oddity in the data, 
this would leave a lot of white space above the other bars, a perfect place to 
put a bit of text explaining the oddity.

> I spotted a few minor things on a quick look, e.g. not stealing my
> .BGSIWASHEREFIRST.  Patch below.

Patch gratefully received. I still have quite a lot to do, not even the 
parameters are cast in stone yet. I did send to Werner, just to check that it 
would be an acceptable project to include in groff, and he suggested I share 
what I had so far with the list, to get ideas.

> Cheers, Ralph.

Cheers 

Deri

PS On the subject of different graph representation. The attached jpeg is a 
portion of my weather station software, the one I have not seen before is the 
wind history graph (bottom left), it works by using gradations of colour to 
show time - 24 hours ago -> Red -> Blue -> Green -> now, the depth of colour 
shows how often it happens and the fatness of the ellipse how long a single 
gust lasted.

Re: [Groff] can't translate character code 229 to special character `oa' in transparent throughput

[Deri James]

On Wed 10 Jun 2015 16:19:24 mikkel meinike wrote:
> I just compiled groff from source and I used pdfmom in a way I have done
> many times before but this time there was a strange problem that I have not
> tried before. The error massages was printed into the document.
> 
> This command is causing the problem
> $ pdfmom udspil.mom >udspil.pdf
> Is this a bug? Is there any way around this problem.
> 
> With this command
> 
> $ pdfroff -mom -mpdfmark udspil.mom >udspil.pdf
> 
> I am able to compile the doc without the error massages. But now there are
> some mistakes in the page structure. (at least that can be fixed with pdftk)
> 
> Thanks in advance
> Mikkel

Hi Mikkel,

There is an error in pdfmom. Please change line 66 to:-

system("groff -Tpdf -dPDF.EXPORT=1 -mom -z $cmdstring 2>&1 | grep '^\\.ds' 
| groff -Tpdf -mom - $cmdstring");

The grep is now '^\\.ds' it was '^.ds' so it matched the name of your document 
(udspil)!!

Cheers

Deri

Re: [Groff] can't translate character code 229 to special character `oa' in transparent throughput

[Deri James]

On Wed 10 Jun 2015 17:51:23 mikkel meinike wrote:
> Deri you talk about an error in the source code of pdfmom?
> 
> Anyway I made this work. I found and old document almost simular that did
> not make that mistake. Than I copy/pasted and edite the contet of the old
> doc to look like the new doc and now it worked
> 
> But maybe I will try to change the code an compile again as you sergest
> Deri

Even without the code change, if you rename udspil.mom to anything which does 
not start with "?ds" where "?" is any character, so mikkel.mom would work with 
current pdfmom.

I will patch pdfmom soon.

Cheers 

Deri

Re: [Groff] How remove title?

[Deri James]

On Fri 12 Jun 2015 23:23:14 Peng Yu wrote:
> Hi, I use the following command to generate a pdf file from a manpage.
> But the pdf file has title "Untitled". I want to unset it via groff.
> But I don't see an option to set title to be null. Would you please
> let me know how to unset the title with groff?
> 
> groff -Tps -mandoc -c < $(man -w ls) | ps2pdf - > /tmp/ls.pdf

I have a program which might be useful. You can test it with:-

wget http://chuzzlewit.co.uk/WebManPDF.pl/man:/groff -O groff.pdf

or

wget http://chuzzlewit.co.uk/WebManPDF.pl/man:/ls -O ls.pdf

It does not unset the title but does set it to the name of the command. The 
program has many quirks which I have not fixed yet, but you are welcome to a 
copy if you want.

Re: [Groff] How remove title?

[Deri James]

On Sat 13 Jun 2015 15:20:24 Peng Yu wrote:
> > Do these actually check the manpages on my system? I guess it does
> > not. I want to convert manpages on my system.
> 
> Maybe you can make a corresponding version that works locally?

Well, that is in fact what happens, on my system it is local. The URL I gave 
was for you to check if it was doing what you wanted. I have attached a script 
(make it executable), which is very much alpha quality, which you can use as 
follows:-

pdfman < $(man -w ls) | groff -Tpdf -mandoc -c > /tmp/ls.pdf

Assuming your man pages are not compressed, otherwise you'll need to use a 
decompressor as well:


Cheers 

Deri


pdfman
Description: Perl program

Re: [Groff] How remove title?

[Deri James]

On Tue 16 Jun 2015 11:49:23 Steffen Nurpmeso wrote:
> Anyway i finally have to say that it is a pity that, instead of
> (making the engine as such multi-pass and) instrumenting the
> macros for different output formats that need meta-information,
> and extending the macros sets to include more meta-information
> that may be usable in output devices, so many other languages and
> text formats have been invented where no person at all only spends
> a single thought on using the necessary commands to provide this
> meta-information as part of the format.
> 
> --steffen

Have you looked at the pdfmark and www macros?

Re: [Groff] How remove title?

[Deri James]

On Tue 16 Jun 2015 11:47:27 Peng Yu wrote:
> I am on Mac. I have installed groff using homebrew.
> 
> $ ls -lgo $(type -P groff)
> lrwxr-xr-x 1 32 Jun 16 11:08 /usr/local/bin/groff ->
> ../Cellar/groff/1.22.3/bin/groff
> 
> Now, I see the following error. What do they mean and how to fix them?
> Thanks.
> 
> $ ./pdfman < $(man -w ls) | groff -Tpdf -mandoc -c > /tmp/ls.pdf
> :6: can't transparently output node at top level
> :9: can't transparently output node at top level

Does the pdf /tmp/ls.pdf look alright in the viewer.

The warnings you are seeing are to do with the pdf overview pane where you can 
click on different sections to jump to that section, it should not affect the 
rest of the pdf. You can suppress all warnings with 

./pdfman < $(man -w ls) | groff -Tpdf -mandoc 2>/dev/null > /tmp/ls.pdf

Re: [Groff] How remove title?

[Deri James]

On Tue 16 Jun 2015 15:15:27 Peng Yu wrote:
> Yes. It can generate the pdf. But the title is "LS("1")". How to
> remove the title?

It may be that if the title is removed some pdf viewers may show the title as 
"Untitled". All the viewers I have tried use the filename if a specific title 
is not given, or even if the title given is simply a space.

I've fixed the issue with the title coming out as LS("1") by removing the 
quotes, so it is LS(1) now, but I don't think that's what you want.

Cheers 

Deri

Re: [Groff] Mission statement PDF

[Deri James]

On Wed 08 Jul 2015 17:56:10 Peter Schaffter wrote:
> I've fixed the offending line in the Mission Statement pdf and
> tested it with a batch of viewers.  Seems to be working fine.
> Uploaded the .pdf to the groff webpage.

How fixed?

A) Editing line identified by Tadziu by hand, or
B) Regenerating from original source with current tools?

Cheers

Deri

Re: [Groff] Mission statement PDF

[Deri James]

On Thu 09 Jul 2015 07:04:53 Doug McIlroy wrote:
> Peter wrote:
> I've fixed the offending line in the Mission Statement pdf
> 
> Out of curiosity, what was the offense? Did some groff construct
> lead to it?
> 
> Doug

Tadziu said:-

> The first element of the Widths array on line 315 of the PDF is
> a "T".  If you change that to a "0", everything seems to work
> again.  I have no idea what could create such an error, however.

Which I believe is what Peter fixed with an editor, and uploaded the result. 
This pdf was originally created by gropdf, so I am hoping Peter has time to 
create the pdf again using current groff tools (particularly current gropdf) 
to see if the error is repeated.

Deri

Re: [Groff] Tbl - repeating column titles

[Deri James]

On Thu 24 Sep 2015 18:47:19 Ralph Corderoy wrote:
> It may pre-date your time on this list, but some of us here re-entered
> the book as troff source from the scan after I got Tim O'Reilly's
> permission.  http://home.windstream.net/kollar/utp/
> 
> Cheers, Ralph.

You can retrieve the pdf with "clickable links", here:-



It is the same content but updated be more easily viewed as a pdf.

Cheers 

Deri

Re: [Groff] Groff command-line argument strangeness

[Deri James]

On Mon 26 Oct 2015 05:31:28 Keith Marshall wrote:
> > However, when I do this, groff gives the following warnings:
> > 
> >
> > Unknown option: I
> > Unknown option: r
> > Unknown option: c
> >
> > 
> >
> > Have I done something wrong, and if so, what?
> 
> Reproduced here ... looks like another bug in -Tpdf.  It doesn't seem to
> be reproduced with (a simplified form of):

Keith is correct. Gropdf fails to handle the "-I switch", the reason is 
because it is not expecting groff to pass the switch on to gropdf. It needs to 
pass the switch to grops because it affects the searching for eps files, which 
gropdf does not accept.

I will add code to ignore the switch in future, or use it to search for pdfs 
which are to be imbedded. Thanks for the heads up.

Cheers 

Deri

Re: [Groff] Using Make with pdfmom

[Deri James]

On Fri 06 Nov 2015 09:36:17 Koz Ross wrote:
> I have the following directory layout:
> 
> Makefile
> LICENSE
> README.md
> src:
> en:
>main.mom
>ch01.mom
>ch02.mom
>...
> ru:
>main.mom
>ch01.mom
>ch02.mom
>...
> 
> In each case, main.mom INCLUDEs ch01.mom etc. When I write a Makefile rule,
> I first tried using the -I directive to add the folder containing all the
> chapter files to the search path, but when I tried that, I got this:
> 
> Unknown option: I
> Unknown option: .
> Unknown option: /
> Unknown option: r
> Unknown option: c
> Unknown option: /
> Unknown option: r
> 
> I've come up against this before with vanilla groff. Thus, I had to
> formulate the command to cd into the right directory first, then build
> there. Is this the only way I can do this, or am I missing some option I
> could use instead?

In the current git log you should see:-

==

commit 0fd1ab8c1c07c7c9bfadd30042a617e7f855d13e
Author: Deri James 
Date:   Tue Oct 27 15:43:41 2015 +

gropdf was choking on -I flag passed by groff.

Now uses these directories to search for included pdfs.

* src/devices/gropdf/gropdf.pl: Handle -I flag, avoid
  unitialised values.

* src/roff/groff/groff.1.man: Include 'X pdf: pdfpic'

* src/devices/gropdf/gropdf.1.man: Document -I flag

==

So this issue has been fixed in the git repository. I attach a small patch 
which is what was applied to the git version.

Cheers 

Deri
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 89767fc..0744378 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -180,10 +180,13 @@ my $debug=0;
 my $version=0;
 my $stats=0;
 my $unicodemap;
+my @idirs;
 
 #Load_Config();
 
-GetOptions("F=s" => \$fd, 'l' => \$frot, 'p=s' => \$fpsz, 'd!' => \$debug, 'v' => \$version, 'e' => \$embedall, 'y=s' => \$Foundry, 's' => \$stats, 'u:s' => \$unicodemap);
+GetOptions("F=s" => \$fd, 'I=s' => \@idirs, 'l' => \$frot, 'p=s' => \$fpsz, 'd!' => \$debug, 'v' => \$version, 'e' => \$embedall, 'y=s' => \$Foundry, 's' => \$stats, 'u:s' => \$unicodemap);
+
+unshift(@idirs,'.');
 
 if ($version)
 {
@@ -925,7 +928,7 @@ sub do_x
 	elsif (lc($xprm[1]) eq 'pdfpic')
 	{
 		my $fil=$xprm[2];
-		my $flag=uc($xprm[3])||'-L';
+		my $flag=uc($xprm[3]||'-L');
 		my $wid=GetPoints($xprm[4])||-1;
 		my $hgt=GetPoints($xprm[5]||-1);
 		my $ll=GetPoints($xprm[6]||0);
@@ -1175,7 +1178,7 @@ sub GetPoints
 {
 my $val=shift;
 
-$val=ToPoints($1,$2) if ($val=~m/(-?[\d.]+)([cipnz])/);
+$val=ToPoints($1,$2) if ($val and $val=~m/(-?[\d.]+)([cipnz])/);
 
 return $val;
 }
@@ -1302,6 +1305,35 @@ sub LoadSWF
 return $xonm;
 }
 
+sub OpenInc
+{
+my $fn=shift;
+my $fnm=$fn;
+my $F;
+
+if (substr($fnm,0,1)  eq '/' or substr($fnm,1,1) eq ':') # dos
+{
+	if (-r $fnm and open($F,"<$fnm"))
+	{
+	return($F,$fnm);
+	}
+}
+else
+{
+	foreach my $dir (@idirs)
+	{
+	$fnm="$dir/$fn";
+	
+	if (-r "$fnm" and open($F,"<$fnm"))
+	{
+		return($F,$fnm);
+	}
+	}
+}
+
+return(undef,$fn);
+}
+
 sub LoadPDF
 {
 my $pdfnm=shift;
@@ -1316,17 +1348,19 @@ sub LoadPDF
 my $instream=0;
 my $cont;
 
-if (!open(PD,"<$pdfnm"))
+my ($PD,$PDnm)=OpenInc($pdfnm);
+
+if (!defined($PD))
 {
 	Msg(0,"Failed to open PDF '$pdfnm'");
 	return undef;
 }
 
-my $hdr=;
+my $hdr=<$PD>;
 
 $/="\r" if (length($hdr) > 10);
 
-while ()
+while (<$PD>)
 {
 	chomp;
 
@@ -1363,8 +1397,8 @@ sub LoadPDF
 	{
 	if ($curobj > -1)
 	{
-		$pdf->[$curobj]->{STREAMPOS}=[tell(PD),$strmlen];
-		seek(PD,$strmlen,1);
+		$pdf->[$curobj]->{STREAMPOS}=[tell($PD),$strmlen];
+		seek($PD,$strmlen,1);
 		$instream=1;
 	}
 	else
@@ -1377,9 +1411,9 @@ sub LoadPDF
 	$pdftxt.=$_.' ';
 }
 
-close(PD);
+close($PD);
 
-open(PD,"<$pdfnm");
+open(PD,"<$PDnm");
 #	$pdftxt=~s/\]/ \]/g;
 my (@pdfwds)=split(' ',$pdftxt);
 my $wd;

Re: [Groff] Times-Roman v. Nimbus Roman No9 L Regular.

[Deri James]

On Tue 03 May 2016 10:53:45 Ralph Corderoy wrote:
> Hi Werner,
> 
> > > Should I be telling groff that I want to use those Nimbus fonts so
> > > it uses their metrics rather than the "almost identical" Times'
> > > ones?
> > 
> > If you use the gropdf output device, try groff's `-P -y -P U' option
> > to use the URW fonts.
> 
> Using -Tpdf gives a PDF that refers to Times-Roman and doesn't embed my
> local Nimbus substitute.  Adding `-P -y -P U' didn't change the PDF
> produced, apart from expected CreationDate, trailer's ID, etc.
> 
> /usr/share/groff/1.22.3/font/devpdf/download has only the "blank"
> foundry, with no mention of Times.  Arch Linux groff 1.22.3-6.
> 
> Cheers, Ralph.

# foundry   ps name psfile
AvantGarde-Book /usr/share/ghostscript/9.14/Resource/Font/URWGothicL-
Book
AvantGarde-BookOblique  
/usr/share/ghostscript/9.14/Resource/Font/URWGothicL-BookObli
AvantGarde-Demi /usr/share/ghostscript/9.14/Resource/Font/URWGothicL-
Demi
AvantGarde-DemiOblique  
/usr/share/ghostscript/9.14/Resource/Font/URWGothicL-DemiObli
Bookman-Demi/usr/share/ghostscript/9.14/Resource/Font/URWBookmanL-
DemiBold
Bookman-DemiItalic  
/usr/share/ghostscript/9.14/Resource/Font/URWBookmanL-DemiBoldItal
Bookman-Light   
/usr/share/ghostscript/9.14/Resource/Font/URWBookmanL-Ligh
Bookman-LightItalic 
/usr/share/ghostscript/9.14/Resource/Font/URWBookmanL-LighItal
Courier */usr/share/ghostscript/9.14/Resource/Font/NimbusMonL-Regu
Courier-Bold
*/usr/share/ghostscript/9.14/Resource/Font/NimbusMonL-Bold
Courier-BoldOblique 
*/usr/share/ghostscript/9.14/Resource/Font/NimbusMonL-BoldObli
Courier-Oblique */usr/share/ghostscript/9.14/Resource/Font/NimbusMonL-
ReguObli
FreeEuro../devps/freeeuro.pfa
Helvetica   
*/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-Regu
Helvetica-Bold  */usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-
Bold
Helvetica-BoldOblique   
*/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-BoldItal
Helvetica-Narrow
/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-
ReguCond
Helvetica-Narrow-Bold   
/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-BoldCond
Helvetica-Narrow-BoldOblique
/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-BoldCondItal
Helvetica-Narrow-Oblique
/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-ReguCondItal
Helvetica-Oblique   
*/usr/share/ghostscript/9.14/Resource/Font/NimbusSanL-
ReguItal
NewCenturySchlbk-Bold   
/usr/share/ghostscript/9.14/Resource/Font/CenturySchL-Bold
NewCenturySchlbk-BoldItalic 
/usr/share/ghostscript/9.14/Resource/Font/CenturySchL-BoldItal
NewCenturySchlbk-Italic 
/usr/share/ghostscript/9.14/Resource/Font/CenturySchL-Ital
NewCenturySchlbk-Roman  
/usr/share/ghostscript/9.14/Resource/Font/CenturySchL-Roma
Palatino-Bold   
/usr/share/ghostscript/9.14/Resource/Font/URWPalladioL-Bold
Palatino-BoldItalic 
/usr/share/ghostscript/9.14/Resource/Font/URWPalladioL-BoldItal
Palatino-Italic /usr/share/ghostscript/9.14/Resource/Font/URWPalladioL-
Ital
Palatino-Roman  /usr/share/ghostscript/9.14/Resource/Font/URWPalladioL-
Roma
Symbol  */usr/share/ghostscript/9.14/Resource/Font/StandardSymL
Times-Bold  
*/usr/share/ghostscript/9.14/Resource/Font/NimbusRomNo9L-Medi
Times-BoldItalic
*/usr/share/ghostscript/9.14/Resource/Font/NimbusRomNo9L-MediItal
Times-Italic
*/usr/share/ghostscript/9.14/Resource/Font/NimbusRomNo9L-
ReguItal
Times-Roman 
*/usr/share/ghostscript/9.14/Resource/Font/NimbusRomNo9L-Regu
ZapfChancery-MediumItalic   
/usr/share/ghostscript/9.14/Resource/Font/URWChanceryL-MediItal
ZapfDingbats*/usr/share/ghostscript/9.14/Resource/Font/Dingbats
U   CenturySchL-Bold/usr/share/fonts/default/Type1/c059016l.pfb
U   CenturySchL-BoldItal/usr/share/fonts/default/Type1/c059036l.pfb
U   CenturySchL-Ital/usr/share/fonts/default/Type1/c059033l.pfb
U   CenturySchL-Roma/usr/share/fonts/default/Type1/c059013l.pfb
U   Dingbats/usr/share/fonts/default/Type1/d05l.pfb
U   NimbusMonL-Bold /usr/share/fonts/default/Type1/n022004l.pfb
U   NimbusMonL-BoldObli /usr/share/fonts/default/Type1/n022024l.pfb
U   NimbusMonL-Regu /usr/share/fonts/default/Type1/n022003l.pfb
U   NimbusMonL-ReguObli /usr/share/fonts/default/Type1/n022023l.pfb
U   NimbusRomNo9L-Medi  /usr/share/fonts/default/Type1/n021004l.pfb
U   NimbusRomNo9L-MediItal  /usr/share/fonts/default/Type1/n021024l.pfb
U   NimbusRomNo9L-Regu  /usr/share/fonts/default/Type1/n021003l.pfb
U   NimbusRomNo9L-ReguItal  /usr/share/fonts/default/Type1/n021023l.pfb
U   NimbusSanL-Bold /usr/share/fonts/default/Type1/n019004l.pfb
U   Nimbu

Re: [Groff] .if !dTS - GNU extension?

[Deri James]

On Sun 01 May 2016 17:39:59 James K. Lowden wrote:
> As far as I can tell, you're defining "best" in terms of the goal of
> delivering a base OS without a troff dependency for manual display.  I
> really don't understand why you consider that desirable.  I would like
> to see groff used more, not less.  

I've been using pdf versions of the man pages for a while now. They don't 
suffer some of the problems mentioned in this thread. For example, in the ksh 
manual you can find the description of "read" with two mouse clicks. First 
open the section "Built-in commands" (near the bottom of the overview pane), 
then scroll down to the "read" command and click on it.

You can see what I mean at:-

http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

Be aware this is very slow over the network, the server is only a few 
centimetres square with a little arm chip running in it. Its much faster on my 
main server. You can get a very crude index of all the man pages on this 
little server with:-

http://chuzzlewit.co.uk/

Cheers 

Deri

Re: [Groff] Times-Roman v. Nimbus Roman No9 L Regular.

[Deri James]

On Thu 05 May 2016 15:13:34 Ralph Corderoy wrote:
> Hi Deri,
> 
> > One way to add the URW fonts post groff install is to run the
> > BuildFoundries program after you have cd'd into the devpdf font
> > directory. Within this directory you should find a file called
> > "Foundry". Make sure line 68 includes the path to the URW fonts,
> > then:-
> > 
> > BuildFoundries .
> 
> Thanks for all the detail.  Should this be a part of groff's `install'
> make-file target so it snapshots the system's fonts at that point?
> 
> Does anyone here happen to know if other distributions, e.g. Debian,
> have some `installed fonts have changed, update various caches' command?
> 
> Cheers, Ralph.

Hi Ralph,

It is part of the groff install, when you compile from source. The problem is 
that most installations are from compiled binaries, so this step either needs 
to be done by the packager, who would then need to make the URW fonts a 
dependency, which is unlikely to happen because most packagers already split 
groff into more than one package, splitting out the minimum to handle man 
pages and have minimal dependencies, not even requiring perl.

Perhaps, what I should do is make BuildFoundries a proper documented 
executable rather than an installation "helper" as it is now. So users can run 
it post install of groff. Perennial problem is documentation, I'm very slow 
and not very good at doing it!

Cheers 

Deri

Re: [Groff] pdfmom question

[Deri James]

On Tue 01 Nov 2016 15:56:49 Peter Schaffter wrote:
> This is a question for Deri James.
> 
> Is there some reason why, in pdfmom, the system() call to groff at
> line 125 does not include '$preconv' in the first pass?
> 
> I've been working on flexible vertical whitespace in the mom macros,
> using pdfmom's PDF.EXPORT to assign first-pass strings with the
> correct amount of flex-space for each page.
> 
> I was using pdfmom to process my test file, which needed both the -t
> and -k flags.  At first, I couldn't get my flex spacing system to
> perform reliably.  After a couple of days of debugging and coming up
> with nothing, it occured to me to process the file long-hand at the
> command line instead of using pdfmom, like this
> 
>   groff -Tpdf -dPDF.EXPORT=1 \
>   -mom -z -t -k test-file.mom 2>&1 \
> 
>   | grep '^\. *ds' | \
> 
>   groff -Tpdf -mom -t -k - test-file.mom  \
> 
>   > test-file.pdf
> 
> That's when I discovered that pdfmom wasn't picking up the -t and -k
> flags on the first groff pass.  Inserting $preconv into the first
> pass in pdfmom solved the reliability issue.  I can't figure out why
> it isn't there already.

I've now added it.

Re: [Groff] Colors with gropdf

[Deri James]

On Fri 25 Nov 2016 16:47:26 Robert Marks wrote:
> I have recently had to embed a PDF image in a groff document and so have
> been using
> groff -Tpdf
> to do so.
> But I find that my \m[red] etc color commands are not recognised (and there
> are error messages..
> Some work on Google led me to the Ubuntu gropdf manual, which states:
> 
>  The  default  color  for  \m and \M is black; for colors defined in the
>‘rgb’  color  space  setrgbcolor  is  used,  for   ‘cmy’   and
> ‘cmyk’
>setcmykcolor,  and  for  ‘gray’  setgray.   Note that setcmykcolor
> is a
>PostScript LanguageLevel 2 command and thus not available on some
> older
>printers.
> 
> Searching for setrgbcolor tells me that it's a PS commend to be used:
> .ds RED \X'ps: exec 1 0 0 setrgbcolor'
> and then referring to \*[RED] to change the color from black, say.
> 
> But there is no change (and no error messages). Using groff 1.22.2
> 
> Any advice on using color in gropdf or groff -Tpdf ?
> 
> Thanks,
> 
> Bob

The information you found in the gropdf is wrong, it got left in erroneously 
from the grops manual, upon which it was based. I have removed it now. The 
correct way to use colour in groff is described in the info page as:-

 -- Request: .defcolor ident scheme color_components
 Define color with name IDENT.  SCHEME can be one of the following
 values: 'rgb' (three components), 'cmy' (three components), 'cmyk'
 (four components), and 'gray' or 'grey' (one component).

 Color components can be given either as a hexadecimal string or as
 positive decimal integers in the range 0-65535.  A hexadecimal
 string contains all color components concatenated.  It must start
 with either '#' or '##'; the former specifies hex values in the
 range 0-255 (which are internally multiplied by 257), the latter in
 the range 0-65535.  Examples: '#FFC0CB' (pink), '##'
 (magenta).  The default color name value is device-specific
 (usually black).  It is possible that the default color for '\m'
 and '\M' is not identical.

 A new scaling indicator 'f' has been introduced, which multiplies
 its value by 65536; this makes it convenient to specify color
 components as fractions in the range 0 to 1 (1f equals 65536u).
 Example:

  .defcolor darkgreen rgb 0.1f 0.5f 0.2f

 Note that 'f' is the default scaling indicator for the 'defcolor'
 request, thus the above statement is equivalent to

  .defcolor darkgreen rgb 0.1 0.5 0.2

Also note that many colours have been pre-defined if you are using grops or 
gropdf all the colours shown in the attached file have already been defined, so 
you can just use the name in your \m[] and \M[]..defcolor black rgb #00
.defcolor grey rgb #bebebe
.defcolor dimgrey rgb #696969
.defcolor lightgray rgb #d3d3d3
.defcolor lightslategrey rgb #778899
.defcolor slategray rgb #708090
.defcolor slategray1 rgb #c6e2ff
.defcolor slategray2 rgb #b9d3ee
.defcolor slategray3 rgb #9fb6cd
.defcolor slategray4 rgb #6c7b8b
.defcolor slategrey rgb #708090
.defcolor grey0 rgb #00
.defcolor grey1 rgb #030303
.defcolor grey2 rgb #050505
.defcolor grey3 rgb #080808
.defcolor grey4 rgb #0a0a0a
.defcolor grey5 rgb #0d0d0d
.defcolor grey6 rgb #0f0f0f
.defcolor grey7 rgb #121212
.defcolor grey8 rgb #141414
.defcolor grey9 rgb #171717
.defcolor grey10 rgb #1a1a1a
.defcolor grey11 rgb #1c1c1c
.defcolor grey12 rgb #1f1f1f
.defcolor grey13 rgb #212121
.defcolor grey14 rgb #242424
.defcolor grey15 rgb #262626
.defcolor grey16 rgb #292929
.defcolor grey17 rgb #2b2b2b
.defcolor grey18 rgb #2e2e2e
.defcolor grey19 rgb #303030
.defcolor grey20 rgb #33
.defcolor grey21 rgb #363636
.defcolor grey22 rgb #383838
.defcolor grey23 rgb #3b3b3b
.defcolor grey24 rgb #3d3d3d
.defcolor grey25 rgb #404040
.defcolor grey26 rgb #424242
.defcolor grey27 rgb #454545
.defcolor grey28 rgb #474747
.defcolor grey29 rgb #4a4a4a
.defcolor grey30 rgb #4d4d4d
.defcolor grey31 rgb #4f4f4f
.defcolor grey32 rgb #525252
.defcolor grey33 rgb #545454
.defcolor grey34 rgb #575757
.defcolor grey35 rgb #595959
.defcolor grey36 rgb #5c5c5c
.defcolor grey37 rgb #5e5e5e
.defcolor grey38 rgb #616161
.defcolor grey39 rgb #636363
.defcolor grey40 rgb #66
.defcolor grey41 rgb #696969
.defcolor grey42 rgb #6b6b6b
.defcolor grey43 rgb #6e6e6e
.defcolor grey44 rgb #707070
.defcolor grey45 rgb #737373
.defcolor grey46 rgb #757575
.defcolor grey47 rgb #787878
.defcolor grey48 rgb #7a7a7a
.defcolor grey49 rgb #7d7d7d
.defcolor grey50 rgb #7f7f7f
.defcolor grey51 rgb #828282
.defcolor grey52 rgb #858585
.defcolor grey53 rgb #878787
.defcolor grey54 rgb #8a8a8a
.defcolor grey55 rgb #8c8c8c
.defcolor grey56 rgb #8f8f8f
.defcolor grey57 rgb #919191
.defcolor grey58 rgb #949494
.defcolor grey59 rgb #969696
.defcolor grey60 rgb #99
.defcolor grey61 rgb #9c9c9c
.defcolor grey62 rgb #9e9e9e
.defcolor grey63 rgb #a1a1a1
.defcolor grey64 rgb #a3a3a3
.defcolor grey65 rgb #a6a6a6

Re: [Groff] Nesting font macros in man pages

[Deri James]

On Thu 27 Apr 2017 20:12:09 Ingo Schwarze wrote:
> Does that still apply to
> 
>   view-source:http://man.openbsd.org/ksh

compared with a PDF version:-

http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

Re: [Groff] Nesting font macros in man pages

[Deri James]

On Thu 27 Apr 2017 23:48:29 Steffen Nurpmeso wrote:
> Terrible, see the spacing errors surrounding the command list
> before the "Substitution" heading!  Not your fault of course, but
> gr...
> 
> --steffen

Well, turns out it WAS my fault! Bug in gropdf, will commit after more 
testing. Thanks for the heads up, is this Ok?

http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

Re: [Groff] Problems with arcs and angles

[Deri James]

On Tue 09 May 2017 13:55:38 John Gardner wrote:
> Looks like there's a mistake in groff_out(5). It describes its arc-drawing
> command as:
> 
> *Draw arc from current position to (h1, v1)+(h2, v2) with center at (h1,
> 
> > v1);*
> 
> However, gropdf.pl tells a different story. To quote line #2791:
>  l?id=453a8aa7c8f8dd0c78160466301f81be8c40df2e#n2791>
> 
> *Documentation is wrong. Groff does not use Dh1,Dv1 as centre of the
> circle!*
> 
> I noticed something odd when drawing an arc which wasn't an evenly-sized
> quarter-circle. For instance, the following Pic code:
> 
> .PS
> 
> > move down
> > A: box
> > arc at A.n
> > line right
> > .PE
> 
> ... generates the following output:
> > …
> 
> V84000
> 
> H99000
> 
> > Da 0 -36000 18000 54000
> 
> Which looks like this in gropdf and my own canvas code, respectively:
> 

In gropdf I adjust the circle centre using code I found in the geometry.cpp 
library used by the grops driver, so that I could duplicate the output 
produced by grops.

Re: [Groff] mom : unicode in .INCLUDE'd files

[Deri James]

On Sun 23 Jul 2017 10:16:39 Dale Snell wrote:
> Hi Erich,
> 
> I suspect that the typeface you're using simply doesn't have the
> "char-with-breve" and "char-with-macron" characters.  That
> happened to me a while back.  I needed vowels with macrons to
> print out some Romaji (romanized Japanese) words.  I kept getting
> errors like yours.  I did a bit of digging, and found that the
> standard Palatino Roman (P) font didn't have those characters.
> However, the U-P font did.  So I switched to that font and haven't
> had any trouble since.  The U- fonts should be part of
> the standard 1.22.3 version of Groff.
> 
> Just a thought.
> 
> --Dale
> 

Hi Dale,

It ought to work if you include:-

-P-yU

On the pdfmom command line. This should tell gropdf to use the U- foundry, so 
you don't have to alter the 
actual mom document.

Cheers 

Deri

Re: [Groff] Elegant -ms and -mpdfmark documents

[Deri James]

On Tue 05 Sep 2017 23:49:26 Kristaps Dzonsons wrote:
> For example, the colouring of links

You could insert these lines at the top of the .ms file:-

\# These lines set link text and border colours to rgb 0.0 0.3 0.9
.ds PDFHREF.COLOUR 0.0 0.3 0.9
.defcolor pdf:href.colour rgb \*[PDFHREF.COLOUR]
.ds PDFHREF.TEXT.COLOUR pdf:href.colour
\

You don't need to specify -mpdfmark explicitly if you are using -T pdf when you 
call groff. Since your document only contains external references you do not 
need to consider forward references in the document, if you did, the groff 
command line for the pdf device gets a bit more complex, I use something like:-

groff -Tpdf -dPDF.EXPORT=1 -ms -z file.ms 2>&1 | grep \"^\\.ds\" | groff -Tpdf 
-ms -

If using 'ms'.

Alternatively you could use the command "pdfroff" which uses the postscript 
device and ghostscript to produce the pdf:-

pdfroff -mspdf --no-toc-relocation index.ms > index.pdf

Re: [Groff] parallel text processing ; vertical and horizontal mode

[Deri James]

On Thu 07 Sep 2017 18:07:27 Peter Schaffter wrote:
> You'll notice that the top of the pdf file has a
> line of text spit out by grep(1) that obviously shouldn't be there.
> I guess I've never had to deal with diacritics in titles, because
> I've never seen this before and the line only appears when the title
> is "L'étranger."  I'm stumped as to how stderr from grep(1) is
> finding its way into the file.  The problem seems to be related to
> preconv(1) and pdfbookmark (from pdfmark.tmac) because
> the same file, processed without the -k flag, does not contain the
> grep(1) line.  Any ideas what's going on?

No files attached, but I suspect this may be the grep in pdfmom, will have a 
look when we see the files.

Cheers 

Deri

Re: [Groff] pdfmom grep (was parallel text processing)

[Deri James]

On Sat 09 Sep 2017 09:51:27 Peter Schaffter wrote:
> On Sat, Sep 09, 2017, Ralph Corderoy wrote:
> > Hi Peter,
> >
> > 
> >
> > > The grep in pdfmom is returning a binary file hit when it encounters
> > > the diacritic in 
> > >
> > >   .ds pdf:look(pdf:bm1) L'étranger
> >
> > 
> >
> > What does locale(1) output for you where you run this pdfmom command?
> 
>   LANG=en_CA.UTF-8
>   LANGUAGE=en_CA:en
>   LC_CTYPE="en_CA.UTF-8"
>   LC_NUMERIC="en_CA.UTF-8"
>   LC_TIME="en_CA.UTF-8"
>   LC_COLLATE="en_CA.UTF-8"
>   LC_MONETARY="en_CA.UTF-8"
>   LC_MESSAGES="en_CA.UTF-8"
>   LC_PAPER="en_CA.UTF-8"
>   LC_NAME="en_CA.UTF-8"
>   LC_ADDRESS="en_CA.UTF-8"
>   LC_TELEPHONE="en_CA.UTF-8"
>   LC_MEASUREMENT="en_CA.UTF-8"
>   LC_IDENTIFICATION="en_CA.UTF-8"
>   LC_ALL=en_CA.UTF-8
>  
> 
> > > The solution is to pass the -a flag to grep.
> >
> > 
> >
> > How about 
> >
> > 
> > groff ... 2>&1 | LC_ALL=C grep '^\.ds' | groff ...
> 
> Yes, that's the solution I thought of before suggesting the tidier
> but, as Steffen pointed out, not universal -a flag.
>  
> 
> > BTW, pdfmom has a bug shown by that strace command I suggested.
> >
> > 
> > system("groff ... 2>&1 | grep '^\.ds' | groff ...");
> > 
> >
> > That's a double-quoted Perl string so `\.' is escaping the dot and grep
> > sees a plain dot for `any character'.  The backslash needs doubling.
> 
> Missed that.  Argh.  Why don't they make special glasses that let
> you see code as if for the first time whenever you put them on?
> 
> -- 
> Peter Schaffter

I can't actually recreate the problem, i.e. grep does not spit out the 
"binary" error. I've tried with a en_GB.UTF-8 and a en_GB environment, neither 
show the message. The version of grep I'm using is:-

grep (GNU grep) 2.20

The double escaping of the "." in the grep pattern used to be there:-

grep \"^\\.ds\"

but got changed.

Cheers 

Deri

Re: [Groff] devpdf U-fonts and Russian

[Deri James]

On Fri 06 Oct 2017 10:57:43 Tadziu Hoffmann wrote:
> Well, I get *different* errors, that at first sight appear
> somewhat bizarre but don't give the impression of something
> critical
> 
>   bash$ groff -Kutf8 -pet -Tpdf RuTest.rof >RuTest.pdf
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> RuTest.rof: Too many glyphs used in font '39'
> 
> but the output is garbled (see picture).
> I'm using the distribution-provided groff on openSUSE Leap 42.2
> here.

I confirm this is a bug with gropdf. The type 1 fonts which are used by groff 
allow up to 255 characters but 
may exceed that in the number of glyphs defined. Often some of the 255 
characters are not defined to a 
particular glyph, i.e. are specified as ".notdef" rather than a particular 
glyph, so when a document uses a 
glyph beyond the 255 boundary gropdf searches for one of these undefined 
characters and defines it to 
represent the desired glyph.

The success of this course of action is dependent on the number of undefined 
characters present in the 
font and the number of glyphs required which are above the 255 boundary. This 
is the case here, more 
glyphs are used from above 255 than the number of undefined characters.

I will work on fixing this so that if gropdf runs out of undefined characters 
which can be used it will start 
using defined but unused characters. This is a little trickier, since a 
character which points to an unused 
glyph may in fact get used later in the document.

I will try to work on this over the weekend.

Cheers 

Deri 

Re: [Groff] devpdf U-fonts and Russian

[Deri James]

On Fri 06 Oct 2017 13:43:13 Tadziu Hoffmann wrote:
> In Postscript you can use the same font with multiple different
> encodings; I assume something similar is also possible in PDF.
> The way this is done is by making a copy of the font dictionary,
> keeping all entries except Encoding, which is replaced by the
> required new encoding, and registering this copy under a new name.
> (This does not really waste memory, since complex data types are
> treated internally as pointers, so both copies of the font
> share all data except for the encoding and the name.)
> 
> Would this also be an option for gropdf?

Yes, I did consider this (having taken a peek at the ps output). The overhead 
of the extra font definitions is 
minimal, the tricky bit is ensuring I am using the correct font all the time. 
Currently I switch fonts whenever 
groff tells me to, but I would now need to add code to switch to select the 
correct subset as well.

The advantage of your method is that it will always work, my method, of 
redefining unused characters, 
would still fail if the total number of glyphs used in one document exceeds 
255. Although this may be 
unlikely, it is still a firm push that I should bite the bullet and go with 
your suggestion.

Cheers 

Deri

Re: [Groff] PDFPIC macro

[Deri James]

On Sun 08 Oct 2017 20:26:02 Keith Marshall wrote:
> You may recall that I did begin to explore possibilities, at the time, 
> but then life ... explicitly a protracted visit to Australia and New 
> Zealand, followed by too many other priorities on return ... got in the 
> way.  I've now found a bit of time to revisit it, and have posted some 
> prototypical code at https://osdn.net/users/keith/pf/groff-psbb/files

Some pdfs I have tried fail with "syntax error". It seems to occur if MediaBox 
is defined in an ancestor 
object rather than in a "/Page object. There are a number of page attributes 
which are inheritable in this 
way, MediaBox is one of them. The standard says:-


==

Inheritance of Page Attributes

Some of the page attributes shown in Table 3.18 are designated as inheritable. 
If such an attribute is 
omitted from a page object, its value is inherited from an ancestor node in the 
page tree. If the attribute is 
a required one, a value must be supplied in an ancestor node; if it is optional 
and no inherited value is 
specified, the default value is used.

An attribute can thus be defined once for a whole set of pages, by specifying 
it in an intermediate page tree 
node and arranging the pages that share the attribute as descendants of that 
node. For example, a 
document might specify the same media box for all of its pages by including a 
MediaBox entry in the root 
node of the page tree. If necessary, an individual page object could then 
override this inherited value with a 
MediaBox entry of its own.


==

So in case a MediaBox is superseded by an entry further down the tree you still 
have to continue looking till 
you get to the object for page 1, to make sure.

Re: [groff] Something broke embedded fonts in gropdf output (but not grops)

[Deri James]

On Thu 15 Feb 2018 17:06:40 Jim Avera wrote:
> Hello,
> 
> Something changed between Ubuntu 16.04 and 17.10 which makes 
> locally-installed fonts not render correctly in PDFs generated with 
> groff -Tpdf.   However groff -Tps produces correctly-rendering 
> postscript (files in devps/ and devpdf/ are identical).   Ubuntu 17.10 
> has */groff 1.22.3/* and */ghostscript 9.21/*.   I'm sorry but I don't 
> know the earlier version nos.
> 
> To rule out a font-installation problem (mostly), I created a script 
> which re-installs a font set into a temporary directory and runs tests 
> without any local environment variables set, except for GROFF_FONT_PATH 
> and GS_FONTPATH, which are set to point only to temporary directories 
> generated by the script.  See below.

Hi Jim,

I believe the problem is because there is no "download" file in the font 
directory. Any font which is not one of the 14 base type 1 files which all pdf 
viewers must know about, must have an entry in download file so that gropdf 
can actually embed the font in the pdf. If the entry is missing in the 
download file, or no download file, then it is not embedded and the viewer has 
to make a "best guess" as to which font to use. Now, since you set 
GS_FONTPATH, any program which uses ghostscript (i.e. gv) is likely to find 
the correct fontfiles to use, but anything which does not use ghostscript, 
using its own display engine (i.e. evince) is likely to choose the wrong font. 
This is why it is necessary for the actual font file to be included in the 
pdf, so that the viewer does not have to find the correct file in the host 
system.

I added these lines to your bash script:-

cat >groff_font_lib/devpdf/download <<'EOF'
# foundry   ps name psfile
CourierHP   /tmp/grtest/fonts/CourierHP.pfb
EOF

at line 7651, and evince now shows the attached png file.  As you can see the 
top line is now correct, and if I look at the font properties in okular it 
shows CourierHP as fully embedded, but for the other HP fonts it has chosen 
its own fonts.

You may like to investigate the "install-font.sh" script on Peter Schaffter's 
mom site:-

http://www.schaffter.ca/mom/mom-06.html#install-font

This may do what you want.

Cheers 

Deri

Re: [groff] Release Candidate 1.22.3.rc1

[Deri James]

On Fri 16 Feb 2018 11:42:13 Peter Schaffter wrote:
> After the list discussion back in the fall about slides and
> gpresent, Deri tinkered with gropdf and I with om.tmac to implement
> slides with mom/gropdf.  I think the mom side of things is done, but
> I'm holding off releasing the new version until gropdf is ready.
> 
> It would be nice to have the mom version with slides in the next
> official groff release, but if it's going to hold things up, I can
> patch the current version with non-slide-related additions and fixes
> (i.e. do a minor version release) for the groff release.
> 
> -- 
> Peter Schaffter

The bit missing from the gropdf changes is better handling of the pdfmarks, 
i.e. they should reference to the complete slide not the first subframe 
containing the target. Currently, it means that clickies in the pdf containing 
slides, are sub-optimal!

I will try to work on this next week, so I will let you know by next Friday.

Cheers 

Deri

Re: [groff] [bernhard.fiss...@mail.de: mom: PDF Author, pdfmom: needs C locale?]

[Deri James]

On Thu 08 Mar 2018 17:06:12 Peter Schaffter wrote:
> This seems to be an "on again, off again" bug.  We discussed adding
> LC_ALL=C to the command string in pdfmom, but I see it's not there.
> Deri--any objections to adding it?  The alternative is to pass the
> -a flag to the various greps, but Steffen Nurpmesco pointed out that
> -a is not standardized.

I've got an example which is meant to show the problem (camus.mom), but 
unfortunately I can't make it generate the error which others are seeing. 
Camus.mom is a utf-8 file and I have used -k in a utf-8 user account 
(LC_CTYPE=en_GB.UTF-8) and with -Kutf8 in an old style account 
(LC_CTYPE=en_GB), neither produced an error from grep.

This leads me to suspect there is something in my version of grep which 
"understands" that UTF-8 files are not binary data. I believe compiling grep 
with NLS support is optional, so may be people who get this error are using a 
grep without language support.

One possible solution would be to replace the greps with a perl regexp, but I 
also have no objection to LC_ALL=C, if this fixes it. Be careful it only 
applies to the greps not anything else.

Cheers

Deri

Re: [groff] [bernhard.fiss...@mail.de: mom: PDF Author, pdfmom: needs C locale?]

[Deri James]

On Fri 09 Mar 2018 16:09:35 Ralph Corderoy wrote:
> That seems unlikely.  grep thinks files are binary if they contain ASCII
> NUL, or have a byte sequence that's invalid for the locale, and it only
> emits that `Binary file ... matches' if such a line matches the regexp.
> 
> Does your grep behave like this?  I used a UTF-8 terminal.
> 
> $ od -tx1z <<<$'x\xa0\xa0y'
> 000 78 a0 a0 79 0a   >x..y.<
> 005
> $ LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y'
> $ LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y\nz'
> z
> $ LC_ALL=en_GB.utf8 grep y <<<$'x\xa0\xa0y'
> Binary file (standard input) matches
> $ LC_ALL=en_GB.iso88591 grep y <<<$'x\xa0\xa0y'
> x��y
> $ LC_ALL=C grep y <<<$'x\xa0\xa0y'
> x��y
> $
> 
> -- 
> Cheers, Ralph.

Your example which produces the "Binary file" message, produces this:-

[derij@pip build (master)]$ LC_ALL=en_GB.utf8 grep y <<<$'x\xa0\xa0y'
x��y

So I am not seeing the message. I looked for any aliases and found:-

alias grep='grep --color'

So I unaliased it and ran again, with same result, except the "y" was not 
coloured.

I don't know why I don't see the message!

Cheers 

Deri

Re: [groff] pdfmom: needs C locale?

[Deri James]

On Sat 10 Mar 2018 12:29:54 Ralph Corderoy wrote:
> I don't know how all those other commands did.  :-)
> What's the output of
> 
> dpkg-query -W grep
> grep --version
> od -tx1z <<<$'x\xa0\xa0y'
> LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y'
> LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y\nz'
> LC_ALL=en_GB.utf8 grep y <<<$'x\xa0\xa0y'
> LC_ALL=en_GB.iso88591 grep y <<<$'x\xa0\xa0y'
> LC_ALL=C grep y <<<$'x\xa0\xa0y'

All the others are the same as yours. Here it is:-

=
[derij@pip ~]$ grep --version
grep (GNU grep) 2.20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see 
.
[derij@pip ~]$ od -tx1z <<<$'x\xa0\xa0y'
000 78 a0 a0 79 0a   >x..y.<
005
[derij@pip ~]$ LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y'
[derij@pip ~]$ LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y\nz'
z
[derij@pip ~]$ LC_ALL=en_GB.utf8 grep y <<<$'x\xa0\xa0y'
x��y
[derij@pip ~]$ LC_ALL=en_GB.iso88591 grep y <<<$'x\xa0\xa0y'
x��y
[derij@pip ~]$ LC_ALL=C grep y <<<$'x\xa0\xa0y'
x��y
[derij@pip ~]$ urpmq -i grep
$MIRRORLIST: media/core/updates/media_info/20180228-135247-info.xml.lzma
Name: grep
Version : 2.20
Release : 4.1.mga5
Group   : Text tools
Size: 706453   Architecture: x86_64
Source RPM  : grep-2.20-4.1.mga5.src.rpm
URL : http://www.gnu.org/software/grep/grep.html
Summary : The GNU versions of grep pattern matching utilities
Description :
The GNU versions of commonly used grep utilities.  Grep searches one or
more input files for lines which contain a match to a specified pattern
and then prints the matching lines.  GNU's grep utilities include grep,
egrep and fgrep.

You should install grep on your system, because it is a very useful utility
for searching through text files, for system administration tasks, etc.
===

I have now run the same commands in VirtualBox on a more recent version of 
Mageia:-

===
[derij@localhost ~]$ grep --version
grep (GNU grep) 3.0
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see 
.
[derij@localhost ~]$ od -tx1z <<<$'x\xa0\xa0y'
000 78 a0 a0 79 0a   >x..y.<
005
[derij@localhost ~]$ LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y'
[derij@localhost ~]$ LC_ALL=en_GB.utf8 grep z <<<$'x\xa0\xa0y\nz'
z
[derij@localhost ~]$ LC_ALL=en_GB.utf8 grep y <<<$'x\xa0\xa0y'
Binary file (standard input) matches
[derij@localhost ~]$ LC_ALL=en_GB.iso88591 grep y <<<$'x\xa0\xa0y'
x��y
[derij@localhost ~]$ LC_ALL=C grep y <<<$'x\xa0\xa0y'
x��y
[derij@localhost ~]$ 
[derij@localhost ~]$ urpmq -i grep
Name: grep
Version : 3.0
Release : 1.mga6
Group   : Text tools
Size: 790453   Architecture: x86_64
Source RPM  : grep-3.0-1.mga6.src.rpm
URL : http://www.gnu.org/software/grep/grep.html
Summary : The GNU versions of the grep pattern matching utilities
Description :
The GNU versions of the commonly used grep utilities.  Grep searches one or
more input files for lines which contain a match to a specified pattern
and then prints the matching lines.  GNU's grep utilities include grep,
egrep and fgrep.

You should install grep on your system, because it is a very useful utility
for searching through text files, for system administration tasks, etc.
===

Now I can see the binary file message, so between versions 2.20 and 3.0 it 
appears the behaviour changed, or a difference in the environment of my user 
under VirtualBox. Peter has committed the LC_ALL=C changes so there should not 
be a problem with either version.

Thanks for your help.

Cheers 

Deri

[groff] Creating a pdf slideshow

[Deri James]

Recently new features have been added to the gropdf device to allow 
presentation pdfs to be produced from roff files. Peter Schaffter has been 
incorporating the new features into mom, but I wondered how difficult it would 
be to incorporate it into other macro packages.

It turns out to be quite easy. I used the ms macros to create the attached 
pdf. It is the first time I have used the ms macros so apologies if I have 
made any newbie blunders. The command to generate the presentation is:-

groff -T pdf -ms ms-slides.rof > ms-slides.pdf

To generate a non-presentation version (which is easier to print), do:-

GROPDF_NOSLIDE=1 groff -T pdf -ms ms-slides.rof > ms-noslides.pdf

The changes in gropdf are in the current git version, so if you want to test 
the new features you will have to install the current git version. I would 
welcome further testing to make sure I've ironed out all the wrinkles.

Cheers 

Deri
.pl 9c
.nr PO 1c
.nr LL 14c
.nr LT 14c
.nr HM 1c
.nr FM .5c
.RP no
.P1
.nr bm 0 1
.nop \!x X papersize=16c,9c
.ds PDFHREF.COLOUR 0.0 0.3 0.9
.defcolor pdf:href.colour rgb \\*[PDFHREF.COLOUR]
.ds PDFHREF.TEXT.COLOUR pdf:href.colour
.OH "'\m[grey]Slides Demo''Deri James\m[]'"
.EH "'\m[grey]Slides Demo''Deri James\m[]'"
.pdftransition PAGE Box .5 . O
.pdftransition BLOCK Wipe 1
.de HD
.sp |\\n[HM]u-6p
\Z!\D't 1p'!\D'l \\n[LL]u 0p'
.fl
..
.de HEAD
.  NH \\$1
.  shift
\\m[pdf:href.colour]\\$*\\m[]
.  fl
.  pdfbookmark -T bm\\n+[bm] \\n[nh*hl] \\*[SN-STYLE] \\$*
.  XS \\n[%]
.  pdfhref L -D bm\\n[bm] -- \\*[SN-STYLE] \\$*
.  XE
.  pdfpause
..
.pdfpagename TITLE
.TL
\m[pdf:href.colour]Demonstrating using
.br
ms macros
.br
for a slideshow\m[]
.AU
Deri James
.LP
.sp -2.4v
.HEAD 1 The Basics
.LP
Using
.I ms
to write a presentation slideshow is easy.
.LP
.pdfpause
.HEAD 2 Configure the "paper" size
.RS
.LD
.ft CR
\&.pl 9c
\&.nr PO 1c
\&.nr LL 14c
\&.nr LT 14c
\&.nr HM 1c
\&.nr FM .5c
\&.RP no
\&.P1
\&.nop \\!x X papersize=16c,9c
.ft
.DE
.RE
The final command sets the pdf page size, suitable for a 16:9 ratio screen.
.HEAD 2 Specify the presentation transitions
.RS
.LD
.ft CR
\&.pdftransition PAGE Box .5 . O
\&.pdftransition BLOCK Wipe 1
.ft
.DE
.RE
A description of the allowed parameters is in the
.pdfhref W -D http://chuzzlewit.co.uk:8080/cgi-bin/WebManPDF.pl/man:/1/gropdf 
-- gropdf(1)
man page.
The parameters applied to
.B PAGE
are used when the transition is to a new slide, and
.B BLOCK
sets the transition for any separate blocks in the slide.
.LP
.B Note:
Not all possible transitions are supported by every PDF reader.
.pdfpause
.HEAD 2 Use Blocks
.LP
A Block is a portion of the slide which you want to appear separately on the 
screen
when you click the mouse or press the space bar. After the text which you want 
to
appear simply insert a pause:-
.RS
.LD
.ft CR
\&.pdfpause
.ft
.DE
.RE
.HEAD 2 Printing the slides
.LP
If the presentation contains blocks it may be difficult to print the slides in 
a format
so they may be given as a handout. The solution is to define GROPDF_NOSLIDE as 
true before
invoking groff:-
.RS
.LD
.ft CR
GROPDF_NOSLIDE=1 groff -Tpdf -ms filename.ms > filename.pdf
.ft
.DE
.RE
The pdf file produced will not be in presentation mode so can be printed 
normally but
you may need to select \[oq]scale to fit\[cq] and \[oq]landscape\[cq] to fit 
the actual
paper size.
.HEAD 1 Other PDF considerations
.LP
This demo has other features which take advantage of calls to the gropdf device 
which
may be useful.
.bp
.HEAD 2 PDF overview and clickable TOC
.LP
I included a custom .HEAD macro which creates a heading, adds it to the 
overview panel
in the pdf reader, adds a clickable link in the TOC and pauses:-
.RS
.LD
.ft CR
.ec Z
Z&.de HEAD
Z&.  NH \\$1
Z&.  shift
\\m[pdf:hrefZ&.colour]\\$*\\m[]
Z&.  fl
Z&.  pdfbookmark -T bm\\n+[bm] \\n[nh*hl] \\*[SN-STYLE] \\$*
Z&.  XS \\n[%]
Z&.  pdfhref L -D bm\\n[bm] -- \\*[SN-STYLE] \\$*
Z&.  XE
Z&.  pdfpause
Z&..
.ec
.ft
.DE
.RE
.bp
It should be called as:
.RS
.LD
.ft CR
\&.HEAD 2 PDF overview and clickable TOC
.ft
.DE
.RE
.HEAD 2 Move TOC to page after TITLE
.LP
First insert the following just before the
.CW .TL
section at the top of the file.
.RS
.LD
.ft CR
\&.pdfpagename TITLE
.ft
.DE
.RE
Then insert these lines at the end of your ms file:-
.RS
.LD
.ft CR
\&.pdfswitchtopage after TITLE
\&.TC
.ft
.DE
.RE
.pdfswitchtopage after TITLE
.TC


ms-slides.pdf
Description: Adobe PDF document

Re: [groff] Creating a pdf slideshow

[Deri James]

On Wed 14 Mar 2018 15:37:00 Ralph Corderoy wrote:
> When viewing with mupdf(1) on this 1920×1080, `f' for full-screen, then
> `H' to fit its height to the screen gives a slight non-paper edge at
> both sides.  `W' to fit width instead gets rid of them, losing a bit top
> and bottom I presume, but working at a page size in points could be the
> other way?
> 
> $ e 448/252
> 1.
> 
> -- 
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy

Hi Ralph,

I have tried with the mupdf on my system (v1.5) and and I press `f` and `p`, 
and either `H` or `W` and there is a grey border on all sides but all the 
slide is shown, does not alter whether fitted to height or width.

So I compiled the latest released version (v1.12) and this produced a mupdf-gl 
and mupdf-x11. The gl version showed the grey borders still, but the x11 
filled the entire screen and no movement when the H and V keys are pressed. 
When in presentation mode mupdf seems to support the Blinds and Wipe 
transitions but uses a fade for all the others.

If you have it, evince pdf reader, seems to have most support for presentation 
mode that I have found.

Cheers 

Deri

PS I did try setting the papersize in points (448p,252p), but the grey border 
still appeared, and it was hard to notice a difference.

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse

[Deri James]

On Mon 02 Apr 2018 14:30:51 Doug McIlroy wrote:
> > > Would it hence be sensible to change PDFPIC to fit 
the description
> 
> Yes. This is clearly a bug, even if it's been around for 
years.
> 
> Doug

100% agreement this should be fixed, although 
compatibility with previous version will be broken. If no one 
complains I will commit a fix.

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse?

[Deri James]

On Mon 02 Apr 2018 12:14:03 Ralph Corderoy wrote:
> Good afternoon Bernhard,
> 
> > > So pdfpic is an extension of pspic. By that you can now even replace
> > > all PSPIC by PDFPIC, nothing gets lost by that.
> > 
> > I read this as suggesting that results with -Tps and -Tpdf should be
> > equivalent.
> 
> Strongly agree.
> 
> > Would it hence be sensible to change PDFPIC to fit the description
> 
> +1.  Even though it may cause some existing documents to change if
> reproduced.  I don't think PDFPIC is old or widespread enough, to try
> and preserve its (broken) behaviour.

To avoid making existing documents render incorrectly I propose to allow the 
existing behaviour to be selected. Adding this to the NEWS file:-


PDFPIC has now been corrected, so the behaviour is the same whether you use 
the postscript or pdf drivers. However, this means that any documents which 
were written using the old behaviour will not be rendered correctly if using 
the pdf driver with the new version.

The change would mean that documents which relied on the previous behaviour 
are likely to have a gap underneath the image which was not there before. If 
you see this effect there are three ways you can restore the previous 
behaviour (listed in order of priority):-

A) Add the line ".nr PDFPIC_LEGACY 1" to the document before the first call to 
.PDFPIC.

B) If it is just a single document which exhibits this behaviour you can run 
groff adding "-rPDFPIC_LEGACY=1" to the command-line.

C) If you have many documents which rely on the previous behaviour you can set 
an environment variable "export PDFPIC_LEGACY=1" which will restore the 
previous behaviour for all runs.

Note that this change has no effect it you were using .PDFPIC with the 
postscript driver, only if you used it with the pdf driver.
=

Does this sound sensible?

Cheers

Deri

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse?

[Deri James]

On Tue 10 Apr 2018 19:26:57 Tadziu Hoffmann wrote:
> > I don't have a specific name suggestion, and I'm aware that
> > this is a bikeshed, but can I suggest a more explicit variable
> > name?  Otherwise the next time some old behaviour needs to be
> > switchably deprecated we're in for some confusion.
> 
> Maybe a descriptive name, for example PDFPIC_NOSPACE?
> Or, if this is versioned, PDFPIC_LEGACY_?

Thanks Tadziu, this makes sense, I'll use PDFPIC_NOSPACE for the groff 
variable and GROFF_PDFPIC_NOSPACE for the environment variable. The reason I 
want to include an environment variable is if we are changing the behaviour, 
there is at least a possibility a user has already many documents which have 
circumvented the bug in some way, I want to give the least work for them, 
adding one line to bash.profile is the minimal I could think of, and as PDFPIC 
already requires it to be run in "unsafe" mode the code to check an 
environment variable is fairly straight forward.

Cheers 

Deri

Re: [groff] groff as the basis for comprehensive documentation?

[Deri James]

On Sat 21 Apr 2018 08:16:36 Nate Bargmann wrote:
> Note that I am only working with Groff's man macro package and do
> understand that other macro packages may have greater demands on the
> HTML generator.

You might consider supporting mdoc macros. You may have seen:-

http://chuzzlewit.co.uk/WebManPDF.pl/man:/7/groff_mdoc

Which shows what a preprocessor inserting Keith's pdfmark extensions can do. 
Compare with:-

http://chuzzlewit.co.uk/WebManPDF.pl/man:/7/groff_man

Which has less semantic markup to use.

Note this runs on a very small arm powered computer, so there is a noticeable 
delay in serving the pages, it is much faster on my desktop. 

Re: [groff] hyphen, minus sign and hyphen-minus

[Deri James]

On Fri 25 May 2018 16:59:50 Pali Rohár wrote:
> Happens for: man -Tps and man -Tdvi
> 
> And I think that the best readable output is by grodvi driver. So would
> really like to have working copy+paste from the dvi output (converted to
> PDF viewer).

man -Tpdf will produce what you want. The '\-' (minus) is used as the output 
glyph, but any copy/paste (or searching within document) will use '-' (hyphen).

This is similar to the treatment of ligatures. If you look at the groff pdf 
output of 
the "find" man page you will see that "fi" has been replaced with a ligature in 
the 
output, but if you cut and paste the two characters “fi" are returned, and you 
can search for "find".

You can see this here:-

Re: [groff] hyphen, minus sign and hyphen-minus

[Deri James]

On Sat 26 May 2018 11:50:31 Ralph Corderoy wrote:
> Hi Deri,
> 
> > man -Tpdf will produce what you want. The '\-' (minus) is used as the
> > output glyph, but any copy/paste (or searching within document) will
> > use '-' (hyphen).
> > 
> > This is similar to the treatment of ligatures. If you look at the
> > groff pdf output of the "find" man page you will see that "fi" has
> > been replaced with a ligature in the output, but if you cut and paste
> > the two characters “fi" are returned, and you can search for "find".
> 
> For those of us that don't know PDF, how is this achieved?  Is it the
> PDF viewer that's translating to try and be helpful, assuming we don't
> want the ligature, and thus vary by viewer, or the PDF itself that
> states this should happen?  What if I do want to paste the ligature in
> `groff'?

Hi Ralph,

The "-u" flag for gropdf allows you to specify your own CMap which contains 
the information on glyph mapping. The default if you don't use the flag is:-

===

/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo
<< /Registry (Adobe)
/Ordering (UCS)
/Supplement 0
>> def
/CMapName /Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<> 
endcodespacerange
2 beginbfrange
<008b> <008f> [<00660066> <00660069> <0066006c> <006600660069> <00660066006C>]
<00ad> <00ad> <002d>
endbfrange
endcmap
CMapName currentdict /CMap defineresource pop
end
end

===

The section starting "beginbfrange" specifies the glyph to character mapping. 
The first two numbers are a start and end pair followed by the mapping you 
would like to use for each glyph in the range. If you include the flag "-u" on 
its own the default is not included so you could cut and paste the ligatures 
if you wanted.

Cheers 

Deri 

Re: [groff] hyphen, minus sign and hyphen-minus

[Deri James]

On Sat 26 May 2018 13:16:42 Pali Rohár wrote:
> And as I said "man -T dvi | dvipdfmx"
> gives me better PDF output as man -Tpdf. So for reading I would really
> prefer man -Tdvi

Hi Pali,

Have you tried passing -P-e on the command line when using -T pdf? One 
difference is that dvipdfmx always embeds the fonts, whereas gropdf does not 
automatically embed the base 14 type 1 fonts, so it is then up to the pdf 
viewer to select the actual font it uses. On my system it seems to use 
LiberationSerif for Times Roman. If you include the flag the ghostscript Times 
Roman font will be embedded.

You may even be able to use the flag -P-yU on the command line, which instead 
will embed the URW versions of the fonts.

Finally, you might install the tex Computer Modern fonts for gropdf to use in 
place of the currently installed fonts. One of these stratagems may be as good 
as the dvi route.

Cheers 

Deri

Re: [groff] Macron characters in pdf files

[Deri James]

On Mon 04 Jun 2018 23:21:15 Peter Schaffter wrote:
> Greetings.
> 
> I've verfied that the problem discussed in the following forwarded
> email exists.  -Tps has no trouble finding macron characters
> composed in vim; -Tpdf does.  Deri, I think this is your bailiwick.
> 
> :)
> 

Hi Peter,

I'm having trouble recreating the problem here. So I need a little help, since 
you can create the issue.

I have created a little test file in vimwith some macron(ned) characters. 
Since this is a utf-8 file I added -k to the groff command, but none of the 
resulting unicode glyphs are available in my fonts, so they are all rejected 
with the warning "can't find special character". Without the -k flag I do see 
the capital A’s described below, but this is just groff cheewing up the "wide" 
chars in utf-8.

The results, i.e. failure, are identical for both gropdf and grops.

If I now insert the line ".ft U-TR" at the top of the file, using the URW 
fonts which do contain the required glyphs, all seems fine and dandy for the 
gropdf output. As an aside it would be lovely if groff had the same concept of 
"foundry" as gropdf, i.e. you could put ".ft TR" in your troff file and select 
the foundry in the groff command line with something like "-y U". Groff would 
then identify the font to use as U-TR and that would be passed to the 
postprocessors.

So I am a little stuck. If you can recreate the issue on your system, please 
can you run this example for ps and pdf using groff's -Z flag, capture any 
errors as well (2>&1), and send me the results.

But it may be all he needs is .FAMILY U-T or similar, to make it work, depends 
on whether his gropdf includes the U foundry.

Cheers 

Deri

NB Example  file builds with:-

groff -Tpdf -k macron.trf

> > Greetings good Sir and thank you for MOM!
> > 
> > I'm writing today because I cannot seem to overcome an issue where I am
> > unable to get macrons over vowels to display correctly in the resulting
> > pdfs. I am on Arch linux using vim as my text editor.
> > Groff version 1.22.3-7 is installed.
> > I use Atril to display pdfs.
> > I can write in Libreoffice Writer and enter the macron-vowels thru the
> > charcter selector, then export to pdf and the characters display correctly
> > so I have fonts installed sufficient to display the macron characters.

But perhaps not registered for gropdf.

> > I
> > can enter the macron-vowels in vim using the Ctrl-K diagraph keybindings
> > and they display correctly in the terminal. If I export the .mom file to
> > ps
> > the result, whilst ugly, displays the macron-vowels correctly, so I
> > believe
> > somewhere in groff something is going wrong. 

I'm not sure what "ugly" means in this context.

> > What I am getting in the pdf
> > is the Capital A with strange markings in place of the i or o with macron
> > intended. 

I see this, in both pdf and ps output if I don't include preconv as part of 
the run.

> > I found online a groff macro .AM which claims to be able to
> > produce macron characters, but I do not see how to incorporate this with
> > mom. I also tried \[i-] style with no luck.
> > I get "can't find special character" errors with this method.

I suppose this is composite \[i -], which generates the correct glyph, but it 
is not in the default font

> > Trying e.g. \[34] and \[de] works, but the macron does not seem to work.
> > Please tell me, is this missing funcionality or am I missing something in
> > the documentation on how to produce macron-vowels with mom?
> > 
> > I thank you again for all the hard work you have done to create mom - I do
> > not want to have to use Libreoffice Writer or another piece of software. I
> > love mom, but need to learn how to overcome obstacles such as this one.
> > 
> > Steve PhilippA> 
> - End forwarded message -
.sp 1i
.nf
.ft U-TR
What does ctrl-K do?

a = ā
A = Ā
e = ē
i = ī
o = ō
u = ū
U = Ū

a = \[a u0301]
A = \[A u0304]

Re: [Groff] Introduction

[Deri James]

On Tuesday 18 Oct 2005 12:44, D. E. Evans wrote:
>
> >We had a discussion on this list a few months ago, that if anyone had
> > done a WYSIWYG front-end for groff years ago, it would be more viable for
> > the masses.  Sigh.
> >
> Like all UNIX tools, the specialized ones are the most viable.  I
> lament the day groff goes gui.  However, I think that a seperate
> gui frontend is not a bad idea.
>

I am not persuaded a gui would improve groff adoption (has LyX helped LaTex?). 
The power of groff, as a typesetting program, is in its speed and 
scaleability. It quite happily gobbles up a 7GB '.trf' file producing 
900,000+ pages of coloured postscript in under 4 hours (always impresses 
me!!).

Cheers

Deri


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Introduction

[Deri James]

On Thursday 20 Oct 2005 19:46, Larry Kollar wrote:
> Is anyone collecting the "reasons for using groff" that have been
> going by in this thread? Such a collection would be a fine beginning
> to an advocacy/"Why Use groff" chapter in UTP (or a standalone web
> page). I'd be particularly interested in seeing James Deri send in a
> write-up about his monster print jobs. (We could put that under a
> heading like, "Scale THIS!" :-D)

My "monster" print jobs are client valuations for a Stockbroker. Groff is used 
in the final stage to actually typeset the report, including a barcode on 
each page to control the "finishing" at the printers, (i.e. Envelope closure, 
mailbag switching - output is mail sorted to reduce postage costs).

The system uses data from 3 sources: the raw data to go in the report, one or 
more Templates (similar to CSS) which describe the "look" of the report, and 
a simple procedural language similar to FileTab/FTL6 which controls the logic 
and structure of the report. These 3 elements are then combined/sorted into 
a .trf file and converted to postscript by groff.

Cheers

Deri


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Introduction

[Deri James]

On Monday 24 Oct 2005 21:40, you wrote:
> Deri,
>
> Are the barcodes generated by troff?  (A special font?)
>
> Or are they images that are generated, and then something like  .PSPIC 
> glues them into the documents?

I generate the bar code directly, using interleaved 2of5. (GPLed font here:- 
). This is a "numbers only" barcode 
which holds 2 numbers per character. The author of the font includes a perl 
script to calculate these character pairs which I converted to a troff macro.

Each print bureau has different  requirements for "driving" their finishing 
equipment, so this barcode is specific to the bureau used. In this case the 
bureau required the barcode to be in a specific position along the long edge 
of an A4 sheet, whilst the rest of the report is portrait, so I used some 
rotation macros (provided on this list some time ago).

I attach a small example, you would need to install the font above to run it. 
(The example is a bit "quirky" since it is generated by the system described 
in my previous post with superfluous sections removed). Run it with:-

groff BCex.trf > BCex.ps

then use a PS viewer to view result. If you don't see a barcode check that you 
have added "Codei25JK   Codei25JK.pfa" to your 'devps/download' file.

Hope this helps.

Deri



BCex.trf
Description: Troff document
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] PS printing - was Re: `Idot' vs. `Idotaccent'

[Deri James]

On Friday 10 Mar 2006 14:28, Michail Vidiassov wrote:
> Dear All,
>
> let us run some survey.
> Please, tell us, how do you use groff PS output.
> Do you know how other people use it?
> Is it really in use?
> Do you use fonts supplied with groff or install your own font files?
>
> Werner is now desiding what to consider the default font set for devps.
>
>   Sincerely, Michail
>

Michail,

Every quarter I produce PS files which contain approx 500,000 pages. These 
files are sent to a commercial printer. Each page contains a barcode to 
control "finishing" (i.e. Envelope stuffing, mailbag breaks, etc.). In 
addition another 500,000 PS pages are produced which are split into about 
65000 PDF files (substantially similar to the print run but including colour 
and PDF Bookmarks). Groff produces the PS files at about 200,000 pages an 
hour (and this includes generation of the .trf file (which can be up to 4.5Gb 
in size) and several large sorts to get the output into mailsorted order).

Fonts used are the Helvetica family and Helvetica-Narrow. The only font I add 
is Barcode 3of9, whch is a very simple procedure.

Cheers

Deri


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

[Groff] Using Printer "Jogging" with groff

[Deri James]

Hello,

I have been trying to get printer "jogging" to work from within groff. The 
print bureau have told me I just need to insert this code on the page which I 
need "jogged":-

%%BeginFeature: *Jog
<< /Jog 3 >> setpagedevice
%%EndFeature

so I set up two macros:-

.de Jogger3
ps: exec
%%BeginFeature: *Jog
<< /Jog 3 >> setpagedevice
%%EndFeature
..
.de Jogger0
ps: exec
%%BeginFeature: *Jog
<< /Jog 0 >> setpagedevice
%%EndFeature
..

which I use by:-

\Y[Jogger3]

and

\Y[Jogger0]

as appropriate.

This seems to produce Postscript output like this:-

%%Page: 1 1
%%BeginPageSetup
BP
%%EndPageSetup
1.05 34.8 EBEGIN
%%BeginFeature: *Jog
<< /Jog 3 >> setpagedevice
%%EndFeature
EEND

The print bureau tell me that when they print this document, although it jogs 
correctly, each line on the page with "jog" commands embedded comes out 
reversed. (i.e. text printed right to left - and in the wrong orientation - 
this was a landscape A4 document.)

Incidentally ghostscript 8.15 barfs on the above postscript, but if I enclose 
the snippet within '[{' and '} stopped cleartomark' gs displays it fine but 
the printer still fails.

Just wondered if someone had solved a similar problem using 'setpagedevice'.

Cheers

Deri


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] doclifter on groffer.man

[Deri James]

On Monday 01 January 2007 19:52, Eric S. Raymond wrote:
> Here is a slightly expanded version of a diagram I posted back towards
> the beginning of the discussion:
>
[...]
>
> The box in the middle is intended to indicate the use of DocBook as a
> common interchange format.

I may have, on occasions, over imbibed on seasonal refreshments in recent days 
so I thought I'd try and set down the knub of this discussion.

Technical documentation has 3 elements - content (the actual words written) - 
structure (gives context to the content) - style (controls the presentation 
of the structure and content).

1. It would be desirable to be able to browse/navigate/search *nix technical 
documentation in a consistent manner - HTML/Browser posited as solution.

(Dealing just with 'man' pages now)

2. Currently man pages generally use the -man macros, although there are no 
restrictions in using any *roff command/escape.

3. The 'man' page author intends to present technical information in the way 
he thinks it will be easiest for the audience to absorb, i.e. he will be more 
interested in presentation and content than structure. This tends to be 
counter to the aims of (1), since a common structure is required to add 
navigational tags and intelligent searching.

4. Fortunately, in the real world, most man page authors have used 
standard -man macros so some structural information can be derived from this. 
By using AI techniques further structure can be deduced.

5. This structure and content of a man page could be captured in XML-Docbook 
by a program called 'doclifter'. 

6. Using just content and structure 'clean' HTML could be produced relying on 
a standard CSS to control presentation. This would mean that presentation 
would not be preserved from the man page,  but would put this under control 
of the user (should high contrast colours, larger fonts, different text to 
speech voices to differentiate structure elements, etc. be required). 

7. Since HTML output would not preserve the original presentation, it would be 
desirable to offer the user a way of viewing the man page as it was 
originally intended (groffer??!). The user can then choose whether to print 
using the browser formatted output, or groff formatted output.

Point 6 above may be "new", in that it appears 'doclifter' is attempting to 
derive presentation information from the troff source (as well as content and 
structure). I would argue this is unnecessary, it would be more desirable to 
completely divorce content from presentation, storing content and structure 
in the XML and relying on a CSS to control presentation. If 'doclifter' 
solely concentrates on extracting content and structure it may be 
considerably simplified (to extract content 'nroff' is your friend ;-)). 
Mapping troff source (to extract structure info) to an nroff image of the 
page, may be easier than trying to track all groff commands and escapes.

Just my tuppence.

Cheers 

Deri


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Paper Size with groff and evince on Ubuntu 7.10.

[Deri James]

On Monday 21 April 2008 15:40:57 Ralph Corderoy wrote:
> Hi,
>
> I'm on Ubuntu 7.10 with
>
> groff 1.18.1.1-12
> evince2.20.1-0ubuntu1
>
> I'm finding evince doesn't treat the PostScript from groff as being A4.
>
> $ cat /etc/papersize
> a4
> $ date | groff -ma4 >date.ps
> $ g '^%' date.ps
> %!PS-Adobe-3.0
> %%Creator: groff version 1.18.1
> %%CreationDate: Mon Apr 21 15:36:37 2008
> %%DocumentNeededResources: font Times-Roman
> %%DocumentSuppliedResources: procset grops 1.18 1
> %%Pages: 1
> %%PageOrder: Ascend
> %%Orientation: Portrait
> %%EndComments
> %%BeginProlog
> %%BeginResource: procset grops 1.18 1
> %%EndResource
> %%IncludeResource: font Times-Roman
> %%EndProlog
> %%Page: 1 1
> %%BeginPageSetup
> %%EndPageSetup
> %%Trailer
> %%EOF
> $
>
[snip]
>
> Cheers,
>
>
> Ralph.

Does the 'DESC' file in 'devps' contain 'papersize /etc/papersize a4'? 

If you upgrade to 1.19+ you would also have:-

"o The paper size is now emitted via the %%DocumentMedia and PageSize
  mechanisms so that it is no longer required to tell `gv' or `ps2pdf'
  about the paper size.  The `broken' flag value 16 omits this feature
  (the used PostScript command `setpagedevice' is a LanguageLevel 2
  extension) -- if you intend to further process grops output to get an
  encapsulated PS (EPS) file you must also use this option.

  Patch by Egil Kvaleberg <[EMAIL PROTECTED]>."

Cheers

Deri

Re: [Groff] Groff Pic and colored objects!

[Deri James]

On Friday 23 May 2008 19:23:12 pod wrote:
> How can I define own colors?

Hi Pod,

Dean has illustrated the use of "shaded" in pic. You can get a list of 
predefined colour names by looking for the file "ps.tmac". You can also 
define your own colours (from 'info'):-

===

 -- Request: .defcolor ident scheme color_components
 Define color with name IDENT.  SCHEME can be one of  the following
 values: `rgb' (three components), `cmy' (three components), `cmyk'
 (four components), and `gray' or `grey' (one component).

 Color components can be given either as a hexadecimal string or as
 positive decimal integers in the range 0-65535.  A hexadecimal
 string contains all color components concatenated.  It must start
 with either `#' or `##'; the former specifies hex values in the
 range 0-255 (which are internally multiplied by 257), the latter
 in the range 0-65535.  Examples: `#FFC0CB' (pink), `##'
 (magenta).  The default color name value is device-specific
 (usually black).  It is possible that the default color for `\m'
 and `\M' is not identical.

 A new scaling indicator `f' has been introduced which multiplies
 its value by 65536; this makes it convenient to specify color
 components as fractions in the range 0 to 1 (1f equals 65536u).
 Example:


  .defcolor darkgreen rgb 0.1f 0.5f 0.2f

 Note that `f' is the default scaling indicator for the `defcolor'
 request, thus the above statement is equivalent to


  .defcolor darkgreen rgb 0.1 0.5 0.2

==

You must place your ".defcolor" BEFORE your .PS line. So, this should work:-

.defcolor GroovyGreen rgb #60b040
.defcolor PerfectPink rgb #f0b0b0
.PS
box height 0.3 shaded "GroovyGreen" "foofoo";
arrow arrowwid 1;
box width 3 height 3 shaded "PerfectPink";
{"foofoo" at last box .n + (0,-0.1);}
box width 1.8 height 1.5 at last box .w + (1.5,0);
.ps 8
{"\fBfoofoo()\fR" colour "GroovyGreen" at last box .n + (0,-0.3);}
.PE

Cheers

Deri

Re: [Groff] GSView question (groff-PostScript viewer)

[Deri James]

On Monday 29 September 2008 20:23:02 Clarke Echols wrote:
> I finally bit the bullet and got rid of my Windows 98 SE operating
> system, replaced the drive with a RAID mirror pair of 500 Gbyte
> drives, added 2 Gbytes of memory, and installed Ubuntu Linux.
>
> I feel like the outcast who came out of the cold dark winter into
> the summer sunshine. :-)
>
> On my old setup, I was using groff running in a bash shell as part
> of the cygwin package, and got the shareware PostScript viewer
> "GSView" which I really like for several reasons.
>
> However, when I loaded Ubuntu, the closest I could get is the
> freeware KDE product "KGhostView" which displays just fine, but
> leaves three problems:
>
> 1. Every time I reload the PS file, it resets to page 1
>instead of automatically detecting the file being changed
>and reloading automatically (I *really* like that feature).
>
> 2. It doesn't display the page number in the lower border of
>the program window ("Page n of x").
>
> 3. The nifty counter in the bottom border that shows the x,y
>coordinates of the cursor on the PostScript page is missing
>and I need that feature so I can check dimensions and
>locations when doing page design and layout work (saves
>printing a lot of paper).
>
> In searching on GSView, I get some garbage web sites that claim to
> "crack" the program, but I haven't encountered a definitive
> indication of whether GSView is available for Ubuntu.  Ubuntu's
> Add/Remove software function doesn't know about it, and it's always
> nice to be able to use that function because it is so effortless and
> clean, in comparison with dowloading product packages and installing
> them manually.
>
> Anyone on the list using GSView on Linux?
>
> If that isn't available, I'll have to fire up my Windows XP
> machine (YUK!) and get GSView installed on it...
>
> Thanks,
>
> Clarke

Have you tried 'gv'? It has feature 3.

Or 'kpdf' ('okular' on KDE 4) which will display postscript as well and has 
features 1&2.

Cheers

Deri

Re: [Groff] How to draw a colorful circle/box with colorful text

[Deri James]

On Friday 10 October 2008 13:43:26 Werner LEMBERG wrote:
> > how to draw a circle with red shade and red edge, while the text is
> > green?
>

How about:-

.PS
r=1

circle rad r "\s-2A\s+2" shaded "red" outline "green" invisible

.PE

Cheers

Deri

[Groff] Re: gropdf driver (was: pdfroff produces two copies)

[Deri James]

On Tuesday 04 August 2009 19:58:04 Werner LEMBERG wrote:
> [Deri, I hope it's OK with you that I cite from your private email to
>  me.]
>

Fine.

>
> Some weeks ago Deri James sent me a first implementation of a gropdf
> driver; I've uploaded it temporarily to
>
>   http://groff.ffii.org/groff/gropdf/
>
> Deri writes:
>
>   [...] Its drawback is its written in perl and has a dependancy on
>   perl module Compress::Zlib (to do the Flate compression).  However,
>   despite this, you may consider it useful to have a 'native' PDF
>   driver for groff (rather than the PS -> ghostscript route).  It is
>   slower than grops but faster than grops+gs.
>
>   The archive contains bin/gropdf (which should be installed in the
>   same directory as 'grops'), /devpdf which should be installed in
>   your groff font directory, two files for the /tmac directory, and an
>   /examples directory.
>
>   NOTE: Lines 13-15 of 'gropdf' must be "hand edited" to configure for
>   your particular 'groff' setup.  Of course these paths would normally
>   be inserted by an install script.
>
>   The /devpdf directory includes the .pfa fonts required to supplement
>   the 14 PDF type 1 base fonts up to the standard 35 fonts which
>   PostScript uses.
>
>   Gropdf supports the following run switches:-
>
>   -p  (same as grops)
>   -l (landscape mode - NOT WORKING yet!!)
>   -d (debug mode - uncompressed PDF and troff output included as comments)
>   -F 
>
>   TO DO
>
>   Fix landscape.

A new version of just 'gropdf' (i.e. you need the .tgz from Werner's site 
installed first, then replace) is here:-

<http://www.chuzzlewit.demon.co.uk/gropdf/>

Very little difference but landscape now works. :-)

(It actually contains a lot more code than the original I sent to Werner, 
which will hopefully allow individual PDF pages to be 'included' (in the same 
way grops allows an EPS to be embedded) - but not yet!!).

Any feedback will be appreciated.

Cheers

Deri

Re: [Groff] gropdf driver (was: pdfroff produces two copies)

[Deri James]

On Wednesday 05 August 2009 11:30:50 joerg van den hoff wrote:
> just a short feedback:
>
> 1.)
> thanks!
>
> 2.)
> in a first test with
>
> groff 1.19.3
> perl v5.8.8
> macosX
>
> this seems to work more or less correctly.
> but with a small text sample the generated pdf was about a factor of
> 10 larger than that resulting from `ps2pdf' (i.e. gs). furthermore `gv'
> complained when
> displaying the pdf-file:
>
>
>  Warning:  An error occurred while reading an XREF table.
>  The file has been damaged.  This may have been caused
>  by a problem while converting or transfering the file.
>  Ghostscript will attempt to recover the data.
>
> ... which Ghostscript apparently is able to do, since the display looks
> OK, but
> something seems to be murky in the generated pdf...
>
> best regards,
>
> joerg

The warning you get occurs when the XREF table is incorrect, it is "non-fatal" 
since all PDF Readers I've looked at will rebuild this table when corruption 
is identified. I'd welcome a copy of the .trf and resulting .pdf (off list) if 
this is possible.

When you say the .pdf is 10x bigger, I assume you mean the file size, rather 
than the scaling of the output. This  will be due to the fact I embed the 
entire font if you "use" it whilst 'gs' subsets the font to only  include the 
glyphs you actually require. Of course this "overhead" reduces when dealing 
with larger .trf files.

Cheers

Deri

Re: [Groff] gropdf driver (was: pdfroff produces two copies)

[Deri James]

On Wednesday 05 August 2009 11:30:50 joerg van den hoff wrote:
>  Warning:  An error occurred while reading an XREF table.
>  The file has been damaged.  This may have been caused
>  by a problem while converting or transfering the file.
>  Ghostscript will attempt to recover the data.
>
> ... which Ghostscript apparently is able to do, since the display looks  
> OK, but
> something seems to be murky in the generated pdf...
>
> best regards,
>
> joerg

Hi Joerg,

I've tracked this down (thanks for the samples). I'd failed to notice the 
PDAReference (from Adobe) requires a trailing single space on each line in the 
XREF table!!&&**!!

Now fixed and 'gv' has stopped belly aching about it! Fixed version is 
available here:-



Cheers

Deri

[Groff] PIC patch (was A little greeting card)

[Deri James]

After having looked at Ted's greeting card example I realised that 'pic' 
outputs:-

\X'ps: exec gsave currentpoint 2 copy translate %.4f rotate neg exch neg exch 
translate'

to achieve the rotation and terminates it with:-

\X'ps: exec grestore'

I wanted the PDF driver (gropdf) I've been working on to work with pic so I 
included these lines in the parser to rotate as appropriate. However I 
discovered that pic did not output the 'grestore' line when using pdf as the 
output device (but it did output the 'rotate' line).

The reason is because the 'rotate' line uses this condition:- 

.if \n(0p \{\

but the 'grestore' uses this condition:-

.if '\*(.T'ps' \{\

Register '0p' is set in ps.tmac (and pdf.tmac) but of course '.T' is different 
for 'ps' and 'pdf'.

This diff can patch 'pic' to use the same condition for both lines.

--- src/preproc/pic/troff.cpp~  2010-01-01 18:00:29.0 +
+++ src/preproc/pic/troff.cpp   2010-01-01 18:00:29.0 +
@@ -462,7 +462,7 @@
   fputs("\n.sp -1\n", stdout);
 }
   if (rotate_flag)
-printf(".if '\\*(.T'ps' \\{\\\n"
+printf(".if \\n(" GROPS_REG " \\{\\\n"
   "\\X'ps: exec grestore'\n.sp -1\n"
   ".\\}\n");
 }

Is this Ok Werner?

Cheers

Deri