Re: Tools for writers
On Wed, 6 Nov 2019 15:36:42 + Oliver Leaver-Smith wrote: > Thanks everyone for recommendations, I think I am just going to use > VimOutliner for development and outlining. The use case I have is for > a novel which should require less formatting than a technical book, > so I should be able to retrofit that after once I have investigated > the many tools mentioned in the thread. If you can't find a VimOutliner to LaTeX converter, let me know, because I have a very rudimentary one that "does the right thing" for all heading hierarchy elements, and for body text. Obviously, you'll need to create a separate file that maps indent level to Part/Chapter/Section/Subsection ... because not all LaTeX files use the same hierarchy. Note also that this is a one-way trip: The instance you start modifying the text you're pretty much stuck in LaTeX. My converter requires you to create an empty doc with the correct headings, etc, the correct document preamble, and the final \bye. Doing the same thing for XHTML is trivial. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: Tools for writers
Joe Davis wrote >> Some writers swear on Scrivener. It's proprietary and Mac/Win only, >> though. > > Manuskript[1] looks promising as a foss alternative. Haven't attempted > to build it on OpenBSD. None of the dependencies look to be a major > problem. > > Cheers, > Joe > > [1]: http://www.theologeek.ch/manuskript/ This looks really interesting. Thanks for sharing, Joe. -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Tools for writers
> Some writers swear on Scrivener. It's proprietary and Mac/Win only, though. Manuskript[1] looks promising as a foss alternative. Haven't attempted to build it on OpenBSD. None of the dependencies look to be a major problem. Cheers, Joe [1]: http://www.theologeek.ch/manuskript/
Re: Tools for writers
On 2019-11-02 11:14, Peter Nicolai Mathias Hansteen wrote: 2. nov. 2019 kl. 16:00 skrev Oliver Leaver-Smith : What tools do people find useful for writing on OpenBSD? By writing I mean long form such as novels and technical books, including plot and character development, outlining, and formatting for publishing (not all the same application necessarily) I have found a number which boast Linux support, but not really anything that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) I really can’t speak to plot and character development, but all three editions of The Book of PF were written using OpenOffice and later LibreOffice write on OpenBSD snapshots. Earlier versions of that manuscript were developed using DocBook SGML (editing with emacs), but the publisher (fortunately) did not want any truck with that. For any new projects I would likely look half-heartedly for something markdown based but would probably end up going the LibreOffice route again. FWIW, Brian Kernighan's new book was written using groff(1), with final rasterization done by gs(1), obviously there's a number of other tools involved. On the other hand, unless you name is Brian Kernighan (or possibly Kristaps, Ingo, or jmc@) I doubt that toolset will satisfy you :-). A few people around here have used TeX, LaTeX, and LyX (a LaTeX front-end) all of which are very much capable of large projects split into sections/chapters/etc. AFAIK OpenBSD's LaTeX / TeX packages are all more than adequate to the task, and all of the necessary tools are in ports. -Adam
Re: Tools for writers
Am Sa., 2. Nov. 2019 um 16:06 Uhr schrieb Oliver Leaver-Smith : > What tools do people find useful for writing on OpenBSD? By writing I mean > long form such as novels and technical books, including plot and character > development, outlining, and formatting for publishing (not all the same > application necessarily) Some writers swear on Scrivener. It's proprietary and Mac/Win only, though. Best Martin
Re: Tools for writers
On Wed, 6 Nov 2019, Oliver Leaver-Smith wrote: The use case I have is for a novel which should require less formatting than a technical book, so I should be able to retrofit that after once I have investigated the many tools mentioned in the thread. Plain TeX would mean in that case a simple text file with few formatting tags, for example for italics and boldface. Then you can generate a postcript file with tex and dvips commands and print it, if you want. Later you can perfectionate it. To read the first pages of "The TeXBook" would be enough for the beginning, and you find a pdf version googling for it. nroff is interesting, because is a unix standard from the beginning and (in the meantime only almost) everywhhere, but is more complicated to learn, the source less readable, and the result not better. Rodrigo
Re: Tools for writers
Hi, As an alternative to LaTeX, especially if you design the book, you may give ConTeXt a chance. Just several elements of comparison with LaTeX Cons: * quite hard learning-curve * documentation is hard to find a the beginning. The reference manual is not maintained any more. Things are however better than three years ago: the ConTeXt excursion book has been updated. Official documentation is now split into manuals dealings with specific issues (tables, biblio, XML and so on). * ConTeXt is a niche even inside the *TeX world. * Publishers usually ask for LaTeX. * You have to design your layout from scratch (no documentclass shiped, only paper format) Pros: * you don't need to upload packages, and check for incompabilities. I have been using it a lot for three years now, and never loaded any third-part module. * bibliography out of the box, which is great since I could'nt have biber working on OpenBSD. * metapost graphics out of the box. MP graphics compile faster than TikZ since there are tightly integrated with base code (the user base is however much smaller than TikZ) * its key-value syntax is quite predictible, once you're used at it. * you can have XML and EPUB output (default is PDF) * smaller base than LaTeX if you install it as a standalone (260M, mostly because of fonts). I could'nt manage to install the Mkiv standalone version (being too stupid to patch its install script), but Hans Hagen released a distribution of luametatex, the development version of ConTeXt, a few weeks ago and it is available for OpenBSD. http://www.pragma-ade.com/install.htm Troubles with pdf inclusions can be bypassed uploading those luametatex binaries after installation http://dl.contextgarden.net/build/luametatex/amd64-openbsd6.6/luametatex Regards, Damien Thiriet
Re: Tools for writers
Thanks everyone for recommendations, I think I am just going to use VimOutliner for development and outlining. The use case I have is for a novel which should require less formatting than a technical book, so I should be able to retrofit that after once I have investigated the many tools mentioned in the thread. -ols -- Oliver Leaver-Smith +44(0)114 360 1337 TZ=Europe/London
Re: Tools for writers
On Tue, Nov 05, 2019 at 06:38:52PM -0500, Steve Litt wrote:
> > 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 ... 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.
Declaring arbitrary styles and semantics while being able to
produce HTML/EPUB and LaTeX was the main point of frundis.
I'll therefore provide some small examples, so that you may
research more if you want.
For example, you can define semantic tags for each format:
.X mtag -f latex -t people -c emph
.X mtag -f xhtml,epub -t people -c em
and then using them like:
.Sm -t people Steve
which will be rendered as Steve in
html, and \emph{Steve} in LaTeX.
There are different kind of semantic tags, whether for
phrasing elements or block/environment elements. The
language provides common semantic elements for novels (4
header levels, TOC, links, cross-references), but it lacks
more advanced functionality, like built-in bibliographies.
When built-in functionality is not enough, you can wrap
LaTeX and HTML code with macros. For example, you can write
the following macro hr in a file macros.frundis:
.#de hr \" define macro hr
.P
.Bf -f xhtml \" when exporting to HTML
.Ef
.Bf -f latex \" when exporting to LaTeX
\erule{\etextwidth}{1pt}
.Ef
.P
.#. \" end of definition
Then you can use it in your main file:
.If macros.frundis \" include macro definitions
.hr
If this kind of extensibility sounds like enough for what
you need, you may have a look at the whole mdoc(7) man page
frundis_syntax(5):
https://bardinflor.perso.aquilenet.fr/frundis/frundis_syntax-5.html
That said, if your books are too technical, you may end up
needing to extend yourself the language too much. Or maybe
you'll hit some unexpected limitations that will probably
not disappear with time, as the language is feature complete
for its main intended usage.
Yon
Re: Tools for writers
Hi, On Wed, Nov 06, 2019 at 08:43:18AM +0100, Ingo Schwarze wrote: > Hi Steve, > > Steve Litt wrote on Tue, Nov 05, 2019 at 06:38:52PM -0500: > > On Tue, 5 Nov 2019 18:38:03 +0100 > Ingo Schwarze wrote: > >> Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: > > >> [ 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. > > Admittedly, this was a bit of a diversion because the OP asked about > long, general-purpose texts like books - but all the same, it didn't > want to let the statement "pandoc is recommended for *documentation*" > go unchallenged. In my opinion, most of the points you made in the OpenBSD Journal apply for novels too, and probably even more so for technical books, but I can only judge for the first. The fact that markdown is not semantic, but essentially presentational, makes it impossible to make formatting changes to a whole semantic category after the fact (e.g. plant name, song title, place name), and impossible to automatically extract that information from the file for various purposes. A fully featured apropos(1) is not required for novels, but it's handy to at least be able to extract a list of names from a specific semantic category, whether to check it's correct, or to display it somewhere else (like an index). It's also handy when translating a work, to compare the original and translated version on specific points, often catching mistakes. But maybe the worst consequence of the markdown pitfalls you mention, is that it cannot provide any kind of syntax error reporting. Markup languages have different needs than programming languages. For example favouring warnings (like you did for mandoc(1)) is generally better than fatal errors (like often LaTeX). But no warnings (like markdown) is worse than both. Some people seem to think syntax highlighting is enough to avoid formatting mistakes, but you cannot depend on it when reading a diff, for example. And anyways, it's still easy to overlook a small formatting error. In my opinion, most of mandoc(1) design philosophy is worth considering for non-documentation long works: diff and grep-friendly simple non-ambiguous syntax, good non-fatal warnings, mostly semantic and fast. All of this seems good for any big project. When designing frundis(1) for novels, it's been my main inspiration, though it falls short on one point: due to the unpredictable requirements of creative works, it's been simpler (unavoidable?) to not make it fully self-contained. At least, new macros can abstract target format specific parts and make it fully-contained per project, which is still better than markdown. For long technical books, I don't think there's still anything approaching what mandoc(1) is for documentation. LaTeX and groff are good, but not semantic enough (making non-PDF exports tricky), have a quite fragile syntax at times and, in my experience, are not great at error reporting - which may be because of current tools instead of the languages themselves, though. Yon
Re: Tools for writers
> With the exception of perlpod(1)/pod2man(1), most programs that good to know as i'm really confortable with pod. > page formatting. scdoc(1) is not an exception; the output code > quality is poor indeed > * stray .P before and after .SH > ... this list is really interesting. maybe it should be shared with the scdoc project. it will not solve the problems but at least those ones can be fixed. > To summarize, there wasn't any need for yet another man(7) > autogenerator, perlpod(1) already existed, and while most man(7) > autogenerators are bad, this one may even be producing below-average > quality. my opinion is more blur: using a tool that works find is important but i'm always happy when i can remove a usage of an interpreted langage (even perl which was by far my prefered one before i started to use raku). > Do not use it. i wasn't even wanting to: this one was mostly a joke to tickle you then it ends up to a really interesting and constructive answer. thanks a lot. marc
Re: Tools for writers
Hi Marc, Marc Chantreux wrote on Wed, Nov 06, 2019 at 08:42:28AM +0100: > let me ruin your day: are you aware of scdoc? > https://git.sr.ht/~sircmpwn/scdoc Yes, i think i tripped over it before, once. > i really appreciated reading about you opinion. thank you. I think the basic idea is a thoroughly bad one: targetting man(7) as an output language is already a dubious choice. On the one hand, man(7) can be considered an ancient, obsolete language. It was the state of the art from 1979 to about 1990 and has now been obsolete for almost three decades. Admittedly, there are still unusual circumstances where you need it, not listing them here. But in that case, it can and should be written by hand. Yes, it is more difficult than mdoc(7) or perlpod(1) to write, but not all *that* hard, so a wrapper language is not really needed. With the exception of perlpod(1)/pod2man(1), most programs that autogenerate man(7) code produce low-quality output, so usually, using a preprocessor is a bad idea because you get poor manual page formatting. scdoc(1) is not an exception; the output code quality is poor indeed: * stray .P before and after .SH * incorrect usage of plain "-" in NAME line * weird ALL CAPS formatting for .SS * failure to use font macros, using font escapes instead * stray .P inside .RS/.RE * incorrect use of plain "-" for \(em * violation of "new sentence, new line" * missing double space after full stop * EXTREMELY poor formatting of bullet lists, totally failing to use .TP or .IP in nroff output mode, instead resorting to plain .nf * TERRIBLE gratuitions use of .ie n for lists with manual negative \h that doesn't even work reliably in a portable way; while it does work with groff(1), it doesn't with mandoc(1) or other formatters * relies on tbl(7) for tables, but without giving any instructions to the subsequent formatter to run the tbl(1) preprocessor; while that works with mandoc(1), it is not portable and fails by default even with groff(1) * produces UTF-8 characters embedded in man(7) code instead of properly encoding them as documented in groff_char(7) and mandoc_char(7); while that works with mandoc(1), it is not portable and fails by default even with groff(1) There may be more problems with it, this list is just from one very brief glance at the man(7) output generated from the scdoc.5.scd manual page itself. To summarize, there wasn't any need for yet another man(7) autogenerator, perlpod(1) already existed, and while most man(7) autogenerators are bad, this one may even be producing below-average quality. Besides, several of the points i made against Markdown appear to apply to scdoc just as well (or rather, just as badly), in particular context sensitivity/ambiguity, purely presentational markup and lack of semantic markup, lack of language independence... Do not use it. Yours, Ingo
Re: Tools for writers
Hi Steve, Steve Litt wrote on Tue, Nov 05, 2019 at 06:38:52PM -0500: > On Tue, 5 Nov 2019 18:38:03 +0100 > Ingo Schwarze wrote: >> Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: >> [ 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. Admittedly, this was a bit of a diversion because the OP asked about long, general-purpose texts like books - but all the same, it didn't want to let the statement "pandoc is recommended for *documentation*" go unchallenged. [ mdoc(7) ] > no method of creating a header hierarchy like ... > I'd suspect it could be done by nesting .Sh lines, No, .Sh does not nest at all. > no way to declare arbitrary styles. > can't make new kinds of lists That's all perfectly true. The mdoc(7) macro set serves a very narrow domain: documentation, i.e. manual pages. It's intentionally neither configurable nor extensible. The goal is to enforce a uniform style on manual pages, optimized for simplicity, conciseness, and clarity, but without manual page authors having to worry about the styling at all, in fact not even allowing authors to mess with that uniform style of manual pages, such that all pages follow the same conventions and readers can quickly become familiar with these conventions. > If I'm wrong, I might start writing my books in mdoc(7). Please don't even try. Writing a book in mdoc(7) is completely impossible for lots and lots of reasons. For a book, i guess that the groff_mom(7) macro set might be useful. Yours, Ingo
Re: Tools for writers
hello, > https://www.openbsd.org/papers/bsdcan18-mandoc.pdf which leds me to the conference video. it was really interesting. > 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. ok. now i get your honorable point but the lazy part of me will take its part of abomination to get things done in a pleasant way :) also: i didn't dive that much in pandoc code but from what i saw: even a non-fluent haskell person which i am can read this code. > 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. well ... i really think this is a bias because i really think markdown is so easy to use it popularized the use of wiki syntaxes (which mean less use of wysiwyg tools ... which is more abominable). let me ruin your day: are you aware of scdoc? https://git.sr.ht/~sircmpwn/scdoc i really appreciated reading about you opinion. thank you. regards marc
Re: Tools for writers
Hi, Martijn van Duren wrote on Wed, Nov 06, 2019 at 06:40:51AM +0100: > On 11/6/19 12:07 AM, Steve Litt wrote: >> On Tue, 5 Nov 2019 23:12:52 +0100 >>> 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? > You mean this one? > https://www.openbsd.org/papers/bsdcan18-mandoc.roff Exactly. Note that it does not use mdoc(7), though, but textproc/gpresent (groff_present(7)) on top of groff_mm(1) and roff(7). The mdoc(7) macro set has a very narrow scope: documentation. It isn't adequate for anything else, in particular neither presentations nor books nor even short journal articles. On the other hand, roff(7) can be used for any kind of typesetting, usually with one of the other macro sets. The most modern and most actively maintained of the general purpose macro sets is Peter Schaffter's groff_mom(7). Also note that i did not say pandoc is useless; all i intended to say is that if you need to write documentation, *that* is not a good reason to look at pandoc - merely because somebody on this list recommended pandoc specifically for writing documentation, which seems very misleading to me. > There are more examples at: > https://www.openbsd.org/events.html True. When it comes to gpresent, examples are arguably easier to find in this shorter list: http://mandoc.bsd.lv/press.html Yours, Ingo
Re: Tools for writers
On 11/6/19 12:07 AM, Steve Litt wrote: > On Tue, 5 Nov 2019 23:12:52 +0100 > Ingo Schwarze 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? You mean this one? https://www.openbsd.org/papers/bsdcan18-mandoc.roff There are more examples at: https://www.openbsd.org/events.html martijn@
Re: Tools for writers
Dear Ingo, > Could I have a copy of the source text file of the presentation and the > command line(s) that produced the PDF file? I found it: https://www.openbsd.org/papers/eurobsdcon2018-mandoc.roff Yours sincerely, Xianwen
Re: Tools for writers
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
Re: Tools for writers
On Tue, 5 Nov 2019 18:38:03 +0100 Ingo Schwarze wrote: > Hi, > > Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: > > [ 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 ... 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
Re: Tools for writers
On Tue, 5 Nov 2019 23:12:52 +0100 Ingo Schwarze 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
Re: Tools for writers
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=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 LOCALUNTITLED o Cynthia o Werner o Kristaps November 6, 2019
Re: Tools for writers
> > > 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
brian
ken
doug
> 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
Re: Tools for writers
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 << ? > > > denis > brian > doug > > > 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 > > denisbriandoug > > > 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
Re: Tools for writers
On 05/11/2019 17:38, Ingo Schwarze wrote: Hi, Hello Ingo! Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: [ 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
Re: Tools for writers
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=157293688812513=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
Re: Tools for writers
Am Mo., 4. Nov. 2019 um 09:39 Uhr schrieb Roderick : > 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
Re: Tools for writers
On Tue, Nov 5, 2019 at 1:58 PM Marc Chantreux 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
Re: Tools for writers
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
Re: Tools for writers
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 << ? denis brian doug 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 denisbriandoug > 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
Re: Tools for writers
Hi, Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: [ 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
Re: Tools for writers
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 , 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.
Re: Tools for writers
On Mon, 4 Nov 2019 09:07:13 +
Yon 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
Re: Tools for writers
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 Campbellhttp://www.acampbell.uk
Re: Tools for writers
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 Campbellhttp://www.acampbell.uk
Re: Tools for writers
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
Re: Tools for writers
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.
Re: Tools for writers
Texlive is great if you're certain your output will be now and forever only in PDF format. 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. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr On Sat, 2 Nov 2019 09:35:42 -0700 Justin Noor wrote: > Mr. Hansteen what are your thoughts on Texlive? > > On Sat, Nov 2, 2019 at 9:16 AM Peter Nicolai Mathias Hansteen < > pe...@bsdly.net> wrote: > > > > > > > > 2. nov. 2019 kl. 16:00 skrev Oliver Leaver-Smith > > > : > > > > > > What tools do people find useful for writing on OpenBSD? By > > > writing I > > mean long form such as novels and technical books, including plot > > and character development, outlining, and formatting for publishing > > (not all the same application necessarily) > > > > > > I have found a number which boast Linux support, but not really > > > anything > > that stands out which supports OpenBSD (aside from the obvious > > LaTeX et al.) > > > > I really can’t speak to plot and character development, but all > > three editions of The Book of PF were written using OpenOffice and > > later LibreOffice write on OpenBSD snapshots. > > > > Earlier versions of that manuscript were developed using DocBook > > SGML (editing with emacs), but the publisher (fortunately) did not > > want any truck with that. > > > > For any new projects I would likely look half-heartedly for > > something markdown based but would probably end up going the > > LibreOffice route again. > > > > — > > Peter N. M. Hansteen, member of the first RFC 1149 implementation > > team http://bsdly.blogspot.com/ http://www.bsdly.net/ > > http://www.nuug.no/ "Remember to set the evil bit on all malicious > > network traffic" delilah spamd[29949]: 85.152.224.147: disconnected > > after 42673 seconds. > > > > > > > > > >
Re: Tools for writers
On Sat, 2 Nov 2019 15:16:22 -0400 STeve Andre' wrote: > On 2019-11-02 15:07, Antoine Jacoutot wrote: > > On Sat, Nov 02, 2019 at 03:04:34PM -0400, STeve Andre' wrote: > >> > >> > >> On 2019-11-02 11:00, Oliver Leaver-Smith wrote: > >>> Hello, > >>> > >>> What tools do people find useful for writing on OpenBSD? By > >>> writing I mean long form such as novels and technical books, > >>> including plot and character development, outlining, and > >>> formatting for publishing (not all the same application > >>> necessarily) > >>> > >>> I have found a number which boast Linux support, but not really > >>> anything that stands out which supports OpenBSD (aside from the > >>> obvious LaTeX et al.) > >>> > >>> Mich appreciated > >>> > >>>~ols > >>> -- > >>> Oliver Leaver-Smith > >>> +44(0)114-360-1337 > >>> TZ=Europe/London > >>> > >> > >> /usr/bin/vi > > > > You obviously never wrote a book. > > At least not with the requirements OP asked for. > > > Actually, I am, right now. I've found that "formatting" is an > annoyance, when writing material. Get it written, *then* worry > about how it looks. I've done this for more than 40 years when > creating documents, reports and such for work. 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. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: Tools for writers
On Sun, 3 Nov 2019 18:50:56 + (UTC) Roderick 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
Re: Tools for writers
On Sat, 2 Nov 2019 20:07:39 +0100 Antoine Jacoutot wrote: > On Sat, Nov 02, 2019 at 03:04:34PM -0400, STeve Andre' wrote: > > > > > > On 2019-11-02 11:00, Oliver Leaver-Smith wrote: > > > Hello, > > > > > > What tools do people find useful for writing on OpenBSD? By > > > writing I mean long form such as novels and technical books, > > > including plot and character development, outlining, and > > > formatting for publishing (not all the same application > > > necessarily) > > > > > > I have found a number which boast Linux support, but not really > > > anything that stands out which supports OpenBSD (aside from the > > > obvious LaTeX et al.) > > > > > > Mich appreciated > > > > > > ~ols > > > -- > > > Oliver Leaver-Smith > > > +44(0)114-360-1337 > > > TZ=Europe/London > > > > > > > /usr/bin/vi > > You obviously never wrote a book. > At least not with the requirements OP asked for. 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. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr
Re: Tools for writers
On 2019-11-02 18:29, Ingo Schwarze wrote: Hi Jordan, Jordan Geoghegan wrote on Sat, Nov 02, 2019 at 05:44:23PM -0700: I've thought about learning latex and mandoc and all the fancy tools, but I've just never gotten around to it. Actually, both mandoc(1) and mdoc(7) are off-topic in this thread. You cannot use either for writing a book, neither the mdoc(7) language nor the mandoc(1) program supports any of the important features. Woops, I got pandoc and mandoc confused. That said, the obvious answer for the OP is of course the "textproc/groff" port (disclosure: which i maintain). The roff(7) language and the troff programm is what people in the UNIX world always used for writing books and journal articles, and it is very much alive even after the roff language celebrated its 55th birthday this year. I'm in the habit of using it to prepare slides for conference talks (with textproc/gpresent), for example, and i'm not the only only one. [snip] As long as you only *use* macro packages, groff is *much* easier to use than LaTeX (not least because the quality of documentation of groff is vastly superior to LaTeX, and LaTeX documentation is so extremely huge and fragmented that it's a terrible challenge to find anything you need). [snip] Most certainly, it is *much* easier to get good typography out of groff or LaTeX (no matter which one) than out of LibreOffice or any similar abomination. Yours, Ingo Thanks for the recommendation Ingo, I'm going to test out groff for a writing project I have coming up. Cheers, Jordan
Re: Tools for writers
Maybe have a look at Asciidoctor[1]. It's a plain text markup language and fast parser/converter with ruby as its sole dependency. The language is easy to write, very easy to read and doesn't get in your way. It's similar to Markdown but much more potent, well-rounded and extensible if necessary. It was born as a replacement for reStructeredText and is very well suited for writing technical documentation or books. I use it specifically because I can just write a plain text document and worry about output formatting and everything else later, all while having the confidence that the output formatting will be doable with reasonable effort. In the beginning of trying it out, I used the firefox plugin from the same project which converts documents on the fly into HTML to get a sense of what the output will look like. (Asciidoctor is not to be confused with Asciidoc, which is the predecessor project but seems abandoned.) Fred [1]: https://asciidoctor.org Am 2019-11-02 16:00, schrieb Oliver Leaver-Smith: Hello, What tools do people find useful for writing on OpenBSD? By writing I mean long form such as novels and technical books, including plot and character development, outlining, and formatting for publishing (not all the same application necessarily) I have found a number which boast Linux support, but not really anything that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) Mich appreciated ~ols -- Oliver Leaver-Smith +44(0)114-360-1337 TZ=Europe/London
Re: Tools for writers
Dear Mr. Péter, Thank you! > I installed it via cabal, but you need a little workaround, since a W^X > allowed partition is required for the build There are some articles > online which I followed and created a cabal directory in /usr/local > (which is wxallowed) and mounted it in my $HOME as ‘.cabal’ (as opposed > to mounting /home as wxallowed). I may try it later! Great tips! Yours sincerely, Xianwen
Re: Tools for writers
Xianwen Chen (陈贤文) [2019-11-03 13:44:20 +0100]: > Does _pandoc_ work on OpenBSD now? I can confirm that pandoc works on OpenBSD as I have built it a few months ago. However, it wasn't a painless procedure. I installed it via cabal, but you need a little workaround, since a W^X allowed partition is required for the build There are some articles online which I followed and created a cabal directory in /usr/local (which is wxallowed) and mounted it in my $HOME as ‘.cabal’ (as opposed to mounting /home as wxallowed). Regards, Bertalan -- Bertalan Z. Péter FB9B 34FE 3500 3977 92AE 4809 935C 3BEB 44C1 0F89 /"\ \ /ASCII Ribbon Campaign X against HTML email & proprietary attachments / \www.asciiribbon.org
Re: Tools for writers
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
Re: Tools for writers
On Sun, 3 Nov 2019, Ingo Schwarze wrote: And finally, the only thing that is seriously wrong with the "print/texlive" port is how ridiculously large it is. That is "texlive". Donald Knuths TeX/mf is exactly the opposite to bloat.
Re: Tools for writers
Right. Thank you very much! Ingo Schwarze writes: > 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
Re: Tools for writers
> My substitute for _pandoc_ is the _org-mode_ of emacs, which is for some > people also good for outlining etc. if i quit using vim some day, it will be for something lightweight so i'll never run emacs, i guess. regards marc
Re: Tools for writers
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
Re: Tools for writers
Dear Mr. Schwarze, > That said, the obvious answer for the OP is of course the > "textproc/groff" port (disclosure: which i maintain). The roff(7) > language and the troff programm is what people in the UNIX world > always used for writing books and journal articles, and it is very > much alive even after the roff language celebrated its 55th birthday > this year. I'm in the habit of using it to prepare slides for > conference talks (with textproc/gpresent), for example, and i'm not > the only only one. 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? Two things that come to my mind that I am concerned with. First, how does groff manage bibliography and citations? 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? Yours sincerely, Xianwen
Re: Tools for writers
On Sun, Nov 03, 2019 at 01:44:20PM +0100, Xianwen Chen (陈贤文) wrote: > Dear Marc, > > > I wasn't talking about mandoc but pandoc (https://pandoc.org/): you > > write most of the things just using markdown format and add latex > > instructions whenever you want. this way, you keep simple things simple > > but you keep the power of latex under the wood. > > Does _pandoc_ work on OpenBSD now? I have built Pandoc on OpenBSD a couple of times: latest was in 2017. However, it can be sensitive to the GHC version used, and I have not bulit it using Stack. There are people who report building it in 2018, after some tweaking. https://github.com/jgm/pandoc/issues/4940 > > Yours sincerely, > Xianwen > Sincerely
Re: Tools for writers
Dear Mr. Chantreux, > i realized i haven't try on BSD as my desktop remains a linux for the > moment. sorry i lost the focus because of this very appealing thread. My substitute for _pandoc_ is the _org-mode_ of emacs, which is for some people also good for outlining etc. But I miss _pandoc_. Yours sincerely, Xianwen
Re: Tools for writers
hello, > Does _pandoc_ work on OpenBSD now? i realized i haven't try on BSD as my desktop remains a linux for the moment. sorry i lost the focus because of this very appealing thread. regards marc
Re: Tools for writers
On 03/11/2019 12:44, Xianwen Chen (陈贤文) wrote: Does _pandoc_ work on OpenBSD now? Pandoc doesn't work on OpenBSD? This is seriously a bit of a shock. It 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 on a platform where is does work. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Tools for writers
Dear Marc, > I wasn't talking about mandoc but pandoc (https://pandoc.org/): you > write most of the things just using markdown format and add latex > instructions whenever you want. this way, you keep simple things simple > but you keep the power of latex under the wood. Does _pandoc_ work on OpenBSD now? Yours sincerely, Xianwen
*roff and page layout ? (Re: Tools for writers)
> the "print/texlive" port is how ridiculously large it is. because it comes with the whole distribution. i never tested but https://tectonic-typesetting.github.io/ seems to fix it by downloading stuff on demand. however, another problem with tex is performance. troff is blazing fast. however... > "textproc/groff" port (disclosure: which i maintain). The roff(7) > The "textproc/heirloom-doctools" port is a serious contender for a ... i tried nroff long time ago so i tried to create templates for memos and letters with layouts where: A is company logo and info B is for metainfo about the current letter C is the actual body ┌─┐┌─┐ │A││B│ └─┘└─┘ ┌┐ │ C │ └┘ ┌─┐┌─┐ │A││C│ │B││ │ │ ││ │ │ ││ │ └─┘└─┘ i tried both of those (you can achieve this with latex minipages) but i never made it work so i gave out. did i miss a fine didactic documentation about it ? regards marc ps: i think it was the plan9 troff, > documentation of groff is vastly superior to LaTeX, and LaTeX > documentation is so extremely huge and fragmented that it's > a terrible challenge to find anything you need). well ... i have to admit i tried harder with LaTeX but thanks to CTAN, i reached the point when i know what are the classes and packages i need (mostly article, book, beamer and tikz). there is no CTAN for troff and that's a missing part. > out LaTeX is easier to program than roff(7) because the syntax and > semantics of the low-level roff(7) language are, let's put it > politely, quite unusual and surprising in many details. i love the way you're saying that. is there a document to dive into it ? > groff, and besides, i did implement considerable parts of the roff > language in /usr/src/usr.bin/mandoc/roff.c. nice. thank you for mandoc! regards marc
Re: Tools for writers
Hi, On Sun, Nov 03, 2019 at 02:29:02AM +0100, Ingo Schwarze wrote: > As long as you only *use* macro packages, groff is *much* > easier to use than LaTeX (not least because the quality of > documentation of groff is vastly superior to LaTeX, and LaTeX > documentation is so extremely huge and fragmented that it's > a terrible challenge to find anything you need). > > But once you start modifying macro packages or writing your own > macros, i.e. once you enter into real programming, then it turns > out LaTeX is easier to program than roff(7) because the syntax and > semantics of the low-level roff(7) language are, let's put it > politely, quite unusual and surprising in many details. I know > that because i did write a non-trivial LaTeX module and because i > do maintain one of the larger roff macro packages, upstream at > groff, and besides, i did implement considerable parts of the roff > language in /usr/src/usr.bin/mandoc/roff.c. I actually wrote a semantic markup language shamelessly inspired from mdoc(7) and with simplified roff-like syntax, called “gofrundis” (actual tool is spelled frundis(1)), but primarily intented for authoring novels. It exports to LaTeX, HTML/EPUB or groff mom, and is documented using mdoc(7). That said, even though the language has quite silently existed for several years, excluding me it still has only two regular users as far as I know. The consequence is that there's not a community providing extension packages for it: anything not covered by the core language frundis_syntax(5) requires you to write some code in LaTeX, HTML or roff/mom and wrap it with macros. It's somewhat extensible, and I used it to write a thesis and export afterwards to LaTeX, because I find the syntax and semantics simpler and more pleasant to use. But I'm not sure I would recommend such non standard use. Yon
Re: Tools for writers
> documents, but for my use case, LibreOffice has treated me well. I primarily > use it for simple things like putting together invoices, writing articles, > rendering documents to PDF or postscript, and reading .docx files people > send me. > I'm sure there's a superior way to do all this, there is no such thing as a "superior way", there are way that fit your expectations: i wasn't trying to convince you to use anything else that please you but i really think toolchain that uses latex as core offers much more opportunity than a libreoffice ones and would like to mention it if it can help. regards > I have to collaborate with average people. I've thought about learning latex > and mandoc and all the fancy tools, but I've just never gotten around to it. I wasn't talking about mandoc but pandoc (https://pandoc.org/): you write most of the things just using markdown format and add latex instructions whenever you want. this way, you keep simple things simple but you keep the power of latex under the wood. regards marc
Re: Tools for writers
I really like Markdown for actual writing, because its markup for logical structure is quite low-key and non-distracting, and (unlike *roff or LaTeX) it also reads pretty well in source form. Tables are fairly annoying, particularly if I later have to insert a column in mid table. Use whatever editor works best for you. I use Vim because when I switched from Emacs back in 1999 my wrist problems disappeared almost overnight, a consequence of replacing almost all of the multi-key combinations with single keystrokes. If not for the physiological consequences I would probably still be using Emacs, or an emacslike such as jed or mg. Frankly I think it’s a bit weird that so many people are using an editor with key mappings expressly designed for a (Space Cadet) keyboard that few people ever had even seen in real life, never mind actually used. But evidently people cope just fine. That’s good, I guess? John On Sun, Nov 3, 2019 at 02:07 Oliver Leaver-Smith wrote: > Hello, > > What tools do people find useful for writing on OpenBSD? By writing I mean > long form such as novels and technical books, including plot and character > development, outlining, and formatting for publishing (not all the same > application necessarily) > > I have found a number which boast Linux support, but not really anything > that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) > > Mich appreciated > > ~ols > -- > Oliver Leaver-Smith > +44(0)114-360-1337 > TZ=Europe/London >
Re: Tools for writers
Hello, What tools do people find useful for writing on OpenBSD? By writing I mean long form such as novels and technical books, including plot and character development, outlining, and formatting for publishing (not all the same application necessarily) I agree with the majority of people here, use a text editor you are comfortable with. I use nvi, I've tryed a lot, but I always go back to nvi. Remember that the version in base doesn't have unicode support. One that almost got me was the new fork of nedit: https://sourceforge.net/projects/xnedit/ My advise is to think about your layout, how people are going to read your work, and then "mark" that layout in a plain text file, using spaces, labels, etc. Write freely, without being distracted by strange lines and your text being transformed while you are typing it, lags... oh man, I don't know why people like those monstrosities, but a lot of people love them so maybe something is wrong with me!. Use key bindings to search for words, translations, synonymous, local dictionaries, whatever. Use the tools your OS already have. Then, at the end, choose a formatter that fits you, or the one that your publisher ask you for, if any. I prefer troff than TeX/LaTeX. In my opinion, the latter has become a chaos. The last time I used it (more than a decade ago) it was still compiled by a generator of C code from pascal sources, and then the "distribution" grew from it like that story about alien plants from Creepshow. If you have to use it, I remember one distribution on Plan9, kerTeX IIRC, it was in unix also, way more compact. I prefer heirloom troff. Very small, very easy to use fonts and non English hyphenation and it feels more unix to me, I suppose it is just a matter of taste. The last time I was in the groff mailing list (they shared it nicely with heirloom troff users) they were working on a macro "mom" to make life easier to writers. I prefer using troff directly, but you can give it a try, it should be mature now. Make a script that creates an input for your formatter from your plain file, using your labels, spaces, etc, so if you need to use another formatter, you don't have to touch your work, just make another script. Just an advise. I enjoyed this book back at the time. Now is not only open, but you have also the groff source, so you can see how is the book itself developed. I think that you can pick a lot of good ideas from it, and it shows you how to use and combine the tools you already have, that is, the unix philosophy. https://www.oreilly.com/openbook/utp/ P.S. I read someone recommending lilypond for typesetting music. The output is beautiful, and if you are familiar with lisp you'll be familiar with its guts. But I prefer these: This is a new version of RISC OS pms: https://sourceforge.net/p/philip-s-music-writer/ I discovered this some time ago by chance, and now I have to make a choice: http://www.Arkkra.com/ Both of them are small C programs, almost no dependencies, beautiful output and easy input syntax. Regards, adr
Re: Tools for writers
On Sat, Nov 02, 2019 at 03:00:28PM +, Oliver Leaver-Smith wrote: > Hello, > > What tools do people find useful for writing on OpenBSD? By writing > I mean long form such as novels and technical books, including plot > and character development, outlining, and formatting for publishing > (not all the same application necessarily) > > I have found a number which boast Linux support, but not really > anything that stands out which supports OpenBSD (aside from the > obvious LaTeX et al.) > > Mich appreciated > > ~ols I am not sure what is your ability to learn tools - no offence, but some people want to have it as WYSIWIG, period, and I am mostly ok about it (as long as they also do their cleaning). However, my unholy opinion is, if you plan for your words to be readable with the least problem say, twenty years from now, then you should stick with text based formats for, er, text and learn few tools that can process such format. So, - LaTeX for writing a book It is possible to have parts of a text in various files, which can be included into main file - various ways of developing plot, etc. It is possible to have many versions of same book, including chapters into them as separate files. And so on. I am not sure if a writer actually needs this much flexibility, but a lot is possible if you would like to mess with different ways to organize a book. - Emacs for editor This part is tricky, but I definitely prefer Emacs. Some prefer Vim and I agree it is very fine editor, but myself, I go with Emacs. I stay away from anything web based, browser based and Javascript based. All of those look like ticking bombs to me. When they go (not an unlikely event, IMHO) those depending on them are left to freeze. Or they will be dying a death of thousand worms loaded from some far away countries in their just-updated JS library. - Org mode for plot/characters and stuff Org mode is kind of program running inside Emacs (not really, but do I want to delve into talking about Lisp, loadable code and programmable editors). Or, it is a way to have one's own personal wiki in a file, without the need for web server and whatnot. Very handy, if you ask me. All those are tools and require some learning. In my case, I read a tutorial built into Emacs (say, an hour of reading + learning to press right keys), I read some chapters from Leslie Lamport book on LaTeX (say, maybe few hours of trying stuff inside Emacs and producing documents with it). As of Org-mode, I caught some basics and started going, then caught some more and there is still 98% or more to learn, but as I do not have to, I just use what I know and keep going. There are few more tools which might be useful for above case. - pandoc for converting from LaTeX to ODT (i.e. Open Office) - I have not used it but some people say it works - version control - whatever is easier, I have just set my own org-mode based "wiki" into RCS. RCS is amongst the oldest such system still in use, but I did not wanted to mess with other things, for a while. Now, if I make a mistake, press wrong key combo and delete half of my wiki, I might have better chance to recover from this error. There are many version control systems to choose from, I think most will work locally on your computer without prematurely exposing the book to the outside world. This email was written in Emacs, BTW. I get easy formatting for free. Of course, tools have quirks. I think so. I got used to them and forgot, so I am unable to say more about this. So maybe the learning experience will not be peachy rosy for you at first, but I would say positives prevail over time. HTH -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Re: Tools for writers
On 2019-11-02 11:00, Oliver Leaver-Smith wrote: > Hello, > > What tools do people find useful for writing on OpenBSD? By writing I > mean long form such as novels and technical books, including plot and > character development, outlining, and formatting for publishing (not all > the same application necessarily) > For writing you need a text editor. I like nvi 1.79 /usr/bin/vi due to its predictability as I agree that Vim sucks http://www.galexander.org/vim_sucks.html nvi is in the base :-) Unfortunately yacc was "depreciated" on Linux in favor of bison so good luck compiling nvi. I have never been able to pull that one on Red Hat 7. Now typesetting is whole another story. In old good times a writter will bring her/his manuscript to a publishing company where qualified individuals would apply typographic rules, enforce standards, and do graphics design before sending things to the typesetter. IMHO letterpress is still the gold standard and nothing comes close to it. However people moved to phototype first and digital to cut the cost. Cutting cost came with the price. Quality sucks but I guess if you have never had a letterpress book in your hands you will not know it. I am guessing you want a computerized solution but you are not a typesetter nor designer and you need some assistance to impose format on the text. Essentially you have two classes of solutions. 1. You will need to use some kind logical markup and enter the mixture of text and commands. In this case typography is embedded into the source file. 2. You want some super clever program to do typesetting for you. You are in luck my friend. If you chose solution one all four typesetting systems in existence are ported and can be found in OpenBSD ports. I am listing them in the chronological order. a. Troff (Please see GNU Troff aka. Groff from the ports) b. TeX (LaTeX is just a set of macros but you can also use key-value driven ConTeXt) c. Lout d. To typeset music use LilyPond. If you chose second option there is only one solution I am aware of. It is Brian K. Reid Scribe. Brian used to work here at Carnegie Mellon University many years before my time. After failing to make millions he essentially left his code to his assistant and my good friend/co-worker Dale Moore who still has a working copy. I am not sure if we can get Scribe to the ports three but for private use should be Ok. I can check with Dale on Monday. > > I have found a number which boast Linux support, but not really anything > that stands out which supports OpenBSD (aside from the obvious LaTeX et > al.) > I am not sure what you have found out but I will tell you a little secret. No matter what you chose these days your publisher if you have one will convert your document into XML as it is the most convenient format for electronic safekeeping. Just to complete this little write up. I am not oblivious to GUI word processors (which typically store things in Rich Text Format (RTF), a Microsoft take onto the TeX). The only problem with them is that they don't change the fact that people who don't know typographic rules can't become experts on typography just because they can drug text with the mouse and click left and right. That is why I personally use LaTeX (typography built in packages) instead of key-value driven ConTeXt. If you must use word processor you are again in luck with OpenBSD. OpenBSD still has the first open source office suite in its ports tree (Siag) and while I still use SIAG spreadsheet my exposure to Pathetic Writer (PW) is only rudimentary. I heard a good things about Ted from people who like RTF Finally I have tried a numerous lightweight markup languages but only found txt2tags to be useful. Keep in mind that using txt2tags+htmldoc to produce pdf document will produce horrible document as there is no line breaking algorithm equivalent of famous TeX algorithm. Getting nicer output from txt2tags will inevitable lead to embedding so much LaTeX code into your txt2tags that you will start wondering why are you using txt2tags to begin with. Cheers, Predrag Cheers, Predrag > Mich appreciated > > ~ols > -- > Oliver Leaver-Smith > +44(0)114-360-1337 > TZ=Europe/London
Re: Tools for writers
Hi Jordan, Jordan Geoghegan wrote on Sat, Nov 02, 2019 at 05:44:23PM -0700: > I've thought about learning latex and mandoc and all the fancy > tools, but I've just never gotten around to it. Actually, both mandoc(1) and mdoc(7) are off-topic in this thread. You cannot use either for writing a book, neither the mdoc(7) language nor the mandoc(1) program supports any of the important features. That said, the obvious answer for the OP is of course the "textproc/groff" port (disclosure: which i maintain). The roff(7) language and the troff programm is what people in the UNIX world always used for writing books and journal articles, and it is very much alive even after the roff language celebrated its 55th birthday this year. I'm in the habit of using it to prepare slides for conference talks (with textproc/gpresent), for example, and i'm not the only only one. The "textproc/heirloom-doctools" port is a serious contender for a top-quality typesetting system (though not recommended as a manual page viewer). In some finer points of typography, it is better than groff; for example, it supports paragraph-at-once filling. But admittedly, groff is more actively maintained, so unless you know exactly why you prefer Heirloom troff, i'd suggest you try groff first. And finally, the only thing that is seriously wrong with the "print/texlive" port is how ridiculously large it is. All the same, i used it often to write journal articles, letters, invoices, and the like, and still use it now and then. As long as you only *use* macro packages, groff is *much* easier to use than LaTeX (not least because the quality of documentation of groff is vastly superior to LaTeX, and LaTeX documentation is so extremely huge and fragmented that it's a terrible challenge to find anything you need). But once you start modifying macro packages or writing your own macros, i.e. once you enter into real programming, then it turns out LaTeX is easier to program than roff(7) because the syntax and semantics of the low-level roff(7) language are, let's put it politely, quite unusual and surprising in many details. I know that because i did write a non-trivial LaTeX module and because i do maintain one of the larger roff macro packages, upstream at groff, and besides, i did implement considerable parts of the roff language in /usr/src/usr.bin/mandoc/roff.c. Most certainly, it is *much* easier to get good typography out of groff or LaTeX (no matter which one) than out of LibreOffice or any similar abomination. Yours, Ingo
Re: Tools for writers
On 2019-11-02 15:54, Marc Chantreux wrote: hello, You can't go wrong with LibreOffice. I've written thousands of pages over the years with it. It may be too "heavy" for some, but for me, if I'm doing something too complex for vi or mousepad, I just fire up LibreOffice. to me there is no such thing that is too complex for the unix documentation toolchain that you can achieve with libreoffice. i feel the other way around: libreoffice is always a bad choice: * when i need a rich good looking document in which you can easily add graphical material of very different nature (music cheets, chemical or math formula, gantt graph, ...), then [your editor of choice] + pandoc + git + latex + tikz + gnuplot + graphviz + m4 is really the best thing i found * if you need interactivity and animation (which isn't my case): the web is there (i personally use pandoc + pug + livescript (to be replaced by elm) + stylus) the only one case where libreoffice is the good choice is if you mind the learning curve but writting a book is a long process, pay the bill at first to be more peaceful later seems to be a good deal to me. regards. marc Fair enough, I have no issue with using the various unix tools for making documents, but for my use case, LibreOffice has treated me well. I primarily use it for simple things like putting together invoices, writing articles, rendering documents to PDF or postscript, and reading .docx files people send me. I'm sure there's a superior way to do all this, but I'm lazy and I like some of the more mundane features of LibreOffice like being able to render a document to postscript and then print to the printer I have specified in my /etc/printcap file as well as .docx format support for when I have to collaborate with average people. I've thought about learning latex and mandoc and all the fancy tools, but I've just never gotten around to it.
Re: Tools for writers
hello, > You can't go wrong with LibreOffice. I've written thousands of pages over > the years with it. It may be too "heavy" for some, but for me, if I'm doing > something too complex for vi or mousepad, I just fire up LibreOffice. to me there is no such thing that is too complex for the unix documentation toolchain that you can achieve with libreoffice. i feel the other way around: libreoffice is always a bad choice: * when i need a rich good looking document in which you can easily add graphical material of very different nature (music cheets, chemical or math formula, gantt graph, ...), then [your editor of choice] + pandoc + git + latex + tikz + gnuplot + graphviz + m4 is really the best thing i found * if you need interactivity and animation (which isn't my case): the web is there (i personally use pandoc + pug + livescript (to be replaced by elm) + stylus) the only one case where libreoffice is the good choice is if you mind the learning curve but writting a book is a long process, pay the bill at first to be more peaceful later seems to be a good deal to me. regards. marc
Re: Tools for writers
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. Dave Raymond On 11/2/19, Jordan Geoghegan wrote: > > On 2019-11-02 13:18, Chris Bennett wrote: >> On Sat, Nov 02, 2019 at 03:16:22PM -0400, STeve Andre' wrote: >>> >>> On 2019-11-02 15:07, Antoine Jacoutot wrote: You obviously never wrote a book. At least not with the requirements OP asked for. > >>> Actually, I am, right now. I've found that "formatting" is an >>> annoyance, when writing material. Get it written, *then* worry >>> about how it looks. I've done this for more than 40 years when >>> creating documents, reports and such for work. >>> >>> --STeve Andre' >>> >>> >> Actually the OP said that not necessarily the same application. >> I have to agree that writing the content and doing the formatting to be >> two separate processes. I write in a furious stream of conciousness. >> Looking at the formatting, etc. just impedes my work. >> Spout out the thoughts. Then review content. Then work on formatting and >> editing content. >> >> /bin/ed >> >> Then do the delicate work of editing and formatting after the creative >> stream ends. Or creativity may be lost. Forever. Over seeing some >> misspelled word or wrong punctuation. >> >> Two or three different tools. Since there are really about three >> processes being done that are quite different. For me, multitasking >> sucks. >> >> But, please, what is good for formatting? I don't have an answer for >> that myself. I am considering writing as a new direction for myself. >> Getting old sucks. >> >> Chris Bennett >> > > You can't go wrong with LibreOffice. I've written thousands of pages > over the years with it. It may be too "heavy" for some, but for me, if > I'm doing something too complex for vi or mousepad, I just fire up > LibreOffice. > > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: Tools for writers
On 2019-11-02 13:18, Chris Bennett wrote: On Sat, Nov 02, 2019 at 03:16:22PM -0400, STeve Andre' wrote: On 2019-11-02 15:07, Antoine Jacoutot wrote: You obviously never wrote a book. At least not with the requirements OP asked for. > Actually, I am, right now. I've found that "formatting" is an annoyance, when writing material. Get it written, *then* worry about how it looks. I've done this for more than 40 years when creating documents, reports and such for work. --STeve Andre' Actually the OP said that not necessarily the same application. I have to agree that writing the content and doing the formatting to be two separate processes. I write in a furious stream of conciousness. Looking at the formatting, etc. just impedes my work. Spout out the thoughts. Then review content. Then work on formatting and editing content. /bin/ed Then do the delicate work of editing and formatting after the creative stream ends. Or creativity may be lost. Forever. Over seeing some misspelled word or wrong punctuation. Two or three different tools. Since there are really about three processes being done that are quite different. For me, multitasking sucks. But, please, what is good for formatting? I don't have an answer for that myself. I am considering writing as a new direction for myself. Getting old sucks. Chris Bennett You can't go wrong with LibreOffice. I've written thousands of pages over the years with it. It may be too "heavy" for some, but for me, if I'm doing something too complex for vi or mousepad, I just fire up LibreOffice.
Re: Tools for writers
>>> On 2 Nov 2019, at 19:17, STeve Andre' wrote: On 2019-11-02 15:07, Antoine Jacoutot wrote: > On Sat, Nov 02, 2019 at 03:04:34PM -0400, STeve Andre' wrote: /usr/bin/vi >>> You obviously never wrote a book. >>> At least not with the requirements OP asked for. > >> Actually, I am, right now. I've found that "formatting" is an >> annoyance, when writing material. Get it written, *then* worry >> about how it looks. I've done this for more than 40 years when >> creating documents, reports and such for work. >> >> --STeve Andre' > > I’m inclined to agree with you STeve. For the “writing words in a document” > part, nothing beats a distraction-free experience that vi provides. For > avoidance of doubt, my query was more around supporting the writing process > (outlining, character development) and the formatting (like you say, an after > thought most often) > > ~ols > -- > Oliver Leaver-Smith > +44(0)114-360-1337 > TZ=Europe/London
Re: Tools for writers
On Sat, Nov 02, 2019 at 03:16:22PM -0400, STeve Andre' wrote: > > > On 2019-11-02 15:07, Antoine Jacoutot wrote: > > You obviously never wrote a book. > > At least not with the requirements OP asked for. > > > Actually, I am, right now. I've found that "formatting" is an > annoyance, when writing material. Get it written, *then* worry > about how it looks. I've done this for more than 40 years when > creating documents, reports and such for work. > > --STeve Andre' > > Actually the OP said that not necessarily the same application. I have to agree that writing the content and doing the formatting to be two separate processes. I write in a furious stream of conciousness. Looking at the formatting, etc. just impedes my work. Spout out the thoughts. Then review content. Then work on formatting and editing content. /bin/ed Then do the delicate work of editing and formatting after the creative stream ends. Or creativity may be lost. Forever. Over seeing some misspelled word or wrong punctuation. Two or three different tools. Since there are really about three processes being done that are quite different. For me, multitasking sucks. But, please, what is good for formatting? I don't have an answer for that myself. I am considering writing as a new direction for myself. Getting old sucks. Chris Bennett
Re: Tools for writers
On 2019-11-02 15:07, Antoine Jacoutot wrote: On Sat, Nov 02, 2019 at 03:04:34PM -0400, STeve Andre' wrote: On 2019-11-02 11:00, Oliver Leaver-Smith wrote: Hello, What tools do people find useful for writing on OpenBSD? By writing I mean long form such as novels and technical books, including plot and character development, outlining, and formatting for publishing (not all the same application necessarily) I have found a number which boast Linux support, but not really anything that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) Mich appreciated ~ols -- Oliver Leaver-Smith +44(0)114-360-1337 TZ=Europe/London /usr/bin/vi You obviously never wrote a book. At least not with the requirements OP asked for. > Actually, I am, right now. I've found that "formatting" is an annoyance, when writing material. Get it written, *then* worry about how it looks. I've done this for more than 40 years when creating documents, reports and such for work. --STeve Andre'
Re: Tools for writers
> What tools do people find useful for writing on OpenBSD? By writing I mean > long form such as novels and technical books, including plot and character > development, outlining, and formatting for publishing (not all the same > application necessarily) > Hi, Not sure for plot and characters. I would recommend txt2tags [1], txtproc/txt2tags in ports. There is also a more up-to-date version written in python3 (2], both works fine. It can convert txt2tags syntax in different formats, such as html or tex (useful to get nice PDF). The most interesting imho are : - ``postproc`` and ``preproc`` instruction. Sort of ``#define`` in C or ``\newcommand`` in LaTeX. Very useful. - ``include``. Also available in LaTeX. Have a look at [3] for an example. One might do markdown + sed + Makefile for the same result. Using txt2tags, I wrote a ≈350 pages book in PDF [4] and maintain it for a little more than two years now, very happy with txt2tags. If txt2tags is not enough, then LaTeX is great, but requires to learn a lot more to use it correctly. Regards. [1]: https://txt2tags.org/ [2]: https://github.com/jendrikseipp/txt2tags [3]: https://framagit.org/prx/auto-hebergement-openbsd/blob/master/src/auto-hebergement-openbsd.t2t [4]: https://ybad.name/ah/ -- prx
Re: Tools for writers
On Sat, Nov 02, 2019 at 03:04:34PM -0400, STeve Andre' wrote: > > > On 2019-11-02 11:00, Oliver Leaver-Smith wrote: > > Hello, > > > > What tools do people find useful for writing on OpenBSD? By writing I mean > > long form such as novels and technical books, including plot and character > > development, outlining, and formatting for publishing (not all the same > > application necessarily) > > > > I have found a number which boast Linux support, but not really anything > > that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) > > > > Mich appreciated > > > > ~ols > > -- > > Oliver Leaver-Smith > > +44(0)114-360-1337 > > TZ=Europe/London > > > > /usr/bin/vi You obviously never wrote a book. At least not with the requirements OP asked for. -- Antoine
Re: Tools for writers
On 2019-11-02 11:00, Oliver Leaver-Smith wrote: Hello, What tools do people find useful for writing on OpenBSD? By writing I mean long form such as novels and technical books, including plot and character development, outlining, and formatting for publishing (not all the same application necessarily) I have found a number which boast Linux support, but not really anything that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) Mich appreciated ~ols -- Oliver Leaver-Smith +44(0)114-360-1337 TZ=Europe/London /usr/bin/vi
Re: Tools for writers
Mr. Hansteen what are your thoughts on Texlive? On Sat, Nov 2, 2019 at 9:16 AM Peter Nicolai Mathias Hansteen < pe...@bsdly.net> wrote: > > > > 2. nov. 2019 kl. 16:00 skrev Oliver Leaver-Smith : > > > > What tools do people find useful for writing on OpenBSD? By writing I > mean long form such as novels and technical books, including plot and > character development, outlining, and formatting for publishing (not all > the same application necessarily) > > > > I have found a number which boast Linux support, but not really anything > that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) > > I really can’t speak to plot and character development, but all three > editions of The Book of PF were written using OpenOffice and later > LibreOffice write on OpenBSD snapshots. > > Earlier versions of that manuscript were developed using DocBook SGML > (editing with emacs), but the publisher (fortunately) did not want any > truck with that. > > For any new projects I would likely look half-heartedly for something > markdown based but would probably end up going the LibreOffice route again. > > — > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. > > > > >
Re: Tools for writers
> 2. nov. 2019 kl. 16:00 skrev Oliver Leaver-Smith : > > What tools do people find useful for writing on OpenBSD? By writing I mean > long form such as novels and technical books, including plot and character > development, outlining, and formatting for publishing (not all the same > application necessarily) > > I have found a number which boast Linux support, but not really anything that > stands out which supports OpenBSD (aside from the obvious LaTeX et al.) I really can’t speak to plot and character development, but all three editions of The Book of PF were written using OpenOffice and later LibreOffice write on OpenBSD snapshots. Earlier versions of that manuscript were developed using DocBook SGML (editing with emacs), but the publisher (fortunately) did not want any truck with that. For any new projects I would likely look half-heartedly for something markdown based but would probably end up going the LibreOffice route again. — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
