groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] Creating a numbered list without macros


From: Peter Schaffter
Subject: Re: [groff] Creating a numbered list without macros
Date: Mon, 20 Aug 2018 15:24:39 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Aug 20, 2018, Holger Herrlich wrote:
> First lets assume that here is a diametral contradistinction between
> plain groff and a macro package like mom in terms of user interface.
> The first provides you all the controls to type set. The latter hides
> that controls as much as possible, claiming the writers perspective.

Don't agree.  Groff provides you with controls to set type AND to
build tools for setting type, i.e. macros.  As I pointed out to Yves
Cloutier, the use of macros isn't optional.  Page transitions, for
example, aren't possible without them.  Both the controls (requests)
and the tools (macros) are part of the groff "experience," whether
you write the macros yourself or not.

A macro package does not hide the controls any more than writing
macros yourself does.  A macro package aggregates the requests
needed to perform typesetting functions for convenience, not
opacity.

Furthermore, an examination of the classical macro sets reveals the
target user is the person typesetting the document, not the writer.
That two roles are often blended doesn't alter the fact that "the
writer" produces content, which "the typesetter" formats.  A macro
set does not claim "writer's perspective," it claims "typesetter's
perspective."

> Here is a reason to do so, because mixing up text and groff requests
> will disturb reading/writing. Document writing using markup will always
> suffer this problem. So if you wanna write, you will end up with a
> macro set.

No.  Document writing using markup will always result in text
interspersed with formatting commands, whether groff requests, LaTex
macros, or html tags.  You are correct that this is considered by
some to be a problem.  The alternative, WYSIWYG, is also
problematic, for different reasons, hence the debate over which
approach to formatting documents is superior.
 
> Why not an existing one?
> 
> For me, I want to use tools that preserve creativity. But a framework
> desires to make things easy. (As a rule of thumb: Always avoid people
> claiming that.) But the kindergarten teacher's "making things easy" is
> different to providing a professional tool that do exactly that it
> claims to do--therefore is "easy to use".

I suspect you haven't examined mom thoroughly.  In addition to
semantically rich markup tags, it provides professional typesetting
tools that do exactly what they claim to do, most of them providing
greater flexibility than can be had with requests alone, and some
providing functions that weren't even thought of in the original
troff.  String tabs, for example; tabs whose length is established
from text strings and thus scale when the point size is changed.

Another example is carded (or "feathered") leading.  It meets both
your requirements for easy: it does exactly what it claims to
do--adjusts leading to fill the page to the bottom margin--and is
invoked simply by entering .DOC_LEAD_ADJUST.

In addition to professional typesetting tools, all of mom's markup
tags have an associated suite of "control macros" that allow you to
set and change every applicable type parameter: family, font, size,
colour, leading, spacing, indent, quad, fill, and vertical
placement.

In other words, mom expands creative options rather than limiting
them.  That's the whole point.

> The framework takes away flexibility.

No. A *poorly implemented* framework takes away flexibility.  A well
implemented one adds to it.

> So to create business cards I had to do it myself from the
> scratch.

Mom provides a sufficiently flexible framework that you could have
created the business cards from scratch using only mom macros and
not one single low-level groff request.  I know, I've done it.
Eight-up with logos, crops, and register marks.

> OKAY, that's the idea.  A framework doesn't provide smaller
> entities (the UNIX thing) to be more creative (not only
> graphically).

I want to insist that you're talking about *inadequate* frameworks,
about which all your comments are true, not well-designed ones.  A
well-designed framework is one that supports you when you want to
wander down the creative path.

-- 
Peter Schaffter
http://www.schaffter.ca



reply via email to

[Prev in Thread] Current Thread [Next in Thread]