[groff] [UTROFF] Utmac-0.4
Hello alls, I am pleased to announce you Utmac-0.4, the last version of my set of macros for Heirloom Troff. It is available on <http://utroff.org>. It has been four years since I published a version and wrote on this list: After my PhD, I found myself unemployed, and with my newborn child, that was harrowing. Hopefully, the sky is now clearing up, and I can allow myself some leisure activity! Here are the main changes. - I separated Utmac from the Utroff package: my long term goal is to make Utmac less dependant of Heirloom Troff and more compatible with neatroff and groff. For that purpose, I splitted the macro files in subfiles. - That was a good opportunity to clarify the code source. - And I added the macro ul, designed to write letters. To celebrate the event, I will write you several mails within the next few days to present you some of the goals and technical designs of Utmac. Kind Regards, Pierre-Jean.
[groff] [UTMAC] Layout and Typography
Hello alls, As promised, here is my first article about Utmac. The goal is not to convince you to use utmac, but simply to discuss about writing macros for troff. Today, I’ll discuss about typography and layout. Utmac aims to produce beautiful documents, and I tried to respect some of the good practices in that matter. # Vertical alignment All lines are placed on a strict vertical grid. For that purpose, in Utmac, the only unit of all vertical movements is the line height (v in heirloom troff). Marginal notes, recto and verso, odd and even pages should all end up being aligned. # Paragraph at once adjustment -- Utmac uses the paragraph at once adjustment of Heirloom Troff. But it also uses a less known algorithm, developped for PdfTex, and included in Heirloom Troff, which slightly adjusts the size of glyphs to optimize the adjustment. That behaviour is configured with the letadj command. Its arguments are: minimum interglyph size, minimum glyph size, width of word that can be expanded, maximum interglyph size and maximum glyph size. I found that adjusting by 1% give the best results – but Heirloom Troff’s adjustment algorithm is not exemplar. .letadj 99 99 15 101 101 # Hanging characters The alignment is visually adjusted by allowing some characters to exceed lightly their normal position at the end of the line. That is called "hanging characters". Heirloom troff provides the rhang macro for that purpose: if font is used and char is at the end of the line, the line size is increased by size, which is 1/1000 of an em. .rhang font char size # Widows and orphans Each time Utmac begins a paragraph, it checks its position on the page, and prints a warning if he discovers a widow, an orphan, or an empty bottom line. To remove these glytches, the macro TI and TD can be used to increase and decrease the size of a paragraph. Amongst other things, TI and TD internally use the letadj command. .\" increase a paragraph .letadj 100 100 15 102 102 .\" decrease a paragraph .letadj 98 98 15 100 100 # Typographic details - In french, most punctuation marks are preceded by some space. Utmac uses localization files to define them. For example u-fr contains: .char : \~: .char ? \|? # Fixed layout -- As a result of that care to typographic details, Utmac’s layout is not configurable. I believe Mom fills the need of configurability, and I also believe Troff is easy enough to encourage people to hack or write macros. Nonetheless, since a single layout can’t satisfy all needs, Utmac comes with three different ones: - uh, for humanities, that I used to write my philosophy thesis. It uses marginal notes so the pages are not broken by bottom ones. - us, uses a common layout similar to the one used by ms. - ul, to write cover letters and curriculum vitae. It also uses marginal notes, but instead of populating them at the top of the page, they are displayed at the side of the text calling them. On my next mail, I’ll write about paragraph at once adjustment.
[groff] [UTROFF] Pagraph at once adjustment
Hello alls, As stated on my previous mail, I’ll talk today about the paragraph at once adjustment of Heirloom Troff in Utmac. # Paragraph at once adjustment details -- The paragraph at once adjustment appears to be difficult to use, because of the way it has been implemented by Gunnar Ritter: macros within the paragraph are executed before the whole paragraph is adjusted. As a result, notes are diverted in the page where the paragraph begins, while the corresponding line could appear on the next page. To solve that problem, Heirloom Troff provides an output line trap \P[macro] which only executes the macro when the line is printed. Utmac uses these output line traps each time it is needed, particularly to divert notes and refer to a page number. .nr num 1 1 .de NS .\" Start a note . \" Put an output line trap. \P[note:trap-\\n+[num]] . \" Define an output line trap macro . de note:trap . \" collect all notes in note:div . da note:div . br . nf . \" actually print the note . note:print-\n[num] . br . di . ev . ev note . br . \" divert the note to the macro note:print-W, . \" which is only called when the line is printed. . di note:print-\\n[num] .. .de NE .\" End a note . br . di . ev .. As you might notice, it is not easy to understand, even in this simplified example. That complexity is not the only flail of the paragraph at once adjustment of Heirloom Troff: it is also bugged, as noticed on the repository of Karsten Kunze: <https://github.com/n-t-roff/heirloom-doctools/issues/22> These two reasons motivated me to try to port Utmac to Neatroff. That’s a lot of work, since both Neatroff and Heirloom Troff have their special set of troff commands. Hopefully, once ported to neatroff, it should be easy to achieve compatibility with groff. On my next mail, I’ll probably talk about fonts. Kind Regards, Pierre-Jean.
[groff] [UTROFF] About fonts
Hello alls, As said yesterday, my little tour of Utmac will focus today on fonts. And I hope to prove you wrong if you think there’s not much to discuss on that topic! # An user interface for fonts - Heirloom Troff can mount OpenType fonts like any other font. It can also define all kind of ligatures, adapt the kerning, and enables the OpenType features, as follow. .fp 1 R LinLibertine_R otf .flig R ct \[c_t] st \[s_t] .feature R +lnum .kernafter R ’ 100 That’s very handy. But the problem with such an easiness and the variety of available features, is that I quickly had too many mounted fonts, and it was becoming difficult to name each of them. Another problem was coming for the difficulty to know which font to use in a particular context. For example, the (private) font Apolline, has a lightly embolden font made for small text: If the user want to use italic inside a note, he should not use \fI, but \f(DI. To solve these problems, I began to use strings to define fonts, and I eventually opted for the easy, hierarchical, xml inspired, user interface for fonts: Roman \*IItalic\*I \*BBold \*IBold Italic \*UBold Italic Superscript\*U\*I\*B I think there is yet a post on this list about those font toggles. Here is how it is implemented in Utmac (in the file u-fonts.tmac). First, fonts are internally mounted and named in the form f-[Bold][Italic][Feature], where Bold, Italic, and Feature are numbers: f-000 roman f-100 bold f-010 italic f-001 small capitals f-002 acronyms, all capitals f-003 superscripts f-004 subscript f-005 final glyphs f-113 bold italic superscirpt f-302 Extra bold acronyms Secondly strings are defined to expand to the internal font name: .ds I \f[010] Thirdly, a substraction is inserted in the string definition, to toggle the font on or off each time it is used. .nr f-i 0 .ds I \\R’f-i 1-\\n[f-i]’\\f[0\\n[f-i]0] \*Iblah\*I => \f[010]blah\f[000] . .ds B \\R’f-b 1-\\n[f-b]’\\f[\\n[f-b]\\n[f-i]0] .ds I \\R’f-i 1-\\n[f-i]’\\f[\\n[f-b]\\n[f-i]0] \*Iblah \*Bblah\*B\*I => \f[010]blah \f[110]blah\f[010]\f[000] Fourthly, a system allows the possibility to set all kind of defaults, ie, to say that the default font is f-310, and its italic f-300. In the end, the strings are defined as follow: .\" The mounted font (roman) .ft f-000 .\" The font toggles: unset if == 0, set if > 0. .nr f-b 0 .nr f-i 0 .nr f-f 0 .\" The subfont strings: we may want the default .\" to be italicized (for example in a heading), .\" and the \*I to toggle the Roman form... .\" So, these strings offer that possibility. .\" (I did not need subfont strings for the features) .nr font-bold0 0 .nr font-bold1 1 .nr font-ital0 0 .nr font-ital1 1 .\" The whole internal font string, of the form f-XXX .ds f-l f-\\n[font-bold\\n[f-b]]\\n[font-ital\\n[f-i]]\\n[f-f] .\" The font strings displayed to the user .\" The first part of the string toggles the format. .\" The second part of the string sets (print) the font. .\" Bold .ds B \\ER’f-b 1-\\En[f-b]’\\f[\\E*[f-l]] .\" Italic .ds I \\ER’f-i 1-\\En[f-i]’\\f[\\E*[f-l]] .\" Small capitals .ds C \\ER’f-f 1-\\En[f-f]’\\f[\\E*[f-l]] .\" Acronyms (all capitals) .ds A \\ER’f-f 2-\\En[f-f]’\\f[\\E*[f-l]] .\" Superscript .ds U \\ER’f-f 3-\\En[f-f]’\\f[\\E*[f-l]] .\" Subscript .ds L \\ER’f-f 4-\\En[f-f]’\\f[\\E*[f-l]] .\" Final glyphs .ds F \\ER’f-f 5-\\En[f-f]’\\f[\\E*[f-l]] While the system may seem complex, it works perfectly, and has a very simple user interface. It also comes with another advantage: it is now easy to create xml documents from troff sources. But that will be for my next topic! Cheers, Pierre-Jean.
Re: [groff] [UTROFF] About fonts
Larry Kollar wrote: > This is one of the things I like about Groff: the “.fam” request sets the > font family, > and then the usual B / I / BI / R settings apply from there. For small caps, > I think > a SC setting would be a sensible extension. Indeed, that request seems very helpful. > In my printed fiction, I use small caps for the headers (and in the front > matter). > I’ve been using Neatroff for that, since I can turn on small caps with the > .ff request. > It’s straightforward. Fonts are better defined inline, in my opinion. I mean, there are a lot of situations where we want to get rid of the space automatically added by requests. > >f-000 roman > >f-100 bold > >f-010 italic > >f-001 small capitals > >f-002 acronyms, all capitals > >f-003 superscripts > >f-004 subscript > >f-005 final glyphs > >f-113 bold italic superscirpt > >f-302 Extra bold acronyms > > TBH, I think this is overly complex… unless many TT/OT fonts provide special > glyphs for super/subscript and acronyms. (I’m not sure what “final glyphs” > means > in the above.) AT&T Troff attempted to render acronyms using what amounts to > small-caps; I’m not sure what typographical difference there is between > acronyms > and small-cap strings. Inside the macro, it is complex, indeed. From the user point of view, I believe the result is simpler than using hardcoded fonts (since Heirloom Troff does not have that .fam request). But, when we look at it, this system is nothing else than the .fam request implemented within a macro: \*I adjusts a parameter within a font family like \fI does in groff. It is only more complex in appearance, because it deals with features too. Yet, I will have a second look at the implementation, to see if using a syntax close to the .fam request could be better. Utmac handles three fonts: Linux Libertine, Linux Biolinum, and Apolline (a private font from Porchez Tyopfonderie). All of them have both superscripts and subscripts (should I say «inferiors»?). Final glyphs are decorative final characters (available in Apolline), to be used at the end of a heading or a paragraph. As we can see, the complexity comes from the highly detailed fonts we can find these days. So, yes, my opinion is that groff should consider offering shortcuts for not only B, I, BI, SC, but also for superscripts and inferiors, and could even consider embolden and italicized small caps, superscripts and inferiors... Concerning acronyms, Jost Hochuli (in «the detail in typography») remarks that capitals are too high above the line to be pretty, while small caps have a highlighting purpose we do not want for acronyms. So, he advises to use normal capitals, but with a reduced size. That's what the \*C does in utmac (using the .fzoom request of heirloom troff). > OK, I’m intrigued. If you can get clean XML out of a *roff file, you have > something > worth looking at! If not today, I'll write about this tomorrow! Thank you for your remarks, Pierre-Jean.
[groff] [UTROFF] Troff and xml
Hello alls,
Resuming my little sery of articles, I am explaining today how
Utmac is linked to the XML world.
# Troff and Xml
---
We all have in mind the various attempts to produce XML files
from a troff document: some aim to be universal, and, dealing
with the raw troff requests, can only ouptut non semantic html
with hardcoded styles, while others, dedicated to a particular
macro, fail to consider the raw troff requests the user may need
in his document (cf. the source of ms2html, in which the author
comments he is implementing more and more raw troff requests)
XML files are nothing else but plain text files with semantic
informations. On the other side, a troff document contains
structured information which gets its meaning within the context
of a macro. When we think at it, we have yet a tool which
interprets a troff source within the context of a macro to
produce plain text files: nroff. Could we use nroff to produce
xml files ? I tried, and it appears that solution works well.
The idea is simple: one only has to write a macro file, which
interprets all the interface macros (paragraph, headers...), to
add XML tags to the output file. For example, here is a simple
macro to produce XML paragraphs and headings:
.de PP
. \" first, we close the previous block
. \" by printing its recorded tag
. if d xml-block \\*[xml-block]
. \" Secondly, we define the closing tag for the block
. ds xml-block
. \" and last, we print the openning tag.
..
.de H1
. if d xml-block \\*[xml-block]
. rm xml-block
\\$*
..
Nroff has to be configured to produce a correct xml files: we do
not want hyphen, lines don’t need to be adjusted, and, the page
length has to be defined correctly.
.\" page length is one line
.pl 1v
.ll 75
.\" don’t adjust nor hyphenates
.na
.nh
.\" Ending macro is doc:end
.em doc:end
.\" Print header
< ?xml version="1.0" encoding="UTF-8" ?>
.\" Open the root tag
.de doc:end
. \" doc:end needs some more space to output text
. pl \\n(nlu+3v
. \" close the previous block
. if d xml-block \\*[xml-block]
. \" Close the root tag.
. \" set correct page length
. pl \\n(nlu
..
Since the fonts are hierarchical and defined as strings in Utmac,
they are easy to implement as well.
.ds font-bold0
.ds font-bold1
.nr f-b 0
.ds B \ER’f-b 1-\En[f-b]’\E*[font-bold\En[f-b]]
The only real problem of using nroff to produce xml documents is
that — along with troff — it is not easy to deal with
automatically inserted spaces. I tried to use .chop and \c, but
without reliable results. To solve that problem and escape the
possible restricted characters a user may insert in his document
(’<’, ’>’, and ’&’), I wrote a small post-processor – postxml –,
which translates a custom set of tags to xml special characters.
Amongst those tags, a special tag removes newlines:
#[ becomes <
#] becomes >
#( becomes &
#) becomes ;
\n#-\n is deleted from the stream, and is used to delete newlines.
So, instead of directly writing xml tags, the nroff macro
produces writes those custom tags, which are later translated by
postxml. Our paragraph macro becomes:
.de PP
. if d xml-block \{\
. \" tag to remove unwanted newlines
#-
. \" closing xml tag
\\*[xml-block]
. \}
. ds xml-block #[/pp#]
. \" opening xml tag
#[pp]#
. \" tag to remove unwanted newlines
#-
..
A preprocessor, prexml, escapes the possible presence of those
tags in the user document. The troffxml archive, avaible on
(http://utroff.org) provides prexml, postxml, and a two xsl
stylesheet to produce html and fodt (flat open document) files,
and Utmac provides the macro ux for that purpose. So, the command
to produce xml documents from a troff source is:
prexml < f.tr | nroff -Tlocale -mux | postxml > f.xml
xsltproc utohtml.xsl f.xml > f.html
xsltproc utofodt.xsl f.xml > f.fodt
Since I believe you want to have a look at the result, you will
find, joined to this mail, its xml, html, and fodt versions as
produced by this system (which reveals the fodt code block needs
some more work...).
On my next mail about Utmac, I will present you some goodies.
Kind Regards,
Pierre-Jean
xml.xml
Description: XML document
http://www.w3.org/1999/xlink";
xmlns:dc="http://purl.org/dc/elements/1.1/";
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0"
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0&quo
Re: [groff] [UTROFF] Troff and xml
For some reason, the html file was not joined, here it is... Pierre-Jean
Re: [groff] [UTROFF] Troff and xml
Steffen Nurpmeso wrote: > Pierre-Jean wrote: > |For some reason, the html file was not joined, here it is... > > No it is not. Maybe your mailer is the cause.. Or the used > version! It seems to be removed by the mailing list server, since I received it on my self sent mail. > But interesting all that. That would have been my idea for going > HTML too, doing that in all of the macros which shall be usable, > but i never really hatched on this in practice yet. There are so many things to do, and so few time! Kind Regards, Pierre-Jean.
Re: [groff] [UTROFF] Troff and xml
Ralph Corderoy wrote:
> > It seems to be removed by the mailing list server
>
> Yes, I expect Mailman has been configured to strip text/html parts.
> Just include it in the plain/text part of your email? Or have your MUA
> send it as a text/plain part since it's the HTML we want to see, not the
> rendering of it.
Here it is, thank you Ralph!
Pierre-Jean.
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>Utroff
Hello alls,
Resuming my little sery of articles, I am explaining today
how Utmac is linked to the XML world.
Troff and Xml
We all have in mind the various attempts to produce XML
files from a troff document: some aim to be universal, and,
dealing with the raw troff requests, can only ouptut non
semantic html with hardcoded styles, while others, dedicated
to a particular macro, fail to consider the raw troff
requests the user may need in his document (cf. the source
of ms2html, in which the author comments he is implementing
more and more raw troff requests)
XML files are nothing else but plain text files with
semantic informations. On the other side, a troff document
contains structured information which gets its meaning
within the context of a macro. When we think at it, we have
yet a tool which interprets a troff source within the
context of a macro to produce plain text files: nroff.
Could we use nroff to produce xml files ? I tried, and it
appears that solution works well.
The idea is simple: one only has to write a macro file,
which interprets all the interface macros (paragraph,
headers...), to add XML tags to the output file. For
example, here is a simple macro to produce XML paragraphs
and headings:
.de PP
. \" first, we close the previous
block
. \" by printing its recorded
tag
. if d xml-block \\*[xml-block]
. \" Secondly, we define the
closing tag for the block
. ds xml-block </p>
. \" and last, we print the
openning tag.
<p>
..
.de H1
. if d xml-block \\*[xml-block]
. rm xml-block
<h1>\\$*</h1>
..
Nroff has to be configured to produce a correct xml files:
we do not want hyphen, lines don’t need to be adjusted, and,
the page length has to be defined correctly.
.\" page length is one line
.pl 1v
.ll 75
.\" don’t adjust nor hyphenates
.na
.nh
.\" Ending macro is doc:end
.em doc:end
.\" Print header
<?xml version="1.0" encoding="UTF-8"?>
.\" Open the root tag
<utmac>
.de doc:end
. \" doc:end needs some more space
to output text
. pl \\n(nlu+3v
. \" close the previous
block
. if d xml-block \\*[xml-block]
. \" Close the root tag.
</utmac>
. \" set correct page length
. pl \\n(nlu
..
Since the fonts are hierarchical and defined as strings in
Utmac, they are easy to implement as well.
.ds font-bold0 </B>
.ds font-bold1 <B>
.nr f-b
0
.ds B
\ER’f-b 1-\En[f-b]’\E*[font-bold\En[f-b]]
The only real problem of using nroff to produce xml
documents is that — along with troff — it is not easy to
deal with automatically inserted spaces. I tried to use
.chop and \c, but without reliable results. To solve that
problem and escape the possible restricted characters a user
may insert in his document (’<’, ’>’, and
’&’), I wrote a small post-processor –
postxml –, which translates a custom set of tags
to xml special characters. Amongst those tags, a special tag
removes newlines:
#[ becomes <
#] becomes >
#( becomes &
#) becomes ;
\n#-\n is deleted from the
stream, and is used to delete newlines.
So, instead of directly writing xml tags, the nroff macro
produces writes those custom tags, which are later
translated by postxml. Our paragraph macro becomes:
.de PP
. if d xml-block \{\
. \" tag to remove unwanted
newlines
#-
. \" closing xml tag
\\*[xml-block]
. \}
. ds xml-block #[/pp#]
. \" opening xml tag
#[pp]
. \" tag to remove unwanted
newlines
#-
..
A preprocessor, prexml, escapes the possible presence of
those tags in the user document. The troffxml archive,
avaible on
http://utroff.org ,">
provides prexml, postxml, and a two xsl stylesheet to
produce html and fodt (flat open document) files, and Utmac
provides the macro ux for that purpose. So, the command to
produce xml documents from a troff source is:
prexml < f.tr | nroff
-Tlocale -mux | postxml > f.xml
xsltproc utohtml.xsl f.xml > f.html
xsltproc utofodt.xsl f.xml > f.fodt
Since I believe you want to have a look at the result, you
will find, joined to this mail, its xml, html, and fodt
versions as produced by this system (which reveals the fodt
code block needs some more work...).
On my next mail about Utmac, I will present you some
goodies.
Kind Regards,
Pierre-Jean
[groff] [UTROFF] references, summary, index
Hello alls, On my previous mail, I said I was willing to discuss about some of the goodies offered with Utmac. But as I had a look at those things, I realized that while some are effectively goodies only useful on some rare occasions, the others are things which are filling basic needs. So, I’ll keep the term « goodies » for my next mail, and will talk today about references, summaries, and indexes. # References Concerning references, there are habbits and standarts to follow. The habbits are well known: if the same reference is cited several time in a row, the macro should only write "ibid." followed by the possible differences. If the reference has been cited yet in another page, the macro should write "op. cit. p. XX". The standart is less known: it is the iso-690 one, which define mandatory fields and their order. In Utmac, u-ref respects both those habbits and the standart. It also indexes each of the referenced title. A modified version of refer <http://utroff.org/man/refer.html> sorts the bibliography list respecting the iso-690 standart. That version of refer also uses strings to define fonts, instead of hardcoded fake small caps. # Summaries --- In utmac, summaries are all implemented within a macro (u-sum.tmac). Compared to solutions which rely on moving a pdf page from the end to the beginning of the document, this solution has the advantage to allow the possibility to write summaries without breaking the flow of the text: within a margin, between a heading and the first paragraph, etc. The drawback is that two to three passes of the troff are needed to adjust the page numbers. The summary is written to a file using .sy and sourced on the next pass with .so. Internally, the hierarchical position of each line of the summary is recorded, to may print summaries of sub-sections. .\" The summary string .ds sum-list . .de sum:record . \" Record the summary in a string . \" This macro called by each heading . \" The aim of the sum-level string is to define the hierarchical . \" position of the heading : /, /1/, /1/1/, /1/2/, /1/3/, /2/, etc. . as sum-list @@@sum :print \\*[sum-level] \\n% "\\*[head-text]" .. .am doc:end . \" Write the summary to a file (added to the ending macro) . \" the sed command creates troff macros from the summary string . \" the iconv command gets around a bug in Heirloom Troff . sy echo \\*[sum-list] | sed -e "s/@@@/n./g" | iconv -f latin1 -t utf8 > /tmp/summary.tr .. .de S3 . \" user macro to print a summary of level 3 headings . \" The aim of the sum-toprint string is to select only . \" the headings of the actual section. . ds sum-toprint /\\n[head-1]/\\n[head-2]/ . \" Source the summary . so /tmp/summary.tr .. .de sum:print . \" Only print the desired summary lines . if "\\$1"\\*[sum-toprint]" \\$3\t\\$2 .. # Index --- To create indexes of titles, words, and everything else, Utmac also uses the .sy and .so requests. But to format the indexes, it calls an external script: idx. .sy echo "\\*[idx-list]" | sed -e "s/@@@/n/g" | iconv -f latin1 -t utf8 > \\*[idx-file] .sy idx -d \\*[idx-file] > \\*[idx-file].b .so \\*[idx-file].b .sy rm \\*[idx-file] \\*[idx-file].b The idx script can be used to help people create summaries of paper books. The procedure is explained on the manual of idx <http://utroff.org/man/idx.html>. On my next, and hopefully last, mail about Utmac, I will effectively discuss about goodies. Kind Regards, Pierre-Jean.
[groff] [UTROFF] conclusion
Hello alls, For my last mail about Utmac, it appears that all I wanted to say can be summarized in a few lines: - Utmac comes with two files – u-en and u-fr – which are used to localize strings and typographic details. - Utmac populates the internal pdf table of contents, and creates internal links everywhere that makes sense. - Thanks to nroff, Utmac documents can also be exported to markdown, plain text, and man formats. That makes a lot of features, much more than I use on a daily life. Yet, I needed each of them at least once, and it is when I realized the work I had done to fulfill my needs that I thought about publishing it. The publication itself forced me to organize things and write documentation, which is great. It is very unlikely people use Utmac as is, but I believe its existence makes sense nonetheless as a proof of concept: Troff can fulfill 21th century needs. Kind Regards, Pierre-Jean.
Re: [groff] A macro package for lists in TROFF
Stephanie Björk wrote: > The project is here: https://github.com/katt64/troff-lists (bul.tmac is the > beating heart of it all) I had a look, and it is very well done. Thank you for sharing it! I also tested it with heirloom troff, and it seems to work flawlessly. May I suggest you to choose a license? Because in most jurisdiction, the absence of license is far more restricting than any license you could choose: the default copyright is applied, and would'nt even allow us to copy the sources. Kind Regards, Pierre-Jean.
Re: [groff] [UTROFF] conclusion
Hello Gour, Gour wrote: > I just wonder how Troff/Heirloom does compare with Mom package when it comes > to > quality typesetting (aka 21th century needs)? Mom is a macro set, while Troff/Heirloom is the interpreter of the macro set, so, we can't compare things like this. A proper comparision would be between Groff, Heirloom Troff, and Neatroff on one side, and Mom, Utmac, ms, me, on the other side. 1) For typographic purposes (and for typographic purposes only), Heirloom Troff and Neatroff are, in my opinion, far better than Groff, because they adjust paragraphs "at once". Comparing between Neatroff and Heirloom would need a set of examples, but at a first glance, I'd say that while on the paper Heirloom has some more features (micro-typography), its adjustment algoritm is also bugged, and I would tend to favor Neatroff. 2) With some hacks if not out of the box, Mom probably works well enough on Neatroff to take advantage of its features. It would need much more work to port it on Heirloom Troff because of the needed \P line trap I wrote about on one of my mails. 3) If you want to compare macros for typographic purpose only, I would advise you to look at the vertical alignment, ie, headings should not break the vertical grid. I know that Utmac takes care of it (if the alignment is broken, it is a bug), I don't know for Mom, but since Peter Schafter has a taste for typography, I believe he did take care about that too. The other typographic things (such as fonts), will be more easily adjusted if they don't fit your needs. 4) All this being said, there are many other things than typography that you should consider when choosing a macro set and a troff intepreter: long term maintenance, easiness to use and install, performances of the pre- and post- processors, configurability, layout, syntax, and a myriad of other things. All those things considered the couple groff/mom is a very solid choice. Kind Regards, Pierre-Jean.
Re: [groff] [UTROFF] references, summary, index
Hello James and Ralph, Ralph Corderoy wrote: > > > It may be better to use `.write', if other troffs have that, rather > > > than allow the local echo(1) to perhaps interpret sum-list's > > > content? > ... > > sy printf '%s\n' '\\*[sum-list]' | sed -e "s/@@@/n./g" > > > > would eliminate that issue. > > But still leave open the original problem. :-) > > $ cat sy.tr > .ds sum-list foo';'date > .sy exec >&2; printf '%s\\n' '\*[sum-list]' | od -c > $ > $ nroff -U foo > 000 W e d 6 D e c 1 4 : 4 7 > 020 : 3 1 G M T 2 0 1 7 \n > 035 > $ That's a bit annoying: I did not use .write because it is not implemented in neatroff... But I'm underdestanding I should better use it, and reserve the possible issue of .sy to neatroff only. Thank you, Pierre-Jean.
Re: [groff] [UTROFF] conclusion
Ralph Corderoy writes: > > For my last mail about Utmac > Thanks, they've been interesting, and more digestible drip-fed over the > days than one long email. I'm glad to read that! Cheers, Pierre-Jean.
Re: [groff] A macro package for lists in TROFF
Stephanie Björk wrote:
> However, Troff's ability to take values of a numerical
> register and use it as a name to another register (.nr my_\na_\nb)
> intrigues me very much.
I do not know if that "feature" was an intentional design or an
accident, and I do not know either if it is considered a good practice
or an abuse to take advantage of it, but I find it very useful. It
does not only work with number registers, but also with strings and,
in fact, everything.
I'm using it to write macros on the fly (".de macro:\nx"), and avoid
the if/else tests (".macro\ni", ".macro\nj").
> I'm not exactly sure how I found this ability, but I think I found it by
> accident.
I have the feeling I found it by accident too. Or maybe did I saw it
in the macro ms...
Kind Regards,
Pierre-Jean.
Re: [groff] [UTROFF] references, summary, index
Doug McIlroy wrote: > How does Utroff deal with even simple changes of line length, e.g. for > flowing text around an image as in the following trivial example. > A robust version that allows for intervening page or paragraph > breaks would pose even more difficulty. > > .wh \n[nl]+3 `in +1.5i > .wh \n[nl]+3+2i `in -1.5i > Paragraph text here ... I must first admit that, unfortunately, Utmac only has a very basic picture management, since I never needed it myself. So, Utmac does not deal at all with that situation. And indeed, that example code would not work in Heirloom Troff. Heirloom nonetheless provides the .pshape request to define the shape of a paragraph adjusted "at once". Gunnar Ritter used that request to draw a paragraph shaped like a circle. But when it comes to real life situations, traps and line length adjustments are much more easy. I tried to use the request to insert short notes within the body of a pragraph (the text flowing around the note), but failed, and abandonned. That is the kind of difficulty which is convincing me to give neatroff a real try, and compare it with heirloom. I like the resulting typographic grey of neatroff, but even if I would prefer heirloom's one, I could be ready to switch to have a simpler interface to write macros, since apparently, Neatroff's implementation of the paragraph at once adjustment is much more transparent. > Unjustified text is becoming quite common these days, presumably > because the added shape of text helps the eye maintain vertical > sync. I personally prefer it. That seems to be an anglo-saxon habbit, since all examples I can think about are architectural books written in english, or very short lines. As a result, I did not give much attention to left align paragraphs. > On unjustified text, fmt (which uses an algorithm purported to be > like Knuth-Plass) does a worse job than nroff. Its scoring method > has a significant chance of making a paragraph less uniform > than nroff--perhaps because it isn't sufficiently "like > Knuth-Plass". But it also has a habit that seems intrinsic > to paragraphwise justification: each paragraph appears to > have its own distinct line length. How does Utroff address > this pitfall? My feeling is that thanks to hyphenation and variable size spaces, that pitfail would become much less visible, if visible at all, on a pdf produced by heirloom troff. If it remains visible, and since there's no "page at once" feature in heirloom, it could only be solved by manual adjustment of interword space (.ss, .minss), and maybe by adjusting lightly the size of the glyphes (.letadj), of the faulty paragraphs in a page. Kind regards, Pierre-Jean.
Re: [groff] A macro package for lists in TROFF
Hello alls, Ralph Corderoy wrote: > Today, m4(1) is still around from that era, along with troff, and is > worth examining. https://en.wikipedia.org/wiki/M4_(computer_language) > autoconf and sendmail still use it. Thank you for the link. I am discovering it is worth examining indeed. Pierre-Jean.
Re: [groff] [Neatroff] arabic typesetting
Hello, kaddour kardio wrote: > Hi i am quiet a newbie in utroff/neatroff typesetting systems, i use LaTeX > daily in my archlinux based laptop. > Do Farsi settings sufficient to typeset arabic texts( via init_fa), or > should i create a init_ar config file?. I can't help much about neatroff, but I believe I should clarify this: I wrote on this list that I aimed to port utroff to neatroff, but that's a long term project, and currently, utroff macros can't be used with neatroff. And unfortunately, I don't know neatroff and arabic languages well enough to may answer easily your question. But as far as I understand, you're refering to the 'make init_fa' target of the neatroff_make package. This target installs a farsi font and the farsi/arabic shaping pre-processor for neatroff. So, to typeset arabic texts, you probably also need to install manually a proper arabic font. To do so, put the font in the 'font' subdirectory, and run './fonts.sh' from there. If you don't receive more answer from this list, maybe could you write directly to Ali Gholami Rudi? His email is indicated at the bottom of his web site: http://litcave.rudi.ir Kind Regards, Pierre-Jean.
Re: [groff] Macros in their own package ...
Hello alls, I am intervening a bit late, but I believe I can clarify some little things about *roff families: > Larry Kollar wrote: > > John Gardner wrote: > > 1. *GNU Troff <https://www.gnu.org/software/groff/>* (~1989/1990 ‒ > > present) > > 2. mandoc <http://mandoc.bsd.lv> *[1]* (2008 ‒ present) > > 3. *Heirloom Doctools <https://github.com/n-t-roff/heirloom-doctools>* > >(? ‒ present) Heirloom doctools began as a fork of Solaris troff. And there are actually two repositories of the heirloom doctools: - the original Gunnar Ritter's (now abandonned) version: - Karsten Kunze's version, which fixes some bugs of Ritter's version: <https://github.com/n-t-roff/heirloom-doctools>. It seems a bit abandonned too. > > 4. *DWB 3.3 <https://github.com/n-t-roff/DWB3.3>* ( ‒ 1993ish) > > 5. *Solaris 10 ditroff <https://github.com/n-t-roff/Solaris10-ditroff>* > >(1980s ‒ ?) Solaris troff is where heirloom comes from. It's official repository is on the solaris project, the github/n-t-roof being only a fork. > > 6. *Plan9 Troff <https://github.com/n-t-roff/Plan9_troff> *( ‒ > > present) > > 7. 9front Troff <https://github.com/n-t-roff/9front_troff> ( ‒ ) Then again, these two have their official sources tree on respectively plan9 and 9front repositories, and I bet they are regularly synchronised together. > > 8. Utroff <http://utroff.org> (Which I know nothing about) The name is probably confusing, but Utroff does not share *roff, only macros and utilities. They are made to be used with heirloom doctools, and I advise to use their most recent version (Kunze's, on github). > You’re missing neatroff — https://github.com/aligrudi/neatroff > > I think both Neatroff and Heirloom are based on Plan9, FWIW. As far as I know, Neatroff is not based on any other troff. It has been written from scratch. Kind regards, Pierre-Jean.
Re: [Groff] setting PD with ms macros has no apparent effect
rumexCrispus wrote: > > I wrote the following expecting the gap between paragraphs to increase from > .3v to .6v. Can anyone suggest what I have missed. I am invoking it as: > groff -ms abc.groff -X > > test > .br > test2 > .br > PD \n[PD] > .br > .nr PD .6v \" ( \n[PD] * 4 ) > .br > PD \n[PD] > .LP > .bp > .br > test > .br > test2 > .br > > -- > View this message in context: > http://old.nabble.com/setting-PD-with-ms-macros-has-no-apparent-effect-tp28687363p28687363.html > Sent from the Groff - General mailing list archive at Nabble.com. > Hello, As far as I understand groff: The PD number register is used by the paragraphs macro of ms (PP, LP, QP, XP and probably IP). The .br operator break lines, but is not what ms consider as a new paragraph. PP is a paragraph style, .br is only a new line. In your test, you should replace .br by one of the paragraph macro. Pierre-Jean.
[Groff] .rd request
Hello alls, I am trying to use the .rd request but all my efforts were in vain. I've tried, without result, the example given here: http://www.gnu.org/software/groff/manual/html_node/I_002fO.html#I_002fO (I've also tried without .nx and .ex requests) I've tried several commands, with or without U and s arguments: cat bar | groff foo >foo.ps groff foo >foo.ps foo.ps Could someone give me another short example or some explanations? Thanks a lot! Pierre-Jean
Re: [Groff] .rd request
Ralph Corderoy wrote: > > Hi Pierre-Jean, > > > Could someone give me another short example or some explanations? > > $ cat main.tr > A. > .rd ignored foo bar > B. > .rd > C. > .m > D. > $ cat data > We have `\$1' and `\$2'. > And another line, followed by a blank line... > > ...before the next lot of input. > .de m > A macro. > .. > $ nroff main.tr A. We have ‘foo’ and ‘bar’. And another line, followed by a > blank line... B. C. A macro. D. > > $ > > Cheers, > Ralph. > Thanks a lot for this example, Ralph. But I can't reproduce it: $ nroff main.tr
Re: [Groff] .rd request
Ralph Corderoy wrote: > > printf 'foo\n\n' | nroff <(printf 'a\n.rd\nb\n') | grep . > > produces "a foo b". A friend's tried that on his ArchLinux and it also > works. Another friend has tried on OpenBSD and it works, but on > > Fedora, version 1.18.1.4 > > he gets "a b" which suggests .rd has the same problem for him there as > it has for you. Perhaps Fedora and ArchLinux have a patch in common for > some versions? Hello, thanks for your answers, and thanks to your friends too. Well, as on Fedora I get "a b". I've looked at the arch packages, it doesn't contain any patches, just a site.tmac for man and mdoc. Here is the pkgbuild: http://repos.archlinux.org/wsvn/packages/groff/repos/core-i686/PKGBUILD So, I need more investigation, looking at my own installation. I'm gonna do some tests and research and reply if I find something. One more thanks for your help.
Re: [Groff] .rd request
Hello, With your help, Ralf, and the last command line you've given, I've discovered that my problem came from .lf request added by preconv: * My bashrc was containing GROFF_ENCODING="UTF-8" * I thought that commenting this line and sourcing bashrc would remove it, but not... Fortunately things are working better now, Thanks a lot! The last problem is that if I want to use preconv and .rd request, the command line is quite not handy to write: $ echo -e "élégante" | preconv -r | groff -Tutf8 \ <(echo -e "Gantée, elle est\n.rd" | preconv -r ) Is it possible to pass the preconv "-r" option to groff? Pierre-Jean.
Re: [Groff] opentype and postscript fonts
Werner LEMBERG wrote: > I suggest to try heirloom troff which supports OpenType fonts > natively. Otherwise... The case of heirloom troff is quite strange: - It has some advantages: OpenType font support, and Knuth's algorythm for paragraph adjustment... - It has most of the groff fonctionnality (utf8 support, long name macros...) - It is frequently advised here. - It's onliest - minor, in my opinion - default is the usage of pipes instead of command line arguments. - But everybody seems to prefer groff... And me too since it is actively developped. I've got a lot of question concerning this situation: - Which are the defaults of heirloom troff? - Why not integrating heirloom troff advantages inside groff? > ... I see this in > > http://www.lcdf.org/type/t1reencode.1.html : > > This series of commands, which use cfftot1(1) and otftotfm(1) as > well as t1reencode itself, generate a version of Warnock Pro > Regular with old-style figures in the slots for numbers (because > of otftotfm’s -fonum option). The new font will be called > WarnockPro-RegularOsF. > > otftotfm -fonum WarnockPro-Regular.otf \ >--output-encoding /tmp/osf.enc > cfftot1 WarnockPro-Regular.otf | t1reencode -e /tmp/osf.enc \ > -n WarnockPro-RegularOsF -N "Warnock Pro Regular OsF" \ > -o WarnoProRegOsF.pfb > > It seems to me that this is exactly what you need. Thanks for showing me that page, after some hours of tests with otftotfm, I had finally thought this tool was only usefull for latex, and didn't look at t1reencode man page. But the solution explained here doesn't work for Groff. I've tried to make a font with small caps, using the "-fsmcp" option. With fontforge, I've looked at the pfd file: - It has got small caps and normal letters. - The small caps are named "a.smcp" where the normals letters are named "a". - The small-caps unicode code is "U+", where the normal letter have their real unicode name, for example "U+0061" for "a". - The onliest difference with a regular pfb file is that the small caps are placed where the normal letters are usually placed, ie in "97 0x61" for a.smcp. But, this onliest change is not efficient. Based on that pfa file, I've made an afm file with "t1rawafm", made a roff font with afmtodit, and tried it. Normal letters are used but not small caps... So, as far as I understand (but honestly, I don't understand anything here) it seems that latex look at the place of the glyph in the font, where groff look at his name or at his code: the solution explained here is probably usefull for latex, but not for groff... Am I missing something? Should I ask help to the maintainer of lcdf-typetools? Thanks a lot for your help! Pierre-Jean
Re: [Groff] opentype and postscript fonts
Werner LEMBERG wrote: > This is not true; Gunnar is actively maintaining heirloom troff. > ... > > - Which are the defaults of heirloom troff? > This question is too vague. IIRC, Gunnar is reading this list (it's > essentially the only list for troff and friends), so he may answer. > ... > > - Why not integrating heirloom troff advantages inside groff? > > Patches are highly welcomed. I simply have not enough time to do that > by myself. It makes me feel uncomfortable to think I could have deprecated your both work. It was not my intention. I'm a fan of Mr Ritter's work: I've discovered *roff in the heirloom web page (before that day I thought it was only a manpage viewer), I'm using its mailx everyday, and I generaly think that the heirloom project is one of the most beautifull opensource project: It's not only a technical project, but also an aesthetic one. Since that discovery (only a few month ago) I'm using groff, mostly because of the sympathy of this mailing list, and the ability to meet it's maintainers here. You give to the old *roff the strength of a young project. > [...] > > > But the solution explained here doesn't work for Groff. I've tried > > to make a font with small caps, using the "-fsmcp" option. With > > fontforge, I've looked at the pfd file: > > - It has got small caps and normal letters. > > - The small caps are named "a.smcp" where the normals letters are > > named "a". > > Here is the problem, I think. To use `a.smcp' instead of `a', you > have to make groff aware of that with code like this: > > .char a \[a.smcp] > .char b \[b.smcp] > ... > > assuming that after using the `afmtodit' program those glyph names are > in the groff font file. > Thanks, you're right. The groff font file is truncated: the name of the special letters (small caps, old style number...) is not mentionned, (replaced by ---) but they are present, and described in the entity name field. One can repair the groff font file using that sed expression (if first field is "---", it is replaced it by the fourth one): sed -i -e " s/---\t\([^\t]*\)\t\([^\t]*\)\t\([^\t]*\)\t\(.*\)/\4\t\1\t\2\t\3\t\4/" \ groff_font_file Then we can use \[glyph_name] I'll make some tests and post a complete "how-to use opentype fonts" on the list. Thanks a lot! Pierre-Jean.
Re: [Groff] opentype and postscript fonts
Orelse, write it correctly.
case ${#NAME} in
0) echo -n ". \\\"" >> begin
echo -n ". \\\"" >> end
NAME="$GLYPH" ;;
1) NAME="$NAME" ;;
*) NAME="\\[$NAME]";;
esac
if [ "$NAME" = "\\" ]; then NAME="\\[\\]"; fi
echo ". char $NAME \\[$GLYPH.$FEATURE]" >> begin
echo ". rchar $NAME" >> end
done
echo ".." >> begin
echo ".." >> end
cat begin >> $FONT.tmp.tmac
cat end >> $FONT.tmp.tmac
rm begin
rm end
DONE="$DONE $FEATURE"
fi
done
# build the macro file
echo ".ig
$FONT.tmac
tmac solution to use $FONT
Should be edited by hand.
List of features:
$DONE
.." >> $FONT.tmac
cat $FONT.tmp.tmac >> $FONT.tmac
rm $FONT.tmp.tmac
# build the test file
echo ".do mso $(pwd)/$FONT.tmac
.tl ''Test of $FONT and $FONT.tmac''
.sp 1
.de TEST
.fam $FONT
.while n[.\$] \\{\\
\&\$1:
.br
.\$1
Portez ce vieux whisky au juge blond qui fume.
\\['e] \\[\`e] \\[~n] \\[ss] \\[oe] fi fl ff ct
.br
PORTEZ CE VIEUX WHISKY AU JUGE BLOND QUI FUME.
\\['E] \\[\`E] \\[~N] \\[OE] FI FL FF CT
.br
1234567890. .,;:?! §$@& ()[]{} ~#|-_ \\[Fo]\\[Fc]\"\'
\\[Eu]\\[Ye]\\[Po]\\[ct]\\[Fn]
.S_\$1
.sp 1
. shift
.\}
..
.TEST$DONE" >> testfile
exit 0
###
7) Copy the script in a file named font2macro. font2macro
need two argument: the name of the font (here it is "font")
and the name of the subfont (here it is "R"). Launch it, wait
a few, and test the new macro file:
$ chmod u+x ./font2macro
$ ./font2macro fontR
$ groff testfile > test.ps
8) You should manually edit the macro file "font.tmac" to give
a name to unnamed glyphs, and copy it in your tmac directory:
$ cp font.tmac $GROFF_TMAC_PATH/
9) Clean your dir:
$ rm fontR
$ rm font.afm
$ rm font.pfa
$ rm font.tmac
$ rm test.ps
$ rm lcdf-typetools*.tar.gz
$ cd lcdf-typetools*
$ make uninstall
$ cd ../
$ rm -rf lcdf-typetools*
10) Use the features of your font this way:
.do mso font.tmac
.smcp
My text in small caps.
.S_smcp
My text in normal caps.
Enjoy!
Pierre-Jean.
Re: [Groff] opentype and postscript fonts
Werner LEMBERG wrote: > > 1) OpenType font format is just an encapsulation of TrueType fonts > > or PostScript fonts. > > This is a exaggerating simplification, but I think you are aware of > that fact. I'm not aware about font formats... And so, I've got a last question: The standart AR macro contain information about kerning. Should these informations be manually added after conversion from .otf to groff font, or are they part of the .pfa font? > Well, a real free font family is, for example, Linux Libertine: > > linuxlibertine.sf.net > It has more than 2400 glyphs and many glyph variants. Very nice font! My script works as expected with it. But, since it only deal with variants glyphs (named glyph.variation), a lot of things must be manually done: looking at the glyphs in the font, and building handy macro to access them easilly. Pierre-Jean.
Re: [Groff] refer help
Peter Schaffter wrote: > Still not happy about refer not having a mechanism for dealing with > multiple works by the same author, but it's way beyond my expertise > to fix that. > Hello, I've got a macro that take care of that: Isobib.tmac. It has been made to respect the iso-690-2 bibliography standart, that I have to follow in France. The macro also replace some fields of the reference by "Idem." and "op. cit. p. xx" when needed, and build an index of references. I don't know how far away it is to MLA, but it should be easy to adapt. The onliest real problem is that I made it for the ms macro, and not for the mom macro, but at the end of the file, there is a section called "USE STANDART GROFF MACRO" which can be modified for that. I had written my master II thesis with it a few month ago, and the result was quite good. I've made a lot of changes since that moment, and haven't fully tested it after that, so there might have regressions. It is based on the refer section from the ms macro by James Clark, is licensed under gplv3, and has got a manual page and an example file. I would have like to publish it somewhere (but where?) in a few weeks (after some more tests and probably some fixes), but since it could help now, here it is (if the mailing list accept attachments). Comments and bugs are welcome. Pierre-Jean. isobib.tgz Description: Binary data
Re: [Groff] opentype and postscript fonts
Werner LEMBERG wrote: > > The standart AR macro > > Macro? You mean groff font file, right? Yes, of course. > BUT: You can use FontForge to load any font, then converting it to a > Type1 font and an AFM file. I just tried it for `Linux Biolinum' > (from the Libertine family): The AFM file has a whopping size of > 2.6MByte, with 2479 glyph metrics and 109131 kernpairs... You're right, it's astonishing. I think that I'm gonna use the Libertine font for some time to learn how to deal with all these addons, and to make comparisons with our usual fonts. So, fontforge produce better results than lcdf-typetools here. Thanks for your help and for the link to the Libertine font. Pierre-Jean.
Re: [Groff] refer help
Peter Schaffter wrote: > Thanks. Isobib gave me some ideas that let me come up with a clean > solution to the idem (multiple works by the same author) problem in > mom. I'm glad of that. > I'm busy with mom right now, but I'd be happy to proofread and > correct your README and manpage. I'd be proud of that. But there's probably more work to do in that proofread that you can imagine. Pierre-Jean.
Re: [Groff] Groff and ePub?
"brian m. carlson" wrote: > On Fri, Dec 17, 2010 at 04:49:43PM -0500, Timothy Groves wrote: > > Has anyone come up with filters, macros, etc., to produce an ePub > > file from groff source? > > Since ePub is basically XHTML in a zip file, you could create one with > -Txhtml. The problem with using groff here is that the text has to be > reflowable, and groff doesn't do that very well. > I've not tested them, but I know that there are a few tools that produce html output from *roff source code without using roff, and so, probably without fixing the content of each line, nor adding spaces to justify them: - ManServer for document using the man macro format: http://www.squarebox.co.uk/users/rolf/download/manServer.shtml - ms2html for documents using the ms macro format: http://hpux.connect.org.uk/hppd/hpux/Text/ms2html-1.2/ They could probably be usefull before using an html to epub tool, One such tool, simply named html2epub is for example given with Calibre: http://calibre-ebook.com/about Please, send your solution on the list if you find something usefull. Pierre-Jean.
Re: [Groff] groff.texinfo - section 5.21 - sentence difficult to understand
Ralph Graulich wrote: > "The optional second argument to de changes this to a macro to ‘.end’." > > For me this sentence is difficult to understand, although the meaning is > obvious. It was the same thing for me, I couldn't exactly understand this until I saw examples in om.tmac. But I'm not a native english speaker.
Re: [Groff] groff.texinfo - section 5.21 - sentence difficult to understand
Werner LEMBERG wrote: > >>"The optional second argument to de changes this to a macro to > >> ‘.end’." > >> > Any improvement in the wording is highly welcomed. It's quite not easy for me, but let's try this: "If a second argument is given to de (for exemple .de name end), the two dots must (can?) be replaced by this argument (.end in our example)." Or this: "The optional second argument to de define a replacement (substitution?) for the two dots." Pierre-Jean.
Re: [Groff] gropdf and pdfroff
Deri James wrote: > Another good programmer's rule says that the best place to do something is > "as > soon as you can". Which places it in the domain of the document creator > (gropdf). It's not really a radical new feature, more exposing an api to add > pages in a non-linear fashion. > Hello alls, My user opinion is that letting a postprocessor change the structure of a document is confusing. I don't like pdfroff for this reason. In my humble opinion, writing the table of content in the begining of a document is a job for a troff macro. I think that doing like that is doing things "as soon as you can" and also "doing one thing but doing it well". Troff has been made for that, why not using it in that case? This is a real question, and this question is the reason of my present mail: Is there any reason why troff would not be able to do that well? Cheers, Pierre-Jean.
Re: [Groff] gropdf and pdfroff
Mike Bianchi wrote: > What is missing is a Front Door that leads you gently into the Castle, teaches > you the way through the rooms, closets and pantries, so you can live > comfortably there with what is present. Then (and only then) should you be > led > down into the basement and shown how the electric, water, heat and sewage > utilities work. Finally you should go into the workshop and start building > your own mechanisms. > > I worry that *roff is an old technology loved only by old people. > It won't survive much longer if it isn't loved by people much younger than me. Well, I love *roff and I'm much younger than you since I was not born when you used it for the first time in the mid-1970s. ;) But, I don't think that *roff is difficult to use, since one accepts it's not a wysiwyg text processor. I also don't think that the troff language is difficult to learn - It seems to me that learning troff is something like learning bash. > What could I do about that? A tutorial with some exercises and examples could probably help new users to discover the troff language. It was missing to me when I learned troff, about one year ago. I hope to may write one - one day... Pierre-Jean.
Re: [Groff] holistic widow elimination
Hello Dave, hello alls, This is a quite interesting problem, so I hope my opinion may help. Dave Kemper wrote: > In professionally typeset novels, when a page is shortened by > one line > to eliminate a widow on the following page, bottom-line > alignment is > handled in one of two ways (at least, in the novels where I've > been able > to figure out their trick): > > - the leading (aka line spacing) of the page is increased > slightly, or > - the facing page (whether preceding or following) is also > shortened >by one line. I must add that in nicely typeset books, lines are always on the same place on the page. So if you look the page in transparency, you'll see that each line exactly recover the line of the other side of the page. This is needed when the paper is not perfectly opaque, but it's also a sign of well done job. That means that the vertical unit of a page is the line spacing, and if, for example, you add space before and after titles, you should take care that the width of the title plus the extra spaces is proportionnal to an amount of lines. So, dealing with orphans by changing the line spacing, is just a "not other choice" solution. You should prefer dealing with interword and interletter spaces. This is usually invisible. I'm personnaly doing this manually: I've just created two macros, ".min" and ".max", to minimize and maximize the width of a paragraph, and I put them where it's needed. One can also have this at the beginning of the paragraph macro, to inform the position of orphans: .nr orphan \\n[header-width]v+1v .if \\n(nl=\\n[orphan] .tm Orphan on page \\n%, \\n(.F line \\n(.c One solution to automatically deal with that in a multi-pass invocation of troff could use this trick: * first pass: for each paragraph, output the position on the page of the last word of the paragraph, the position on the line of the last word of the paragraph, and the number of lines of the paragraph. Also output page breaks caused by macros. * It is now possible to find the best paragraph that should be modified to avoid widows and orphans: it's a long one, with the last word near the beginning or the end of the line, with no page break between him and the widow. * A filter could calculate that and add '.min' or '.max' at the beginning of the paragraphs that need to be changed before the next pass. Cheers, Pierre-Jean.
Re: [Groff] holistic widow elimination
Werner LEMBERG wrote: > > > I remember reading (on this list) a PHD thesis by Han The Thanh (of > > pdfTEX fame) on micro typography, although the original is now a > > dead link I think I've found it here:- > > > > http://www.pragma-ade.com/pdftex/thesis.pdf > > > > Many thought provoking ideas. > > All his ideas (or rather, Hermann Zapf's ideas) have been implemented > in pdfTeX. However, this still doesn't solve the original issue > discussed in this thread. They are also implemented in Heirloom Troff, which I've used for the thesis of my wife, and which I'm still using for mine. These functions are really usefull to shorten or expand a paragraph by one line. For example, here are some macros that I use: .de typo . \" Default typography adjustment. . \" Each paragraph use this. . padj\" paragraph at once interword space adjustment. . \" to get a regular « gris typographique ». . \" An important thing in my opinion, the first . \" thing I've learned to see concerning typography. . ss 11 0 \" interword space . minss 10\" In heirloom troff interword space may be shrinked \" this command define the minimum interword space . letadj 99 99 15 101 101 \" adjust letter space and width . \" 1: shorten inter-letter space in % . \" 2: shorten letter width in % . \" 3: size from which a word may be expanded . \" 4: larger inter-letter space in % . \" 5: larger letter width in % . \" hanging characters at the end of a line. . \" to get a better visual alignment. . \" 1: font, 2: glyph, 3: hanging width . rhang R - 100 \(hy 100 \(en 100 \(em 100 » 150 . rhang I - 100 \(hy 100 \(en 100 \(em 100 » 150 . rhang B - 100 \(hy 100 \(en 100 \(em 100 » 150 . \" One can also use .lhang for the begining of a line. .. .de min . \" minimize paragraphs . \" Have to manually insert .min after .PP . \" Deal with .ss, .minss, and .letadj . padj . ss 10 0 . minss 9 . letadj 98 98 15 101 101 .. .de max . \" maximize paragraphs . padj . ss 12 0 . minss 11 . letadj 100 100 15 102 102 .. As we're talking about that, could we find some way to get someone working on an implementation of these ideas in groff, via a google summer of code, a call to donation, or something else? Would you be interested to work on that Werner? Is there a way to help? Last but not least, all this is not only a matter of taste, it's based on optic laws, and is a way of dealing with optic illusions. People who are making fonts are also dealing with optic illusions: to get a perfect visual alignment of glyphs, some must be higher than others. Cheers, Pierre-Jean.
Re: [Groff] holistic widow elimination
Dave Kemper wrote:
> There may be one in the -mpm macro package (thanks, Sverre and Ralph),
> but I haven't been able to get it working so far. I'm not sure if it's
> compatible with groff at all: its tmac file depends on something called
> tmac.srefs which doesn't exist in groff.
tmac.srefs seems to be part of the plan9 troff. It is the code of tmac.s
which format refer output. There is a modified version of it in Heirloom
troff, which I join to this mail.
It should be compatible with groff, if you use the corresponding pm macro,
which I also join.
Cheers,
Pierre-Jean.
.\"
.\" Changes by Gunnar Ritter, Freiburg i. Br., Germany, October 2005.
.\"
.\" Derived from Plan 9 v4 /sys/lib/tmac/tmac.srefs
.\"
.\" Copyright (C) 2003, Lucent Technologies Inc. and others.
.\" All Rights Reserved.
.\"
.\" Distributed under the terms of the Lucent Public License Version 1.02.
.\"
.\"
.\" Sccsid @(#)srefs1.4 (gritter) 10/30/05
.\"
.\" REFER macros citations
.de []
.][ \\$1
..
.de ][
.if \\$1>5 .tm Bad arg to []
.[\\$1
..
.if n .ds [. [
.if t .ds [. \s-2\v'-.4m'\f1
.if n .ds .] ]
.if t .ds .] \v'.4m'\s+2\fP
.if n .ds [o ""
.if n .ds [c ""
.if t .ds [o ``
.if t .ds [c ''
.\" the next lines deal with the problem of .[1] or [1].
.\" refer will write "linexxx\*(<.[1]\*(>.
.\" and either "<." or ">." should produce the .;
.\" similarly for ,
.if n .ds >. .
.if t .ds <. .
.if n .ds >, ,
.if t .ds <, ,
.de [5 \" tm style
.FS
.IP "\\*([F.\0"
.nr %T 2
\\*([A, \\f2\\*([T\\f1,
.ie \\n(TN \\*([M.
.el Bell Laboratories internal memorandum (\\*([D).
.RT
.FE
..
.de [0 \" other
.FS
.nr [: 0
.if !"\\*([F"" .IP "\\*([F.\0"
.if !"\\*([A"" \{.nr [: 1
\\*([A\c\}
.if !"\\*([T"" \{.if \\n([:>0 ,
.nr [: 1
\\f2\\*([T\\f1\c\}
.if !"\\*([O""\{.if \\n([:>0 ,
.nr [: 1
.if \\n([O>0 .nr [: 0
\\*([O\c
.if \\n([O>0 \& \c\}
.if !"\\*([D"" \{.if \\n([:>0 ,
.nr [: 1
\\*([D\c\}
.if \\n([:>0 \&.
.if !"\\*([%"" Cited p. \\*([%.
.RT
.FE
..
.de [1 \" journal article
.nr %T 1 \" title font
.FS
.if !"\\*([R"" .rm [C
.if !"\\*([F"" .IP "\\*([F.\0"
.if !"\\*([A"" \\*([A,
.if !"\\*([T"" \\*([o\\*([T,\\*([c
\\f2\\*([J\\f1\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([V"" .if n ,\& Vol.\&\c
.if !"\\*([V"" \& \\f3\\*([V\\f1\c
.if !"\\*([N"" (\\*([N)\c
.if !"\\*([P"" \{\
.ie \\n([P>0 , pp.\ \&\c
.el , p.\ \&\c
\\*([P\c\}
.if !"\\*([I"" .if "\\*([R"" , \\*([I\c
.if !"\\*([O"" .if \\n([O=0 , \\*([O\c
.if !"\\*([D"" \& (\\*([D)\c
\&.
.if !"\\*([O"" .if \\n([O>0 \\*([O
.if !"\\*([%"" Cited p. \\*([%.
.RT
.FE
..
.de [2 \" book
.FS
.nr %T 2
.if !"\\*([F"" .IP "\\*([F.\0"
.if !"\\*([A"" \\*([A,
.if !"\\*([T"" \\f2\\*([T,\\f1
\\*([I\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([D"" \& (\\*([D)\c
\&.
.if !"\\*([G"" Gov't. ordering no. \\*([G.
.if !"\\*([O"" \\*([O
.if !"\\*([%"" Cited p. \\*([%.
.RT
.FE
..
.de [4 \" report
.FS
.if !"\\*([F"" .IP "\\*([F.\0"
.nr %T 1
\\*([A, \\*([o\\*([T,\\*([c
\\*([R\c
.if !"\\*([G"" \& (\\*([G)\c
.if !"\\*([I"" , \\*([I\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([D"" \& (\\*([D)\c
\&.
.if !"\\*([O"" \\*([O
.if !"\\*([%"" Cited p. \\*([%.
.RT
.FE
..
.de [3 \" article in book
.FS
.nr %T 1
.if !"\\*([F"" .IP "\\*([F.\0"
.if !"\\*([A"" \\*([A,
.if !"\\*([T"" \\*([o\\*([T,\\*([c
.if !"\\*([P"" pp. \\*([P
in \\f2\\*([B\\f1\c
.if !"\\*([E"" , ed. \\*([E\c
.if !"\\*([I"" , \\*([I\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([D"" \& (\\*([D)\c
\&.
.if !"\\*([O"" \\*([O
.if !"\\*([%"" Cited p. \\*([%.
.RT
.FE
..
.de ]<
.[<
..
.de [<
.LP
.rm FS FE
..
.de [>
.]>
..
.de ]>
.sp
..
.de ]-
.[-
..
.de [-
.rm [V [P [A [T
.rm [N [C [B [O
.rm [R [I [E [D
.rm [G [%
..
.de ]]
.\"this is never executed and just uses up an end-of-file bug.
..
pm
Description: Binary data
Re: [Groff] Parsing specific section of man page
ridiculous_fish wrote: > Our intent is to produce a shell with less internal complexity, and far less > user-facing > complexity, than popular shells. > Hello, I suppose that you know the shell fish: It's doing what you want concerning completion of options. You could have a look at it. It has a lot of new features, and aim to give a better command line interface than other shells... It didn't convince me at all, but I'm happy to see that people are still interesting in improving command line interface.
Re: [Groff] Eric Raymond on groff and TeX
Steve Izma wrote: > I've made a lot of notes about this, and I promise that soon I > will try to document this and other issues that make XML to groff > processing tricky. Most of us would like to read this, it's a very intersting issue about troff. Please, inform the list when you've got a draft of this document. > That's exactly what you need to do, but it's not general-purpose > because each project that has a different DTD would require > rewriting the dictionary to include the inline tags for that DTD. > As far as I know, there's no conventional way of flagging inline > tags in DTDs or schemas. E.g., typical ways of tagging emphasis: > , , , , . This problem is, in my opinion, true for all xml-to-print software: you'll have to make typographical and layout choices, you'll have to choose how to render each specific tag, and this can't be done a priori for all the existing xml schemas. Making a distinction between inline and block elements is a little part of this work. Furthermore, the fact that the distinction between inline and block elements doesn't exist in xml is not only a problem for troff, but for most of the printers. The CSS style sheet *must* define if a tag is an inline or a block element to render properly an xhtml page - we usually forget this because most of the tags have a default definition. Cheers, Pierre-Jean.
[Groff] Troff to xml
Dear troffers, I'd like to share here some thoughts about the translation of a troff file to xml. This is not, in my opinion, a very difficult task, the problem is more that there's not one way to do that, and so no standart way, and so a lot of partial solutions. We know one of them: 'groff -T xhtml' ; some of us might know that plan9 shares 'htmlroff' ; we can also think at 'manserver', 'mstohtml' and such other tools that we can still find on the web. All these solutions have the same two problems: - they do not handle the mini-languages of the preprocessors, they usually build a picture of tables and equations instead. - they have choosen to include some layout information in the xml - which make an ugly xhtml. In one hand, there's not enougth information (data of tables, equations, pictures and references are lost), on the other hand, there's too much information (layout is usually not needed in an xml file). This strange use of xml is comprehensive when xml is restricted to xhtml. But the power of xml is its versatility, it's ability to be transformed. We should prefer a good xml file, even if it's not a known format and transform it using xslt than having an xml file specific to an application - html here, odt somewhere else. But what is more strange is that nobody seems to have think at the simpliest way to translate a troff file to an xml one: using nroff itself. Here is an example: .de PP \\*[END] .ds END .. Writing a macro to convert to xml is much more easy than writing a troff macro, as we don't need to handle layout. There's, of course, a lot of small problems doing things that way. One of them concern fonts written '\fX'. A pre-processor can transform them to '\*X', so that troff can replace these strings by some xml tag. One other problem concern the trailing newline, that might result in a not wanted space, for example after the in the macro hereinbefore. A simple post-processor could take care of this. One last problem concern the mini-languages. But it's not a hard task to write pre-processors that transfer them to xml. Groff eqn can produce MathML. I've made some test with the heirloom refer: it's easy to transform it's output to xml. A tbl to html might exist somewhere, even if I didn't find one. The major difficulty could be a 'pic to svg' tool. So, we could translate some file to xml using a nice command line: prexml file.tr | xrefer | eqn -T MathML | xtbl | xpic | \ nroff -mxml | postxml > file.xml Let's close this mail with a discussion concerning refer. Refer is the onliest pre-processor that I use. I use it always, I use troff because refer is one of the best tool to deal with references. How should we translate references? There's two solution: we can use troff to format the reference (insert 'idem.' if needed, delete some informations, add some punctuation, etc.), or we can decide that the xml file should be as neutral as possible, and use xml tools to do these transformations. Even if I don't know how to do use xslt, the second solution seems to be the correct one, as we don't loose information in the translation from troff to xml, and because we use the power of xml. It's not hard to patch refer to let it produce something like that: Author Title City Issuer Date And it's propably possible to use xslt to get something like this: Author, Title, City: issuer, date. I think that this way of transforming troff to xml is the easiest one and the correct one. It's a troff way, because end user can build it's own xml macro, but it's also the xml way, because it let xml do the most difficult thing, say use some standart (like odt). As a proof of concept, here is a macro to convert a subset of ms (SH, PP, QP, FS, FE and some fonts written as \*X) to flat odt. Use like this: groff -Tutf8 sxml f.tr > f.fodt open it with your office suite, and enjoy! Pierre-Jean. .\" subset of troff ms to flat odt (.fodt) .\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" .\" start xml file .de intro .\" office:document http://www.w3.org/1999/xlink"; xmlns:dc="http://purl.org/dc/elements/1.1/"; xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg\[u002D]compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc
Re: [Groff] Troff to xml
"Eric S. Raymond" wrote: > http://www.catb.org/~esr/doclifter/ You talked about doclifter a few weeks ago, and, sorry for that, but I thought it was not published - I don't exactly know why I had this idea... I should have say that I don't use ms nor other macro sets and need something to translate my troff files to xml ; but I'll maybe try to hack doclifter for my needs. Last but not least, I'm happy to learn about pic2plot, to convert pic to svg. Does someone know if there's something for tbl? Thanks, Pierre-Jean.
Re: [Groff] Macro packages
Hello, trebol wrote: > So maybe I’ll try ms, I > find it more simple (the groff_ms man page show me in a cou‐ > ple of lines all the basic things I want to do in a simple > way), and like Ralph suggests, extend it with my own macros > to fill my needs. That's the step I followed four years ago, and it seems to me it was a good choice. > I find groff awesome and I can’t believe > it fits in 10M. I feel all the system’s potential, so while > I’m learning I would like to know the experiences of users > writing science texts, novels, poetry and other works > using this packages, and the main problems they encoun‐ > tered. I'm actually writing my philosophy thesis with troff (heirloom troff), and before that, I've writen my master memory, the lessons I teach, and some articles with it. The onliest problem I encoutered was concerning the bibliography: I have to follow the ISO-690 standart, and the french typography. So, I've first written a macro to handle that whith ms. It was a nice way to learn both refer and troff internals. After that, I've decided to create my own macro set, whith the layout I wanted (marginals notes instead of footnotes). > This could help me to resolve my personal "TeX vs > Groff" advantages and disadvantages dilemma (And other peo‐ > ple reading the mailing list too). This has been discussed a lot here. It also have been discussed on plan9 mailing list. You could have a look at these discussion if you still need to be convinced. Know that there are at least four things to compare: Kertex (a Tex distribution that only contain Plain Tex), Latex, Groff and Heirloom Troff. Each one has advantages. In my opinion, the advantage of troff (and groff) is that it's easy to create and hack macro. The disadvantage is that the macro you need probably doesn't exist yet. Less is more... > Sorry for my English, and thanks to all. Sorry for mine ! Cheers, Pierre-Jean.
Re: [Groff] Macro packages
Anton Shterenlikht wrote: > Another factor is size. A modern latex > distribution, i.e. texlive is enormous. That's why some people are building the minimal Kertex distribution. They want Tex to be like Troff ! Pierre-Jean.
Re: [Groff] Macro Packages
Hello alls, "Grigoriy A. Sitkarev" wrote: > While there is one exceptional sociological and > psychological phenomena with groff/troff (as a part of Unix > culture), which is still a point to study. The groff mail‐ > ing list joins three generations of very interesting people: > ‘‘grandfathers’’, ‘‘fathers’’ and ‘‘sons’’. As an 80’s born > kid, I consider myself to be a ‘‘grandchild’’ of people like > Douglas McIlroy, in hope that they will accept us, the > youth, with this role. Moreover, these people come with > different background and they were involved in different > areas of the arts — literature, music, languages, program‐ > ming, mathematics and other. > > There must be something we do not completely understand and > value yet. And these aspects or what are not technical at > all. > > I hope to dig to the roots of this phenomena one day. You maybe know this article of Thomas Scoville: _The elements of style: Unix as litterature_, (http://theody.net/elements.html). This article might be a good starting point to understand who are the troffers and why they like troff. I believe that people who write texts feel at home with text interfaces. Not because they are more productive (how can we really mesure that?), but because a language interface is the natural way to manipulate texts. I think that troff is the way that the Unix philosophy of language as interface has meet text processing. This is well explained in the introduction of _Unix Text Processing_, which relates this strange moment of our recent history: tools made to develop software can be used to write texts, because they have been made to manipulate the language using the language itself. Cheers, Pierre-Jean.
[Groff] Vgrind and vfontedpr
Hello alls, You maybe remember that vgrind is an old pre-processor for troff that colorize source code. It's a shell script that call a C progamm named vfontedpr. I'm trying to understand what those names means. In french, to grind means « grincer » and « mouliner ». Does that mean that vgrind does a difficult job? It seems that vfontedpr has something to do with « font », since it adds font definition inside code. Does that mean that within vfontedpr, a programm ( « pr » ) is « fonted » ? Last but not least, what's the meaning of that « v » ? Is it for « virtual » ? As you can see, these questions are absolutely essentials. I hope that a good english speaker could explain me what does that mean. Cheers, Pierre-Jean.
Re: [Groff] Vgrind and vfontedpr
Meg McRoberts wrote: > So this makes this visual-font-edit-and-print, which seems to be more or less > what > it does. That is one of the longer command/program names from the days when > we > used ASCII characters to do online art ;-) That seems correct. Such a long name might be explained by the fact that vfontedpr is most often called by vgrind than by the user himself. Doug McIlroy wrote: > Hence the meaning of grind has been extended to refer to > long, slow, monotonous work. I suspect that's the intent > of "grind" in vgrind. You're probably right. In one of the source file (regexp.c), a comment explain the situation: "loop till expression string is exhausted (or at least pretty tired)". That's maybe why the manual page says: "grind nice listings of programms". Thanks for your explanations, Pierre-Jean.
Re: [Groff] new groff-filenames.7 (roff filename extensions)
Hello troffers, "Bernd Warken" wrote: > the filename extensions for files using the roff language are not > documented. As there are many of these, a kind of standard should be > implemented. I propose the following description as a man-page > "groff-filenames.7"0. It should go to groff/man/groff-filenames.man I think that documenting filename extensions is a good idea. People who discover troff today can't know which extension give to their troff files, since (except manual pages), none exist on their system. In such a documentation, the .tmac should be added for macros. It could also be said that in the original troff, and so in heirloom troff, macros are named "tmac.file". It should also be of interest to say something about freedesktop standart: it recognize *.tr, *.roff, *.t, *.me, *.ms, *.mm, and *.man. It also recognizes troff files if they begin by a comment (ie by .\" or '\" ). > .reffor files using the prefer preprocesor Since I've got a lot of refer files, I've added a text/x-refer mime type in my system. It recognizes the file if it has the extension .ref or if it begins by a %. Here follow the refer.xml file which add this mime type, and a simple makefile to install it. Most of the translation should be corrected. I also have got a set of icons for troff files, based on a famous icon theme. I can share them if wanted. Cheers, Pierre-Jean. refer.xml Description: XML document ROOT= MIMEDIR=$(ROOT)/usr/share/mime/packages/ MIMEPKG=$(MIMEDIR)/packages/ INSTALL=/bin/install UMD=/usr/bin/update-mime-database install: refer.xml $(INSTALL) -c refer.xml $(MIMEPKG)/refer.xml || exit ; $(UMD) $(MIMEDIR) uninstall: rm $(MIMEPKG)/refer.xml $(UMD) $(MIMEDIR)
Re: [Groff] new groff-filenames.7 (roff filename extensions)
Ralph Corderoy wrote: > > Since I've got a lot of refer files, I've added a text/x-refer mime > > type in my system. It recognizes the file if it has the extension .ref > > or if it begins by a %. > > Does that clash with PostScript recognition at all? PostScript files > often starting with a % as it's the comment character. > > %!PS-Adobe-1.0 No, it doesn't... but because of a bug in the refer.xml file that I hadn't notice ! I've fixed that now, thanks to you. Seeing your question, I also had a look at the file /usr/share/mime/packages/freedesktop.org.xml on which such expressions are defined, and it appears that a "%" as first character is used by a lot of files, but usually as part of more longer string -- that's the case of pdf, postcript, postcript fonts, and encapsulated postcript files. The exceptions are matlab and tex files, which can be recognized by a single "%" but with a very low priority of 10. Tex files are better defined, with a priority of 50, if the string "documentclass" begins at the second character. Matlab files are better defined, with a priority of 50, by the string "function" begining at the first character. To avoid most of the conflicts, we can change the priority of the "%" of a refer file: more than 10, and less than 50, so that if a file begins by a "%" it is a refer file, except if that character is part of the definition of another file. WIth such a definition, Tex and Matlab files will not be recognized correctly if 1) they don't have extension, and 2) they only match the single "%" expression. Here is a corrected refer.xml, in wich the bug is fixed, and the priority defined to 40. Cheers, Pierre-Jean. refer.xml Description: XML document
Re: [Groff] how to use amsmath symbols ingroff␛
Hello alls, It appears that I inserted some escape sequence in the content of my previous mail, which explain it appears empty. That was not my intention, of course. Here was my message, and sorry for the noise... Pierre-Jean. > Shiv Shankar Dayal wrote: > > > Also, how can I do syntax highlighting? Should I write custom > > scripts to format my piece of code? > > > > Syntax highlighting on the input or the output side? > > > On the output side. I guess I can write a Python script which can be invoked > > along with Pygments to output code to produce colorized output in PS/DVI. > > At least, the old vgrind script, and it's preprocessor > vfontedpr, doest that. They are part of the heirloom > doctools archive. > > Since they were not very conveniant for today use, I've > worked on the vfontedpr pre-processor, to make it > independant and easier to use. I renamed it "grind", > since it's no more compatible with older versions. > > * Grind acts by default as a filter, and highlight code > between .vS and .vE macros. The first argument of the .vS > macro tell to grind which language to highlight. > > * Grind will highlight the whole file if the language is > given by the -l option. > > * Code is highlighted by inserting string around keywords, > variables, strings, and so on. You should defined these > strings in your file or macro package. > > * Except for troff, how to highlight code is defined in the > grindefs file, which one can (not easilly) modify. It does a > very basic job, but correct for short pieces of code. > > * To highlight troff sources, grind use an hardcoded parser, > which does a better job, thought certainly not perfect yet. > > * the manpage should be enought to use it, and the grindefs > file is commented to help people to modify it. > > * Grind is distributed under the original BSD licence. The > grindefs file is distributed under the CDDL1.0 licence. > > Since it might be usefull now, I share it here, just in case it > passes throught the list robot. > > Cheers, > > Pierre-Jean.
Re: [Groff] replicating official memo
Daniel Lyons wrote: > I'm fairly new to groff. Me too, I'm a four year old troffer. > I'm thinking now if I ever want to do footnotes or number > headings or whatever, I should instead customize one of > the existing macro packages. This is my question. I think there's four ways of using troff: 1. use a standart macro package without modification, 2. use mom macro package, which is highly customizable, 3. use a standart macro package by modifying it, 4. create your own macro package. Methods 2. and 3. should give the same result. Method 3. is probably harder, but it's a good starting point to be able to create an own macro package. > I gather this is usually done with -ms, is that correct? If you choose method 3, -ms is known as a good choice, since it is probably simpler than other macro packages. That's the one I choosed to start, and I've never complained about that choice. When ms couldn't suit my needs, I began to write standalones macros, and so, never really tryed other macro packages. > Is the chapter on customizing -ms in UTP the right reference for this kind of > job? In a sense, yes, but the problem is that UTP is based on the orginal ms. Groff ms has been rewritten from scratch. But, consider that there is two way of customizing a macro package: - create new macro based on the ms macros, such as .PP, .SH, etc. In that case, you only need to know the troff commands. - hacking the package. you'll have to know the troff commands, *and* to understand the internals of the macro package. In that case, you'll have to read the ms macro, and try to understand it by yourself. The original "nroff/troff user manual" gives some examples to manage footnotes and headers. It's, in my opinion, the best troff documentation. The manual can be found on heirloom troff website (take care of some incompatibilities between heirloom troff and groff): http://heirloom.sourceforge.net/doctools/troff.pdf Cheers, Pierre-Jean.
Re: [Groff] refer how-to
Daniel Lyons wrote: > If that's the case, how does one actually use refer to > produce a paper with inline references and references at > the end? Didn't look how does mom handle this, so just in case that could help, here is how I do. With Gnu refer, you can use the "bibliography" command between .R1 and .R2 macros. Actually, by writing, where you want the bibliography list to appear: .R1 bibliography file.ref .R2 Running refer from your groff pipeline will then produce a paper with inline references and references at the end. The Gnu refer manual page is a bit discouraging, but, this is because Gnu refer is *very powerfull*. Gnu refer offers, like tbl and eqn a real mini-language. If, for some reason, you have to use a non-gnu refer, you can replace the R1...R2 commands by this one (and still run refer from the command line): .pso refer -B file.ref In both case, references not cited inline, but present in your bibliography file will appear in the bibliography list. Cheers, Pierre-Jean.
Re: [Groff] groff_lilypond v0.2
Hello alls, The groff_lilypond program is a very nice idea. But since many of you seems to want to write music with troff, why not asking to lilypond people to implement a groff output, since it seems to exist a latex output? I mean, they might not want, or have no time to do this, but, it's not impossible that someone find interesting to work on that, isn't it? I'm asking this question because I don't exactly understand why nobody seems to wish that: is that wished but for some reason impossible -- and so not said -- or is that not wished? In both case, I would appreciate to understand why. Cheers, Pierre-Jean. "Bernd Warken" wrote: > In groff_lilypond there are now 2 modes for generating the EPS > files: > --ly2eps (the new default) and > --pdf2eps (that's the old mode from version v0.1 with pdf to ps to eps). > > With ly2eps mode, lilypond generates the EPS files itself, for each page > one EPS file. > > Unfortunately the .PSPIC works only in groff pdf and dvi mode, not in ps. > Tty, X and html mode have errors and display only a rectangle with the > file name. > > To fix that is beyond my knowledge. > > I could write the groff_lilypond program only by the knowledge that many > of you gave per email. I thank you very much. > > Bernd Warken
[Groff] (no subject)
Dear Troffers, Even if it's not a Groff related project, I'm sure that some of you might be interested by Utroff: http://utroff.org - Utroff is focused on Heirloom Troff, and gives some macro to handle its typographic features easily. - These macro follow a single language, so that one can export his document to various layout without having to modify it. - Summaries, table of contents, indexes, and internal links are supported out of the box. - Export solutions to readme, man, markdown, xml, html, and fodt (flat OpenDocument) are included. - Pre- and post-processors have been added or modified to handle syntax highlighting (Ugrind), the iso-690 bibliography standart (Refer), and greek polytonic (Tchars). I've released the first public version today: utroff-0.1. Enjoy ! Pierre-Jean.
[Groff] Announcing Utroff
Dear Troffers, Even if it's not a Groff related project, I'm sure that some of you might be interested by Utroff: http://utroff.org - Utroff is focused on Heirloom Troff, and gives some macro to handle its typographic features easily. - These macro follow a single language, so that one can export his document to various layout without having to modify it. - Summaries, table of contents, indexes, and internal links are supported out of the box. - Export solutions to readme, man, markdown, xml, html, and fodt (flat OpenDocument) are included. - Pre- and post-processors have been added or modified to handle syntax highlighting (Ugrind), the iso-690 bibliography standart (Refer), and greek polytonic (Tchars). I've released the first public version today: utroff-0.1. Enjoy ! Pierre-Jean.
Re: [Groff] Fw: We need a new maintainer for groff
Dear troffers, I wish we could simply cross the street to offer to Werner some champagne for the long time spent working on groff, and for the success of his next projects... Werner LEMBERG wrote: > Here's my e-mail sent to gnu.org. For now, since our small community now search for some more people able to maintain groff, I've written a little news in the french website devoted to linux and free software. I hope that this can help groff: https://linuxfr.org/news/groff-cherche-un-nouveau-chef-de-projet
Re: [Groff] space width
Peter Schaffter wrote: > I have to say I completely agree. Backward compatibility is > essential, but more and more, I wonder about future compatibility. > As far as I know, I'm the only person actively developing > a macro set for groff. I should claim here that I am also actively developping a macro set (visible on http://utroff.org). These macros have been made for Heirloom Troff, especially to handle these typographic extensions that are missing to groff. And I think that backward compatibility is something that we need. Simply because, at this time, each troff version has its advantages: if you want typographic features, you can actually use heirloom troff, and if you want powerfull pre and post processors, you should better choose groff. The actual minors incompatibility between groff, heirloom troff and plan9 troff is certainly a solution for some needs, but it is also a major problem for the whole troff community. Should'nt we begin the extension discussion by a discussion about the "state of the art" in the troff land ? Cheers, Pierre-Jean.
Re: [Groff] The future redux
ce xml documents. One simply have to write a nroff macro to do that, and let nroff itself deal with all the macro created by the end user and inserted in the final document. What's difficult, thought, is to deal with newlines. Nroff could probably do this alone, but it's hard to implement. Much more simpler is to let him insert some tags that inform a post-processor to delete the not needed newlines. This way, the command line to convert a troff document to xml is: nroff -mux f.tr | postxml > f.xml It's so easy ! > * Summing up In one hand, I'm often feeling that our recents discussions are pointless since Groff does not have any developper to implement what we're discussing about. But, in the other hand, an overview of the state of the art in the troff land (and probably also latex), a precise roadmap, and an organized community is probably needed to find a developper. Maybe that we could continue this discussion in the aim of producing a public document that would encourage people to come and work on groff. > Again, sorry for the long post. So do I. Cheers, Pierre-Jean.
Re: [Groff] The future redux
Peter Schaffter wrote: [ about heirloom troff paragraph at once adjustment ] > > I believe that Groff will face this kind of problems. > > FWIW, the mom macros solved this thorny some time ago. I won't > say it was easy--I still recall the hair-pulling six weeks I spent > getting it right. And, to be honest, I'm not sure the mom solution > is 100% robust, though no one has ever reported a problem. And, > again being honest, when I look at the macros these days, I'm not > certain even I can untangle all the hoops I had to jump through. :) Do you mean that you've worked on mom so that it can be used with heirloom troff and its paragraph at once adjustment activated ? If that's not what you wanted to say, you, did not understood me. Usual troff line by line formating make (almost) sure that the note diversion occurs on the page where the note has to be printed. But with the heirloom paragraph at once adjustment, the diversion occurs at the time the whole paragraph is formated, then, the paragraph is printed, and might be split on two pages. The result is that the note which should appear on the second page are part of the diversion of the first page... That's why we must divert the note to the new linetrap, and wait that the linetrap is executed to divert the note to the diversion containing the note of the page. Here is a short (not working) example: .de NOTESTART .nr I +1 .\" Put the line trap \&\\P[LINETRAP-\\nI]\c . .\" Define the macro of the line trap . de LINETRAP-\\nI . \" add the note to the other notes of the page . da PRINTNOTES . NOTETRAP-\\nI . di \\.. . . \" divert the note to the line trap . di NOTETRAP-\\nI .. .de NOTESTOP . di .. .de FOOTER . PRINTNOTES .. If there are three notes on a single paragraph split on two pages, and that only the first two notes are on the first page, heirloom troff will execute the macros in that order if paragraph at once adjustment is set: .NOTESTART .NOTESTOP .NOTESTART .NOTESTOP .NOTESTART .NOTESTOP .LINETRAP-1 .NOTETRAP-1 .LINETRAP-2 .NOTETRAP-2 .FOOTER .PRINTNOTES .LINETRAP-3 .NOTETRAP-3 .FOOTER .PRINTNOTES Funny isn't it ? Cheers, Pierre-Jean.
Re: [Groff] The future redux
(Ted Harding) wrote: > Whichever way you try to output footnotes in the correct page, there > is one situation which will cause problems. > > Namely, the in-text reference to the footnote is in what would (say) > be printed as the last line but three on the page (i.e. 4th line from > the bottom). I thought that ms could handle that correctly. There's a long time that I did not use it, so I might be wrong. In my own macros, I'm using two footer traps: one to begin the notes, and another one to divert the text of the note that does not fit on a page to the next one. Cheers, Pierre-Jean.
Re: [Groff] Mission statement
Hello groffers, Before reading further, please remember that I switched from groff to heirloom troff because groff was missing things that I need. I nonetheless hope that my opinion might be of some interest for you. Peter Schaffter wrote: > Here's a draft for a mission statement, based on discussions over > the past few months. Comments, please. I personnaly regret the emphasis on the semantic man and build system discussions, which obfuscate what I think are important things for groff. I still remember what Werner said a few month ago: > . Implement TeX's paragraph formatting or something similar - I >consider groff's line-oriented paragraph formatting as its weakest >point. See heirloom troff for an example how this could be >implemented. > > http://heirloom.sourceforge.net/doctools.html > > . Update to today's font world. What groff currently supports >natively (PostScript Type 1) is out of date since 15 years. >Again, heirloom troff has support for this. > > . Apply zillions of small bug fixes sent to the groff mailing list. > > . Better support of Unicode. With that in mind, the recent mission statement is a bit disapointing concerning the text processing mission of groff: > Backend > > - implementation of the Knuth-Plass linebreaking algorithm with > paragraph-at-once formatting; groff currently implements > line-at-a-time Fonts and Unicode are, IMHO, missing here. And why not mentionning heirloom implementation ? Isn't it an important reference for anyone wishing to work on these features ? Cheers, Pierre-Jean.
Re: [Groff] Manpages, groff, and the browser.
Hello alls, Kristaps Dzonsons wrote: > Even if groff(1) could do as above, and somehow carry over the original > macro language's "meaning", it'd be only as good as its input language. > To wit, Eric proposed extending man(7) with semantics to address > exactly that. And that would give us... another mdoc(7). > > While I agree that mdoc(7) is no semantic saint--sometimes it goes too > far, sometimes not far enough--it exists right now, has considerable > support and inertia, many eyes on macros and renderings, and has > demonstrable proof of capability. mandocdb(8), via mandoc(3), dumps > manpages' semantic content into Berkeley or SQLite databases. (Ingo, > who's captaining mandoc, can speak better on its status, as well as > -Thtml and friends.) > > And how exactly would groff(1) profit from a new macro language? At the > very least, it'd require a whole new macro package to maintain. And > groff(1) still wouldn't be able to understand semantics without "clean" > roff(7) and considerable work on internals. > > And how would the community as a whole benefit? As a language, the new > man(7) wouldn't be much different from mdoc(7). And then there's > balkanisation: we already have two language for manpages. You're > proposing another? I agree with all that. Mdoc looks like a simple and obvious solution for the semantic man problem. I believe that each project concerning the semantic manual would study that possibility seriously. Mdoc aims to be semantic, while man does not have that goal. If the semantic goal of mdoc is not achieved, it's still possible to improve it. That's exactly what Ingo Schwarts proposed: > - improve the semantic usefulness of manpage markup by encouraging >and actively supporting the transition from man(7) to mdoc(7), >and carefully evolve and improve mdoc(7), while at the same >time continuing full support for the traditional man(7) macros, >completely unchanged, to support historic and autogenerated >documentation. And Eric S. Raymond replied: > Actively supporting is empty verbiage unless you have a mechanical > translator from man(7) markup to semantically enriched mdoc(7). You > don't, and I know exactly why you don't, because I wrote the pattern > analyzer you would need and don't have. Eric is wright: if doclifter could evolve to produce mdoc document from man document, most of the semantic man problem would be solved. Adapting doclifter in such a way could be a great occasion to define in which point mdoc would have to be improved. Eric knows the solution and is the most competent person to implement it. It would be a great gift to the community if he would agree to do the job. It would also be a great example of community conciliation. Cheers, Pierre-Jean.
Re: [Groff] Mission statement, second draft
Hello folks, Peter Schaffter wrote: > Here's the second draft of the mission statement, incorporating > suggestions from Ingo, Eric, Pierre-Jean, and others. It's starting > to come into focus, although a third pass will probably be necessary > before we commit to it. I mostly agree with that second mission statement. Nonetheless, I think that if the goal is to publish this mission statement in the hope that it encourages people to join the groff community, a bit more of « writing art » will be needed: words that encourage someone to come and work on groff. Werner spoke about the clean codebase of groff, we could also mention our experienced community and the precedence of Knuth and Kernighan algorythms. The mention of some "mentors" might also be important if some students whish to work on groff. Last but not least, the Gnu project might have some kind of help to give to groff developpers. That kind of literacy should probably be part of another document. > 2. Ingo's strategy... > 3. Eric's strategy... We all have a strategy here. I've got mine: find a path to minimize conflicts between heirloom troff and groff. These different strategies are part of our recent difficulties, and hopefully, we're gonna solve them. It's important that we do not discover in a few month that groff is a "cheval de Troie" for a goal that is finally not dedicated to the groff project. And I need some insurance that the man project is not such a "cheval de Troie". These insurances might be: - Don't forget the existing mdoc markup, - Study several solutions, - Don't use tricks to force the usage of that new markup but only arguments, - Show a draft of the whole project. This is a kind of literal hygiene mode for that discussion. Cheers, Pierre-Jean.
Re: [Groff] Mission statement, second draft
Peter Schaffter wrote: > On Tue, Mar 18, 2014, Joachim Walsdorff wrote: > > it would be fine if you could provide an example text, formatted > > both with groff and Heirloom troff, to demonstrate us the > > typographic gain by `paragraph-at-once formatting´ against `line > > formatting´. > > http://heirloom.sourceforge.net/doctools/just.pdf I've attached another postscript example produced by heirloom troff. Look at the blanks in the first paragraph, and how we can remove them so that the "color" of the paragraph seems more uniform. We can also use some tricks to increase or decrease the size of the whole paragraph and avoid orphans. Some art is still needed to adjust everything correctly. These features only offer the possibility to practice that art. Here is the code I used: .\" set heirloom extensions: .do xflag 3 .de lorem .sp 1v .\" text from wikipedia "microtypography". Microtypography is the name given to a range of methods for improving the readability and appearance of text, especially justified text. The methods reduce the appearance of large interword spaces and create edges to the text that appear more even. Heirloom Troff, the OpenType compatible free and open-source version of UNIX troff also supports protrusion, kerning and tracking. .. .vs 15 .ps 11 .ll 10v .po 3v .\" Historic troff behaviour .lorem .\" Paragraph at once adjustment .padj .lorem .sp |0 .po 16v .\" lightly use glyph size .letadj 99 99 15 101 101 .lorem .br .\" Define default interword space .ss 10 0 .\" Define minimal interword space .minss 9 .lorem Cheers, Pierre-Jean. f.ps Description: PostScript document
Re: [Groff] Mission statement, second draft
Hello alls, Deri James 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 .hygiene command is an interesting debate. I don't exactly know what to think about it. After writing several articles about troff on a french linux & free software website, and reading the various comments, I've got the feeling that: 1. people usually don't know that troff is able to produce postscript documents. 2. people which use latex are happy with it and will not switch to troff, even if it's typographic quality is equivalent. 3. most people prefer using a markup syntax (txt2tag, markdown...). Some of them are interested by another backend than LaTex to produce pdfs. 4. some people are interested by the programmability of troff, and want a tutorial to build their own macros. I believe that the group 3. and 4. are the onliest group of people which may join the community of groff users. Those two groups of people need to be able to insert raw troff commands in their documents: txt2tag, for example, insert some of these raw troff commands while producing troff documents, and should insert more of them to do a better job (to deal with imbricated fonts for example). End users of troff usually work with some handmade macros that they need for their daily work. Furthermore, I had a quick look at the evolution of txt2tag. Its first release was a basic tag transformer. With time, more and more complex commands where introduced, and there's now a kind of txt2tag language that can be used to automate some things and tweak the default export mechanism. Markdown seems to follow the same evolution. A versatile language is the core component of groff. And I think that's its best feature for new users. So... An hygienic mode could truncate groff, and effectively decouplate a syntax and the troff backend. There would not have any reason to use troff anymore... But that also might be a nice part of groff to be able to check that a document is strictly semantic. With that in mind, instead of an hardcoded lock in the macro package, I'd prefer and external tool, a kind of `checknr`, or a command line option. Saying that, I still don't exactly know what to think about that idea. Cheers, Pierre-Jean.
Re: [Groff] Mission statement, 3rd draft
Peter Schaffter wrote: > this represents the final version of the mission statement. This is a fine final version. Pierre-Jean.
Re: [Groff] OT: Fork of the Heirloom Documentation Tools for fixing bugs
Hello groffers ! Carsten Kunze wrote: > For discussing heirloom troff (and other non-groff > specific macro packages and tools) a mailing list will be > set up to not misuse the groff list and annoy groff-only > list members (further ;). I'm currently setting up that list: it should be available in a week or two. Carsten Kunze and I had a long discussion since we are both working on (and with) troff which are not groff. We believe that this kind of discussion could interest more people, and since there's no meeting point for the whole troff community yet, we decided to create one. At least, we need a list to share bugs about DWB, Heirloom and Plan9 troff. But we also want a list to discuss about the the recent troff developments, such as Carsten's Troff, Neatroff, Utroff, to share ideas, tips, requests, and comments. It appears to Carsten and I that there's place to some coordination even if we are working on different projects, with different goals, and using different troff implementations. Diversity with compatibility is one of the strength of troff, giving a place to that diversity is the goal of this list. Cheers, Pierre-Jean.
Re: [Groff] OT: Fork of the Heirloom Documentation Tools for fixing bugs
Ralph Corderoy wrote: > Would you consider the groff list suitable if the list's owners and > general population of subscribers were happy? Seems a shame to fragment > the small, fledgling community. This was, in fact, our first opinion. But we finally thought it would be annoying for the groff community to receive mails about technical issues which does not concern groff. Ingo Schwarze wrote: > Given how many people already posted variations on this > theme: The rash spectator might already jump to > conclusions regarding the predominant feeling of the > population... We are both very happy to read that, because our onliest community is the groff community. But let be sure that everyone understand what's going on: There's first, a pending technical discussion: Since Carsten is fixing Heirloom troff, Utroff now mostly rely on his work, and we will probably have to discuss about Heirloom bugs and utroff issues on the groff list, and we will maybe invite our potentials users to do so. There is, secondly, an observation: We are not the onliest fool outside of groff. There are some Heirloom users on this list, Ali Gholami Rudi announced great improvments on Neatroff a few weeks ago, and the Plan9 community is happy to receive Carsten bug reports and patches. But the non- groff users and workers are uncollected so that they're hard to see. I'd be happy to see them more. There is, thirdly, a simple goal: help the development of the various projects around Troff. And the simple thing to do for that is to encourage discussion between these projects, even if they don't share code. For sure, all this is not a big deal for the Groff mailing list since it only concerns a few people, and so, a few messages. But it's another goal than the Groff development. That's why I think it's not a so easy decision. Cheers, Pierre-Jean.
Re: [Groff] OT: Fork of the Heirloom Documentation Tools for fixing bugs
Ralph Corderoy wrote: > I'd still say give it a try. Perhaps where it is, say, Plan 9-troff > specific, mention that in the subject. We've lost the benefits of > Usenet readers like trn, but some of us might have mailer's with `kill' > files. :-) Well, I agree with that: let's try, and take another decision later if it appears it's not constructive. Cheers, Pierre-Jean.
[Groff] [Heirloom] Generating doc/ files
Hello alls, I'm forwarding this discussion to the list. Comments are welcome :) Carsten Kunze wrote: > on generating the documents under doc/just, doc/troff etc. > a lot of errors regarding missing fonts are reported. I > had always ignored these messages. I think that Gunnar > had a lot more fonts installed on his private system to > make the documents look fancy but did not put this fonst > to SourceForge (maybe for licence reasons). What do you > think? The question is regarding issue #1 on GitHub > (https://github.com/n-t-roff/heirloom-doctools/issues/1). Yes, Gunnar was using a set of special fonts: - Adobe Myriad Pro for doc/quickstart, - Adobe Garamond Premier Pro for doc/font and doc/just, - Tex Gyre Terms OpenType for doc/troff, Tex Gyre Terms OpenType can be downloaded from the CTAN: http://www.ctan.org/tex-archive/fonts/tex-gyre/ It is under the Gust Font Source license which derives from the LaTex Public License. It is, for this one, at least possible to adapt the makefile to download the font during the build process (the font is not packaged outside of TexLive in most distributions). I can do this if you want. The others fonts are private ones. Actually, the obvious choice to replace them is the Libertine font, but it does not have the elegance of the garalde choosen by Gunnar, and so, is not a very good choice for a demonstration file. There exist a garalde on the CTAN, but the last time I checked it, it was only containing a minimal set of glyphs, and so it is not a better choice. Finding an appropriate free font will be difficult... Once the font is choosen, we still have to re-write the .tr files, since they make an intensive usage of the font features of heirloom. I now have some experience with this, and can do it if needed. Cheers, Pierre-Jean.
Re: [Groff] [Heirloom] Generating doc/ files
Blake McBride wrote: > The documents should be changed to use included or > standard fonts only. For the troff documentation I agree, we should use the default font. > If included or standard fonts are not good enough - take > that up with X11 et al. That's the case of the other documents, which show how to use the font features and how to tweak the typographic details. I believe we should go with Linux Libertine, since it is packaged in most distributions -- at least, I'm gonna try with this one. Cheers, Pierre-Jean.
Re: [Groff] Extending refer
"Bernd Warken" wrote: > 1) `refer.man' cites under `FILES': > file.i Index files. I did not investigate this much, but this should be the conventional output file name of the 'mkey' program from Heirloom/refer, which build an index of keys of a refer file. Another program, 'inv' make an inverted index from the mkey output and produce a set of files: file.ia, file.ib, file.ic, file.id. Then, the 'hunt' program search and deliver items from the inverted index. For all these programms, the documentation is "Application of inverted indexes in the Unix system" by M. E. Lesk. Based on this document, I have made three manual pages, which might be usefull: http://utroff.org/man/mkey.html http://utroff.org/man/inv.html http://utroff.org/man/hunt.html > 2) `refer.man' cites under `FILES': > /usr/dict/papers/Ind Default database. I personnaly use refer a lot. And even if I copy all my references in a central database, I find more usefull to create a new database for each paper. That said, it would be nice to share a refer database of the various troff (and maybe unix) papers, which are sometimes mentionned on man pages. > 4) The programs in Heirloom and refer history > - addbib I find easier to add papers manually. > - roffbib This one can be replaced easilly by refer -B file.ref | troff -ms > - sortbib Since refer is able to sort, I don't use this one a lot. Cheers, Pierre-Jean.
[Groff] [Heirloom] bug in '.if' string comparison tests
Hello Alls, I've found another bug in Heirloom troff (with ^G being the control character, "Ctrl+V + Ctrl+G" in vim): .do xflag 3 .if "A"A" .tm A is like A .if ^GB^GB^GB .tm B is like B .char " "\| .if "A"A" .tm A is like A .if ^GB^GB^GB .tm B is like B Output "A is like A" and "B is like B" only once. I've recently seen the usage of the ^G character as field separator. That is a good idea, since it should avoid most possible conflicts with user input. But does anyone know what does this character means, and why does it seems to be prefered to other control characters ? Cheers, Pierre-Jean.
Re: [Groff] Extending refer
Werner LEMBERG wrote: > I've just seen this: > > http://ftp.fi.muni.cz/pub/bibliography/tools/bibtex2refer This is, for sure, a handy script. Zotero (a firefox and OpenOffice plugin, which extract bibliography references from web pages, store them, and insert them in office texts) can also deal (input and output) with the refer format (also known there as 'RIS' format). Pierre-Jean.
Re: [Groff] [Heirloom] bug in '.if' string comparison tests
Ralph Corderoy wrote: > See ascii(7), as others have said, and 10.1 in http://troff.org/54.pdf > around where it says I should probably stop skim through this document to look for command definition, and start reading it from the begin to the end... :) Thanks ! Pierre-Jean.
[groff] [Utroff] Utmac ported to neatroff
Hello alls, I am pleased to announce you that my macro set Utmac has been ported to Neatroff. And indeed, I must admit it is a pleasure to work with Neatroff! For years, I was using Heirloom Troff, for its ability to format paragraphs at once. Neatroff does that too, in a much more transparent manner. To switch from Heirloom to Neatroff, all I had to do was removing Heirloom's specifities and complexity. As a result, the code of Utmac is now much simpler, and close to be Groff compatible. As a side effect (which could interest Groff users), since Neatroff does not implement nroff, Utmac is using `groff -Tutf8` to format plain text files, as follow: $ groff -k -Tutf8 -mum f.tr > f.man $ groff -k -Tutf8 -mut f.tr > f.txt $ groff -k -Tutf8 -muw f.tr > f.mkd $ groff -k -Tutf8 -mux f.tr | postxml > f.xml There are probably still bugs here and there, but for the most part it works well, as can attest the Utroff html pages (http://utroff.org), and the manual pages shipped in all Utroff archives. I would like to be able to share some of my enthusiasm for Neatroff. It is a wonderful troff implementation, not only for its paragraph at once and right-to-left scriptures implementations, but also because its source code is clear, and its installation easy. Ali Gholami Rudi is helpful and attentive, which is a precious thing too. People willing to have a look at Utmac can find it here: https://github.com/pjfichet/utmac And Neatroff is there: http://litcave.rudi.ir Kind Regards, Pierre-Jean.
Re: [groff] Now online: gropdf / grops previewer
John Gardner wrote: > Well, here it is: > https://rawgit.com/Alhadis/Roff.js/web-demo/index.html It is nice to see our old troff on the web, thank you for the hard work! If I remember correctly your other posts, this previewer is only a part of the online troff editor you are working on, isn't it? I also noticed you were thinking about a troff to xml converter. May I suggest you to have a look at my own "proof of concept" on that matter: <http://utroff.org/xml.html> (I posted some mails about it on that list a few months ago). It is not especially a great piece of software, but I believe the idea of using nroff, with a macro made for the purpose of the conversion, still worth being considered. At least, I'd be glad to hear criticisms if it is not. >- *Heirloom Troff output isn't perfect.* This is a known issue I intend >to fix in a future release. At the moment, the renderer is heavily reliant >on the âwâ and ânâ output commands to identify where a word ends. > Groff >uses these sequences consistently, but Heirloom doesn't. I have used heirloom troff for years, and felt very lonely. Karsten Kunze seemed to be the only other person on earth interested with that software. I'm not certain it is worth your time working on compatibility with heirloom troff. Kind Regards, Pierre-Jean.
Re: [groff] Now online: gropdf / grops previewer
John Gardner wrote: > It's an extension for a text editor named Atom <https://atom.io/>, which is > like Emacs or Vim except graphical. Atom runs on a framework called Electron > <http://electron.atom.io/>, which uses web technologies (HTML/CSS/JS) for > creating desktop applications. This foundation is what's enabled me to > share my work as an online previewer. But the full experience can't be > ported to the browser, since it needs to shell out to Troff to process its > output. Ah... I thought atom was an online editor of some kind... Thank you for the details! Pierre-Jean.
Re: [groff] Creating a numbered list without macros
Hello alls, Tadziu Hoffmann wrote: > Note that I'm not saying that you should generally not > write your own macros. On the contrary, I'm all for it. I must say that discussion gave me the uncomfortable feeling that people were advocating against writing personal macros. I think that writing a personal macro is a perfect way to use groff. The original troff documentation is short and well done, giving enough clues for people to dive in the language by themselves. That makes writing macros relatively easy, and that's why I love troff, because, unfortunately, one simply has to have a particular need in term of data input format, layout, or localization (think at the macros formatting refer output) to need a custom macro set or a hacked one. Kind regards, Pierre-Jean.
Re: [groff] Design and Implementation of *roff
John Gardner wrote: > Reimplementing Troff is a task best not attempted at all. Well, Ali Golhami Rudi made it a few years ago... Reimplementing a Troff is a task people can do if they have reasons to do so. > On Sat, 1 Dec 2018 at 02:37, Yves Cloutier wrote: > > I'm in search of any documentation that provides insight into the design > > and implementation of a *roff. > > > > I know source code exists for a few implementations like Plan 9, Heirloom, > > Groff and Neatroff. > > > > However what I'm in search of is something a bit more high-level than > > source code. Rather some design/implementation documentation that explains > > an *approach* to implementing a *roff. Althought it's still source code, I'd advise looking at Neatroff sources: it is, as far as I can judge, clean, small, and easier to understand than the other troff sources I looked at. It also contains features that worth being considered today: paragraph at once adjustment and right to left scriptures. Here it is: https://github.com/aligrudi/neatroff Kind regards, Pierre-Jean.
Re: [groff] Design and Implementation of *roff
John Gardner wrote: > Well, I assume his reasons were to have a Troff variant which supported > right-to-left languages (which, if you think about it, is a pretty glaring > oversight in a typesetting system...) Ali also has tonnes of other > non-trivial projects, so his patience is obviously in greater reserves than > most mortals. Using Ali's creations as an argument was unfair, I agree :)
Re: [groff] Design and Implementation of *roff
Hello alls, Actually, neatroff's documentation has a figure which quickly shows where Neatroff's major layers and features are implemented in its source tree: http://litcave.rudi.ir/neatroff.pdf#page Pierre-Jean.
Re: [groff] Design and Implementation of *roff
Ted Harding wrote: > So, happily inspired, they developed the > text-formatter runoff (--> roff) on Unix, and then > demonstrated to Bell Labs how good it was at formatting > structured documents -- in particular legal documents. > At this point Bell Labs woke up, and adopted Unix! Do we have any copy or source of these early troff formatted legal documents? Was there a macro dedicated for that task? Pierre-Jean.
Re: [groff] Regularize (sub)section cross references.
Hello alls, "G. Branden Robinson" wrote: > +.ie \\$1 .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ > +.el .tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz The problem with this, is that it ignores all but english languages. "élément", for instance, would become "éLéMENT", which is the ugliest thing you can get. And yes, there are man pages in french, and I believe, in a lot of other languages. Cheers, Pierre-Jean.
Re: [groff] Regularize (sub)section cross references.
Hello Ingo, hello alls, Ingo Schwarze wrote: > >>> +.ie \\$1 .tr aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ > >>> +.el .tr aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz > > >> The problem with this, is that it ignores all but english languages. > > > Yup. I'm aware of that, which is why I did not propose it as an > > actual patch. > I'm a native German speaker and i wouldn't worry about that at all. > It would be good enough to just ignore that problem, it is really a > fringe case. While I agree with the facts that 1) translated manpages are rarely up to date, 2) most people, and particularly those having to read manual pages, speak english well enough for that task, and 3) computer science is better understood in english than in native languages in most places, I can't agree on the fact that a typographical enhancement of manual pages should involve a regression for all languages but english. I mean, people allready believe that groff/troff is a tool of the past, they don't need to come back to the nineties when computers were unable to display accented uppercase letters. Or should they ? Kind regards, Pierre-Jean.
Re: [groff] Fonts, PDF images, groff vs. heirloom troff
Richard Morse wrote: > Hi! I’m working on a project where I want to use troff to create > PDFs. I want to use some particular OpenType features (in particular, > a bunch of smart kerning and character substitutions), but I also want > to embed PDF images into the final PDF. > What I’ve discovered is that GNUs groff does not seem to handle > fonts in any useful way, but Heirloom troff can’t manage PDF images. Heirloom Troff probably offers the most detailed management of OpenType fonts. For it, you can transfer your PDF images to EPS (with convert, from imagemagick for example), and then embed the EPS file. There's a macro for that in the heirloom package. Using groff would require you to transfer the font in a format groff undestands, exporting each OpenType feature you want to use in its own font. I can't help much more with groff, though. > Is there some other option available that can do both of these? Neatroff do both of these. It suports OpenType fonts, but does not offer as much control as Heirloom Troff does. For instance, the .ff request allows you to select an OpenType feature, and .fmap to map a troff character to a glyph in a font. You will have to create a font definition file from your font, though (see the script in neatroff_make). And you can embed your pdf directly, with the .PDF macro, part of tmac.eps. Neatroff is described here: http://litcave.rudi.ir/ It can be installed with: https://github.com/aligrudi/neatroff_make That being said, I would personaly advise you to use the troff version you are comfortable with, because all the above mentionned will require some (probably long) set up. Kind Regards, Pierre-Jean.
Re: [groff] Fonts, PDF images, groff vs. heirloom troff
aksr wrote: > On Tue, Jan 22, 2019 at 08:27:08AM +0100, Pierre-Jean Fichet wrote: > > Neatroff do both of these. It suports OpenType fonts, but does not offer > > as much control as Heirloom Troff does. > Are you sure about that? Heirloom troff is able to set ligatures with .flig and .fdeferlig, kerning with .kernbefore and .kernafter, .kernpair, and hanging characters with .lhang and .rhang. All these things are, as far as I know, missing from Neatroff. > Anyway, even though I use both, I often prefer Neatroff (it is very good). I also prefer neatroff, for a lot of reasons... Two of them being: - heirloom paragraph at once adjustment behaves sometimes oddly (and seems buggy). - That same algorytm forces the usage of line trap macros to print notes, which is hard to code. > Code is clean and the Neatroff's author is very helpful. I agree ! Kind regards, Pierre-Jean.
Re: [groff] Fonts, PDF images, groff vs. heirloom troff
Hellor Roy, Roy Fisher wrote: > On 1/24/19 12:58 AM, Pierre-Jean Fichet wrote: > > - heirloom paragraph at once adjustment behaves sometimes oddly (and seems > > buggy). > > What sort of odd/buggy issues are you seeing with paragraph adjustment? > Which version of Heiloom? As far as I remember, on some paragraphs, the inter-word space is not regular, ie too high on some lines, which is not as pretty as it should be. That was years ago, when I was still using heirloom before switching to neatroff. I did not investigate more myself, but some people did for n-t-roff: https://github.com/n-t-roff/heirloom-doctools/issues/22 Hopefully, they'll come to a patch, and a better algorytm. But even though, I'm not sure I'll come back to heirloom, feeling neatroff does the job very well. Kind regards, Pierre-Jean.
Re: [groff] Fonts, PDF images, groff vs. heirloom troff
Roy Fisher wrote: > The changes that resulted from issue #22 were incorporated into n-t-roff > last year, and it can now produce paragraphs as good as those of the > leading commercial application, at least in my (possibly slightly > biased) opinion. I'm so glad to read these changes are applied. It might be worth closing the issue (openning a new one if needed), since seeing it openned made me think the changes were still not applied. And you should have post an announcement on this list. > So, if you do decide to revisit n-t-roff and try out > those new features, I think you might be pleasantly surprised. I've looked at reffort's doc (1), and I am indeed pleasantly surprised. N-t-roff has become a tool to create masterpieces of typographic details. 1) https://github.com/reffort/troffmanual/blob/master/troffdoc-mk.pdf > It still uses output-line traps, though, which sounds like a > deal-breaker for you. Output-line traps can be more intricate, but they > do allow full-paragraph optimization instead of forcing sub-paragraph > optimization. For the short story, I had built my macros especially to use heirloom troff correctly, using output line traps when required. That took me some effort, but I obviously managed to overcome it, and my thesis has been printed with these macros. The problem came later, when I realized how hard it was to understand the resulting code to apply fixes. The outdated and abandonned code is still online: https://github.com/pjfichet/utmac/branches Kind regards, Pierre-Jean.
Re: [groff] Fonts, PDF images, groff vs. heirloom troff
Hello Roy, Roy Fisher wrote: > On 1/28/19 4:51 AM, Pierre-Jean Fichet wrote: > > masterpieces of typographic details. > > 1) https://github.com/reffort/troffmanual/blob/master/troffdoc-mk.pdf > > While I won't disagree too loudly with the first part, that particular > document is the exact opposite. It is a utility document, a gdiffmk > markup that exists only to flag the location of changes that were made > to the nroff/troff user's manual; it doesn't use paragraph adjustment at > all. I was not clear enough, sorry. I meant the document describes a tool able to produce masterpieces of typographic details, not that the document was such a masterpiece. ;) > The description document has more detail about how to use the requests. > It will probably be more useful initially than the nroff/troff user's > manual. It can can be found at: > https://github.com/reffort/typo-tests-documents/blob/master/typotests-doc.pdf I am discovering here you're the author of these changes. That's a fantastic work you've made. It's really encouraging me to try heirloom again, and I hope, other troff enthusiasts too. > I downloaded utmac some time ago when you first posted about it. There > are some interesting ideas in there, but I haven't studied it in as much > detail as I would like. It is honestly too much based on my own needs to be useful as something more than an inspiration. Kind regards, Pierre-Jean.
[groff] troff Address book
Dear groffers and troffers, I'm looking for an address book compatible with troff. What I'd like is to automatically fill fields in a troff source. A bit more complex task would be to create several source files from a list of contacts (to build a bench of letters, for instance). Does anyone know if such a tool exist yet ? If none exist I might attempt to hack refer... Though, a vcard compatible tool would certainly be more compatible... I'm gladly receiving people's advises, ideas, and opinions about all that. Kind regards, Pierre-Jean.
Re: [groff] troff Address book
Hello Robert, Robert Thorsby wrote: > Why not simply use groff as *one* of the tools to do the job? In your > favourite programming/scripting language extract the data from the > various sources and dump those extracts into a template that contains > all the groff information. That's the kind of things I will end up doing, indeed. I was wondering if some kind of pre-processor existed back in the time, since filling letter's fields seems like a common task... There's a python library to handle vcards, which may be a good starting point for me. Kind regards, Pierre-Jean.
Re: [groff] A poor mans Excel
Hello Troff users,
Ralph Corderoy wrote:
> > I have written a small perlscript, that preprocesses tables and allows
> > to
> >
> > - add the values in selected collums
> > - to replace a table entry by the result of an expression
>
> Thanks for letting us know. As Mike said, please show us the code;
> the list's archive will hopefully capture it for others that Google later..
People may be interested by a program I made for the same kind of
purpose: tsql (https://github.com/pjfichet/tsql). It's a C thing
which parses your troff document, processes sql statements on an
sqlite databases and formats the result for either tbl or
neatroff tmac.tbl.
The user interface is not fixed yet, but is currently as follow:
sqldb :memory:
TS
allbox;
c c .
sqltbl
create table T (id integer primary key, name text);
insert into T (name) values ('Pierre'), ('Paul'), ('Jacques');
select * from T;
sqlend
TE
Cheers,
Pierre-Jean.
Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)
Hello Larry, hello alls, Larry Kollar wrote: > I’m using neatroff for printed fiction, because it directly supports TrueType > (including font features like small caps and extended ligatures) and > paragraph- > at-once justification. Still, I chafe at its low resolution (1/720in vs > Groff’s > 1/72000in), because some microtypography requires a bit more than 1/10pt > precision. The macro set I use tries to accommodate either one. As a simple curiosity, to help me improve my typographic eye, could you please explain me in which situation you need a higher resolution? Did you consider sending a request to Ali Gholami Rudi? He always seems happy interacting with neatroff's users. Cheers, Pierre-Jean.
Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)
Hello alls, Peter Schaffter wrote: > On Fri, Jul 31, 2020, Steve Izma wrote: > > ...I would like to caution people who think that the > > implementation of that algorithm [Knuth-Plass] in groff is going > > to lessen the effort that goes into high-quality typography. > > Again, I agree. That's quite strange because, in my eye, paragraph at once adjustment is really improving the quality of documents. Not that it's perfect, nor that it remove the need of a manual intervention to get rid of widows, orphans (btw, avoiding them is not the goal of that algorythm), and occasionnal glitches, but, on a day to day basis, it's a simple way to get a much better quality. I really think that's a situation where we benefit from automation. Cheers, Pierre-Jean.
Re: Groff vs Heirloom troff (was Re: Quick question: how to do .index in groff?)
Steve Izma wrote: > > As a simple curiosity, to help me improve my typographic eye, could > > you please explain me in which situation you need a higher resolution? > > For almost everything I typeset, especially books and > newsletter-type publications, I always at least a few places > where I need to use track kerning on a paragraph in order to get > good word spacing and to shorten or lengthen paragraphs in order > to avoid widows (the last line of a paragraph starting a column > of text). When I adjust the kerning (or mortising, if necessary) > in values of one-hundredth or one-thousandth of a point, it can > make a difference in whether a word fits on a line or is broken > or pushed to the next line, thereby making the paragraph too > long. I avoid trying to adjust only part of a paragraph because > that can drastically affect the "colour" (i.e., density) of the > text. > Allright, I understand now. Thank you ! Pierre-Jean.
Re: Learning troff - where to start?
Hello alls, I'm a neatroff user, and feels, as a result, compelled to give my opinion. I'll second everyone stating that "Nroff/Troff User Manual" (CSTR 54) is the manual of choice. It's 37 pages of well written documentation, and should cover all your needs: https://www.troff.org/54.pdf Then, you'll need to know what are the differences between the old troff and neatroff: http://litcave.rudi.ir/neatroff.pdf http://litcave.rudi.ir/neatstart.pdf If you use preprocessors (refer, pic, tbl...), you'll have to read their documentation separately. Then, if you want to write your own macros, you'll probably want to begin by adapting one of them, and get used with its internals. Maybe ms is a good candidate, as it's quite short, and yet used that way by Ali Gholami Rudi for neatroff, with: https://github.com/aligrudi/neatroff_make/tree/master/demo and https://github.com/aligrudi/neatroff_ths To fetch for ideas on how to do this or that, maybe can I also point to my macros, as they'll work with neatroff too, and implement a lot of things: https://github.com/pjfichet/utmac/ I figured that despite appearing unreadable at first glance, the troff formatting language is easy. I quickly could have my first working layout. Then comes the harder part of the work when complexity increases the risk of glitches, and glitches become harder to track and fix. But in the end, the journey is worth the effort, imho. Hoping that helps! Pierre-Jean.
Re: Learning troff - where to start?
Hello Johann, Johann Höchtl wrote: > .../neatroff/roff -mu-fonts -mus para.tr | ../neatpost/pdf -pa4 > out.pdf u-fonts only contains macros shared by all fonts and does nothing by itself, you should use u-libertine or u-biolinum instead: roff -mus -mu-libertine para.tr | pdf -pa4 > out.pdf > neatroff: failed to mount > I suspect I have missing fonts or am I missing another utmac - macro > inclusion? You also need to install the linux-libertine font in your system first, then produce the neatroff font. The makefile of neatroff_make, if that's what you used, should be able to do that with some adaptation. If not, you can edit the makefile in the "utmac/neatroff": BINDIR: the path to neatroff mkfn FNTDIR: the path to the neatroff font directory DEVDIR: the path to neatroff devutf directory OTFDIR: the path to your libertine font (/usr/share/fonts) FONTS: the names of the various fonts you want to convert. And you can run: make fonts And it should work... Though, please note that I'm not using the default neatroff_make installation, but a custom one, using the makefile in utmac/neatroff. Warm regards, Pierre-Jean.
