Tools for writers

classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Steve Litt
On Sun, 3 Nov 2019 18:50:56 +0000 (UTC)
Roderick <[hidden email]> wrote:

> Here is an old system, written in FORTRAN and C, perhaps compiles in
> OpenBSD:
>
> http://www.tustep.uni-tuebingen.de/tustep_eng.html
>
> But I never used it and I am hyppy with TeX.
>
> Rodrigo
>

I'm not sure, but I think if you write with a certain subset of TeX, it
would be fairly easy to write a program to convert it to XHTML5, from
which you can pretty easily create ePubs. Plain TeX as made by Knuth is
indeed simple for all simple things, and doable for more complicated
things.

SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

acampbell
In reply to this post by Raymond, David
On 02 Nov 2019, Raymond, David wrote:
> You might try lyx.  This is a front end for latex.  You can write
> without worrying about formatting and come back to that later.  Also,
> when you do the formatting, you don't have to worry about niggling
> details as in word and its clones.  Just declare chapters, sections,
> etc.
>
> Lyx is an OpenBSD package.
>

I'm glad someone has mentioned LyX. I've now used it to produce
seven books and find it excellent. But I also agree with those who
have said that producing books is a two-stage process, writing the
text and preparing it as a book.

So I start in vim, which is ideal for cutting, restoring, moving
blocks of text, etc. I then import the result into LyX, but may go
back to vim from time to time when big changes become necessar.

The above is for books that are going to be printed. I only use
libreoffice when I am compelled to provide a book in Word.doc
format, as required by Smashwords. I dislike doing this but LyX
can't produce Word.doc files.

We often read that many good writers like to draft their books in
longhand. I don't do that but starting in vim is my equivalent
method. It gives maximum flexibility and I've used it for so long
that it's become pretty intuitive to me.



--
Anthony Campbell http://www.acampbell.uk

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Roderick
In reply to this post by Steve Litt

On Mon, 4 Nov 2019, Steve Litt wrote:

> [...] If you can even conceive of it being ePub or some
> other lineflow reading format, Texlive and all the TeX/LaTeX
> tools dead-end you.

TeX produces dvi, a well documented and simple page description language.
Then it is transformed to postscript or pdf.

They are by far not dead end.

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

acampbell
In reply to this post by Steve Litt
On 04 Nov 2019, Steve Litt wrote:

>
> So after writing the whole thing, you're going to go back and insert
> some sorts of codes for backstory paragraphs, emphasis, dialog, and
> various other styles?
>
> How are you going to get word-wrap right?
>
> I know it's possible with novels, but it takes some pretty good writing
> skills to do so. And I'll go out on a limb and say it's impossible with
> a technical book.



I don't know what sort of technical book you have in mind, but I've
used my standard two-stage method (vim plus LyX) to produced a
medical acupuncture textbook with illustrations, references,
marginal images and notes. It worked well. I've described my
settings here for anyone interested:
https://www.acampbell.uk/linux/writingabookonlyx.html


--
Anthony Campbell http://www.acampbell.uk

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Yon-2
In reply to this post by Steve Litt
On Mon, Nov 04, 2019 at 02:27:38AM -0500, Steve Litt wrote:
> I'm not sure, but I think if you write with a certain subset of TeX, it
> would be fairly easy to write a program to convert it to XHTML5, from
> which you can pretty easily create ePubs. Plain TeX as made by Knuth is
> indeed simple for all simple things, and doable for more complicated
> things.
I do not think it's easy to define a subset of TeX and stick
to it.  I've used pandoc in the past to convert reasonably
semantic LaTeX files to EPUB, and sticking to the right
subset without accidentally using non supported commands was
difficult at the time.  Careful review of the produced EPUB
was needed.  Quite a nightmare.  Thankfully, all of this
ended the day I wasn't able anymore to compile pandoc and
its hundred or so dependencies for OpenBSD :-)

Maybe there are better TeX to EPUB tools now - I haven't
tried combining tex4ht with calibre for a long time, for
example.  Using a presentational format like dvi as
intermediate representation is a sign that TeX is unsuitable
as a common source, but it may work well enough
nevertheless.

Otherwise, if both LaTeX and EPUB outputs are needed, and
fine-grained control of the produced EPUB is wanted, using a
well-defined intermediate markup language seems the safest
way to go.  Oddly enough for me, markdown still appears to
be the most common choice.  I would have thought that its
caracteristics - semantically poor, with irregular and
no-warnings “every text file accepted” permissive kind of
syntax - would have made it unsuitable for maintaining long
works.

Yon

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Steve Litt
On Mon, 4 Nov 2019 09:07:13 +0000
Yon <[hidden email]> wrote:

> On Mon, Nov 04, 2019 at 02:27:38AM -0500, Steve Litt wrote:
> > I'm not sure, but I think if you write with a certain subset of
> > TeX, it would be fairly easy to write a program to convert it to
> > XHTML5, from which you can pretty easily create ePubs. Plain TeX as
> > made by Knuth is indeed simple for all simple things, and doable
> > for more complicated things.  

> I do not think it's easy to define a subset of TeX and stick
> to it.  I've used pandoc in the past to convert reasonably
> semantic LaTeX files to EPUB, and sticking to the right
> subset without accidentally using non supported commands was
> difficult at the time.  Careful review of the produced EPUB
> was needed.  Quite a nightmare.  Thankfully, all of this
> ended the day I wasn't able anymore to compile pandoc and
> its hundred or so dependencies for OpenBSD :-)

I can imagine that LaTeX subsets would be a nightmare. So would HTML
subsets. But TeX is simple enough that avoiding a few esoteric things
won't be difficult.

>
> Maybe there are better TeX to EPUB tools now - I haven't
> tried combining tex4ht with calibre for a long time, for
> example.  Using a presentational format like dvi as
> intermediate representation is a sign that TeX is unsuitable
> as a common source, but it may work well enough
> nevertheless.

Ah, yes, I've never heard of a way to convert dvi to HTML. I was
referring to writing a fairly simple conversion program that takes TeX
and converts it directly to HTML, style for style, word for word. And
this is where the subset comes in:

\mymacro{The quick sly fox jumped over the lazy brown dog.}

In the preceding, there's a rule that the closing brace must be on the
same line. This makes the parsing program much simpler. And for:

\beginMyMacro
One reason so many folks like OpenBSD is that it's solid. It works and
keeps working, without the little bugs and crashes of other
distributions and operating systems. And of course there's the security
angle, which is OpenBSD's forte.
\endMyMacro

In the preceding paragraph, \beginMyMacro and \endMyMacro occur on
their own line. Once again, a lot easier to parse.

It's not absolutely necessary to make these restrictions, but not
making them makes the conversion program harder to code.

>
> Otherwise, if both LaTeX and EPUB outputs are needed, and
> fine-grained control of the produced EPUB is wanted, using a
> well-defined intermediate markup language seems the safest
> way to go.  Oddly enough for me, markdown still appears to
> be the most common choice.  

Ex-Actly. I use Asciidoctor for the same purpose for the same reason.

> I would have thought that its
> caracteristics - semantically poor, with irregular and
> no-warnings “every text file accepted” permissive kind of
> syntax - would have made it unsuitable for maintaining long
> works.

I haven't actually used Markdown for this, but I researched it plenty
before settling on Asciidoctor. I think for a simple book with simple
formatting, Markdown would work beautifully. If you needed a
bibliography or if you needed to declare and use your own styles,
Markdown might prove insufficient.

SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

ian@
In reply to this post by Steve Litt
On Mon, Nov 04, 2019 at 02:06:35AM -0500, Steve Litt wrote:
>
> I know what you mean and you're right to a degree, but I'm currently
> writing a couple of books with AsciiDoctor edited in Vim. And I use
> VimOutliner for outlining. I'll try to remember and let you know when I
> actually finish one of the books.

I've used AsciiDoc and AsciiDoctor for two large O'Reilly Cookbooks which I
proof locally in PDF. Their publishing sofware puts it through some arcane
toolchain which formats to their house style &c, and generateds PDF, EPub,
HTML, etc.  But all the editing work is done, like Steve's, in vi and
asciidoctor.

I've also used adoc for magazine articles where the publisher "needs" the file
in MS-Word format. For that I use pandoc (on another box) to convert adoc into
docx.

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Ingo Schwarze
In reply to this post by U'll Be King of the Stars
Hi,

Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +0000:

[ Pandoc ]
> is one of the most useful tools I have ever used.  If you are writing
> any sort of documentation then I *highly* recommend checking it out

I strongly oppose that point.  There is no need at all to bother
with pandoc when you write documentation.  (It may be useful for
other purposes, i have no idea).

If you write documentation, just use the best format in the first
place.  If the project you are documenting allows checking in
documentation in mdoc(7) format, use that.  If the project also
wants to cater for systems not supporting formatting of mdoc(7)
documents (basically, system providing neither groff nor mandoc,
which more or less boils down to some old commercial UNIXes),
use mandoc(1) -T man at release tarball build time to produce
man(7) versions of the mdoc(7) files and ship them in the release
tarball, too.

If the project you want to document does not allow checking in mdoc(7)
files, write your documentation in perlpod(1).  The widely
available pod2man(1) tool converts perlpod(1) to high quality man(7)
output.  If, at some time, you want to upgrade to mdoc(7), the
pod2mdoc(1) tool helps a lot with that conversion.

If the project you want to document neither allows checking in
mdoc(7) nor perlpod(1) sources, write your documentation with
groff_man(7).  Doing that well is admittedly harder than writing
good mdoc(7) or perlpod(1) and results in somewhat lower output
quality, but it's not rocket science either.

Using any other format is a thoroughly bad idea.  The worst one
which you must avoid at all cost is DocBook, closely followed
by Markdown and related formats.

So, when talking about documentation, i have never encountered any
problem that even made me look at pandoc, and i'm working on
documentation a lot, including format conversions.

The fact that pandoc appears to not support the most important
documentation language, mdoc(7), at all, neither for input nor for
output, already makes me raise an eyebrow or two, but even if it
did, i still wouldn't see what it could possibly be useful for.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Marc Chantreux
hello,

> > is one of the most useful tools I have ever used.  If you are writing
> > any sort of documentation then I *highly* recommend checking it out
> I strongly oppose that point.  There is no need at all to bother
> with pandoc when you write documentation.  (It may be useful for
> other purposes, i have no idea).

yes ... what's the point of using another format than postscript
directly. also: using an high level language instead of
writing everything in assembly is a chance to lose control over what
you're writing. live is long enough to waste time ...

i would like to suggest 2 reasons to use pandoc (and the markdown format):
it will make the edition and the review of the document much more

* easier
* inclusive (people are able to read markdown format... but latex, html
  or troff is too much for lot of people)

that said: i'll really give troff a try again when i will figure out how
to create templates for the documents i need (as i said in a previous
message: i have a layout problem)

> The worst one
> which you must avoid at all cost is DocBook, closely followed
> by Markdown and related formats.

agree for docbook but can you explain us what's so wrong with keeping
simple things simple the way markdown allows us? i personally prefer
textile but markdown became kinda defacto wiki syntax standard with lot
of variations.

i really like to use human readable formats so markdown and yaml became
formats i use every day and enjoy it.

> So, when talking about documentation, i have never encountered any
> problem that even made me look at pandoc,

there is no problem with other formats but can't you admit that for many
people, something like

* denis
* brian
* doug

is easier to write, read and edit than << ?

<ul>
    <li>denis</li>
    <li>brian<li>
    <li>doug</li>
</ul>

also:

* transpiling is always a good thing to catch and avoid errors. for
  exemple: did you realize that the "brian" item is broken? this will
  not happen using a markdown as source
* the "proper" way to serialize an html/xml that is not intended to be
  edited isn't the way i write above but this below instead. and frankly
  i don't want to edit those kind of stuff

    <ul><li>denis</li><li>brian</li><li>doug</li></ul>

> The fact that pandoc appears to not support the most important
> documentation language, mdoc(7), at all, neither for input nor for
> output, already makes me raise an eyebrow or two

please contribute :)

also: the support of troff was removed from graphviz many years ago. how
sad is it?

> did, i still wouldn't see what it could possibly be useful for.

you don't have non technical colleagues, don't you ?

Sincerely

marc

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Oliver Marugg
In reply to this post by Ingo Schwarze
Hi Ingo

Many thanks for your inputs concerning older, but interesting tools
g/t-roff and refer(1). I didnt know them before.

-oliver

On 3 Nov 2019, at 16:41, Ingo Schwarze wrote:

> Hello,
>
> Xianwen Chen wrote on Sun, Nov 03, 2019 at 04:16:43PM +0100:
>
>> I am interested in giving _groff_ and _gpresent_ a try. I am seasoned
>> LaTeX user. Is there a tutorial that you would recommend to someone
>> like
>> me?
>
> No, i'm not aware of tutorials (but i generally don't use tutorials,
> so maybe i missed them).  But there is good reference documentation:
>
>   https://www.gnu.org/software/groff/manual/html_node/
>
> Gpresent is a macro package specifically for presentation slides.
> The documentation is in the groff_present(7) and presentps(1)
> manual pages in the textproc/gpresent package and in the groff_mm(7)
> manual page in the textproc/groff package.
>
>> Two things that come to my mind that I am concerned with.
>>
>> First, how does groff manage bibliography and citations?
>
> See the refer(1) utility in the textproc/groff package.
>
>> Second, peer-reviewed journals usually require submissions to be in
>> Word
>> format or in LaTeX. Is there an easy way to convert a groff document
>> to
>> a Word document or LaTeX?
>
> No, and there isn't even a complicated way either.  If your publisher
> requires LaTeX, use LaTeX; it's really that simple...
>
> Yours,
>   Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Raul Miller
In reply to this post by Marc Chantreux
On Tue, Nov 5, 2019 at 1:58 PM Marc Chantreux <[hidden email]> wrote:
> yes ... what's the point of using another format than postscript
> directly. ...

That's not a really question (nor does it fit here).

> that said: i'll really give troff a try again when i will figure out how
> to create templates for the documents i need (as i said in a previous
> message: i have a layout problem)

First mention of templates in this four dozen message thread.

What templates?

Thanks,

--
Raul

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Martin Schröder
In reply to this post by Roderick
Am Mo., 4. Nov. 2019 um 09:39 Uhr schrieb Roderick <[hidden email]>:
> TeX produces dvi, a well documented and simple page description language.
> Then it is transformed to postscript or pdf.

Nope. pdfTeX was developed 25 years ago, LuaTeX 12 years ago. Both
write PDF directly.

Best
    Martin

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Marc Chantreux
In reply to this post by Raul Miller
hello,

> > that said: i'll really give troff a try again when i will figure out how
> > to create templates for the documents i need (as i said in a previous
> > message: i have a layout problem)
>
> First mention of templates in this four dozen message thread.

i replied to this thread but as it was another branch, i changed the
subject and the "in reply to" is the id of the original author. sorry if
it wasn't the expected behavior.

https://marc.info/?l=openbsd-misc&m=157293688812513&w=2

> What templates?

template or macros: i don't know the good way to do it. the idea is to
have the layout used in my organization so i can generate some reports
using troff to generate pdf. this would be awesome but setting up a page
layout is out of my scope and i haven't found a didactic documentation
to just dive in the problem.

any help would be much welcome.

regards,
marc

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

U'll Be King of the Stars
In reply to this post by Ingo Schwarze
On 05/11/2019 17:38, Ingo Schwarze wrote:
> Hi,

Hello Ingo!

> Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +0000:
>
> [ Pandoc ]
>> is one of the most useful tools I have ever used.  If you are writing
>> any sort of documentation then I *highly* recommend checking it out
>
> I strongly oppose that point.  There is no need at all to bother
> with pandoc when you write documentation.

I think you shoud re-read that, especially the second sentence.  Do you
realize how ridiculous it is?

Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Chris Bennett-4
In reply to this post by Marc Chantreux
On Tue, Nov 05, 2019 at 07:56:03PM +0100, Marc Chantreux wrote:

>
> there is no problem with other formats but can't you admit that for many
> people, something like
>
> * denis
> * brian
> * doug
>
> is easier to write, read and edit than << ?
>
> <ul>
>     <li>denis</li>
>     <li>brian<li>
>     <li>doug</li>
> </ul>
>
> also:
>
> * transpiling is always a good thing to catch and avoid errors. for
>   exemple: did you realize that the "brian" item is broken? this will
>   not happen using a markdown as source
> * the "proper" way to serialize an html/xml that is not intended to be
>   edited isn't the way i write above but this below instead. and frankly
>   i don't want to edit those kind of stuff
>
>     <ul><li>denis</li><li>brian</li><li>doug</li></ul>
>
> > The fact that pandoc appears to not support the most important
> > documentation language, mdoc(7), at all, neither for input nor for
> > output, already makes me raise an eyebrow or two

Vim has many useful HTML plugins (or write your own)
The above list require two keystrokes and a number of list items wanted
in one plugin I have barely started to use.

A print CSS file can do a tremendous amount of formatting useful for
printed documents.

* brian
Has no formatting. Once again, we are talking ed(1). Followed by a
formatter. I use vim on my laptop and ed(1) on my phone. It works.
I detest Libreoffice. I have never yet gotten it to do anything I
needed.

But to each their own. Overall, this thread has been very enlightening
for me. I do need to learn some other methods. TeX and LaTeX keep coming
up everywhere I look.

Have fun,
Chris Bennett


Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Marc Chantreux
> > > documentation language, mdoc(7), at all, neither for input nor for
> > > output, already makes me raise an eyebrow or two

> Vim has many useful HTML plugins (or write your own)

yes ... but why should i bother with an uggly distracting format when
i can have a format that is close visually to the idea i have in mind
(a list). also i made other points that aren't adressed by vim plugins.

> The above list require two keystrokes and a number of list items wanted
> in one plugin I have barely started to use.

yet another plugin to install, maintain and learn when i can rely on
external commands i can use in other contexts;

> A print CSS file can do a tremendous amount of formatting useful for
> printed documents.

what if you want to use music cheets, chemical structures, good looking
math formula or other material. latex comes with tikz, beamer, qtree,
all those things that makes good looking printed documents much easier
to produce ...

html is when i need interactivity or animation but it's always a
painful process to me. but the point of using markdown remains:

* brian
* ken
* doug

is easier to write, read and edit than

\begin{itemize}
\tightlist
\item
  brian
\item
  ken
\item
  doug
\end{itemize}

or

<ul>
<li>brian</li>
<li>ken</li>
<li>doug</li>
</ul>

> I detest Libreoffice. I have never yet gotten it to do anything I
> needed.

so do i: i was interested by arguments against markdown.

> But to each their own. Overall, this thread has been very enlightening
> for me. I do need to learn some other methods. TeX and LaTeX keep coming
> up everywhere I look.

i have to admit i started using both html and latex at the same time and
prefered html at the begining. but with time, latex is much more
rewarding when it comes to printed docs.

the only format that made me really unhappy for the moment is troff but
i still hope i'll have fun with it at some point.

regards
marc


Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Ingo Schwarze
In reply to this post by Marc Chantreux
Marc Chantreux wrote on Tue, Nov 05, 2019 at 07:56:03PM +0100:

> can you explain us what's so wrong with keeping
> simple things simple the way markdown allows us?

https://undeadly.org/cgi?action=article&sid=20170304230520

The following presentation also contains a few related remarks
on pages 32-34, especially on page 33:

https://www.openbsd.org/papers/bsdcan18-mandoc.pdf

Nothing is wrong with trying to make things simple for users, quite
to the contrary.  But that is not an excuse for delivering solutions
that are technically abominable.  When a language is technically
as ill-designed as markdown is, the multitude of resulting traps
actually makes it very hard to use, *not* easy at all.

Yours,
  Ingo


 $ mandoc -mdoc -T ascii
.Bl -bullet -compact
.It
Cynthia
.It
Werner
.It
Kristaps
.El
^D
UNTITLED                             LOCAL                            UNTITLED

o   Cynthia
o   Werner
o   Kristaps

                               November 6, 2019

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Steve Litt
On Tue, 5 Nov 2019 23:12:52 +0100
Ingo Schwarze <[hidden email]> wrote:

 
> https://www.openbsd.org/papers/bsdcan18-mandoc.pdf

If the preceding presentation was authored in mdoc(7), could  you please
post the mdoc code that created it, and the mandoc(1) command and any
filter programs that caused it to be a presentation instead of a man
page?

Thanks,
 
SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Steve Litt
In reply to this post by Ingo Schwarze
On Tue, 5 Nov 2019 18:38:03 +0100
Ingo Schwarze <[hidden email]> wrote:

> Hi,
>
> Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +0000:
>
> [ Pandoc ]
> > is one of the most useful tools I have ever used.  If you are
> > writing any sort of documentation then I *highly* recommend
> > checking it out  
>
> I strongly oppose that point.  

I'm not a fan of pandoc either. It's a little too black-boxy for my
taste.

> There is no need at all to bother
> with pandoc when you write documentation.  (It may be useful for
> other purposes, i have no idea).
>
> If you write documentation, just use the best format in the first
> place.  If the project you are documenting allows checking in
> documentation in mdoc(7) format, use that.  

TL/DR SUMMARY: mdoc(7) is cool, but based on an hour or so's research is
insufficient for all but the simplest full length books.

I've spent the last hour or so looking at man pages mandoc(1) and
mdoc(7), and I currently don't see how a non-simple book could be
authored in mdoc(7). First of all, I see no method of creating a header
hierarchy like <h1>...<h6> or \part ... \subparagraph . I'd suspect it
could be done by nesting .Sh lines, but I couldn't see how that could
be done.

As far as I can tell, mdoc(7) has no way to declare arbitrary styles.
If I want a style called "stories", as an author I should be able to use
one, and worry about semantic to presentational conversion of the
stories style to be something I make later (with CSS or LaTeX or
whatever). Almost by definition, if I can't create new semantic styles,
I'll need to use or reuse predefined ones, which introduces ambiguity
and mixing of semantic and presentational.

Kudos for provisions to make a bibliography, and a TOC in HTML output.

mdoc(7) supported lists cover a wide variety of presentations, but as
far as I can tell you can't make new kinds of lists based on the
existing lists. For instance, I might have a list for people with
vertical spacing very different from a list for concepts, and I see no
way to do that in mdoc(7) without declaring that all people are done
with one kind of mdoc(7) list, and all concepts are done with another.
Another problem: If I initially do both people and concepts with a
certain mdoc(7) list type, and then decide people should look
different, I'd have to search out all the people, instead of changing
one line of CSS or one line of LaTeX.

Based on my hour or so research, I don't understand how mdoc(7) would
be a good authoring format for anything but the simplest book length
document. If I'm wrong, I might start writing my books in mdoc(7).

SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Reply | Threaded
Open this post in threaded view
|

Re: Tools for writers

Xiánwén Chén
In reply to this post by Ingo Schwarze
Dear Ingo,

> The following presentation also contains a few related remarks
> on pages 32-34, especially on page 33:
>
> https://www.openbsd.org/papers/bsdcan18-mandoc.pdf

I read through the entire presentation for the sake of seeing what kind
of presentation mdoc could produce. The presentation looked nice.

Could I have a copy of the source text file of the presentation and the
command line(s) that produced the PDF file?

Yours sincerely,
Xianwen

1234