On text reflow. It's not about bullets!

David Requena drequena at andram.net
Tue Nov 26 00:13:31 GMT 2019
Hi all,

   Just joined the list to add my 2 cents to the reflowing discussion. With
all
due respect, I think that long thread didn't touch on a couple fundamental
aspects I believe worth considering.

1. Text reflow IS A MUST.
       We live in a world of wildly varying screen sizes these days. The
trend
    is clearly headed towards polarization: huge 22'+ desktop screens in one
    corner, small less than 7' smartphone screens in the other. Nothing in
the
    middle. There's no way you're going to get decent presentation of non
    reflown text on both kinds of displays. No matter how many kludgy rules
you
    instate on default width, max before forced wrap, etc.

2. Author's having selected lines not reflown IS A MUST.
       This has nothing to do with formatted lists, tables, fancy styling or
    ASCII art. Fact is that Gemini is a publishing platform and by not
allowing
    this, you'd be precluding certain kinds of content from being
distributed
    over it. Those include text snippets whose semantics intrinsically
depend
    on formatting (spacing and horizontal alignment), such as:

     - The simplest of mathematical formulas involving fractions
     - Source code snippets in some computer languages. Hey pythonists, I
see
       several of you hanging around here!
   
   You literally cannot convey that kind of thing in the presence of text
   reflowing.

   If we can agree on 1 and 2, then we could as well man up, select a proper
   line marker and be done with it.
   Is the spec golden goal to end with exactly on special line marker?
   Or is it ending with exactly what is needed, no more, no less?

   How about (in non standarese):

   Each line in a text/gemini document can, at the option of the client, be
reflown and/or be presented in any font the client deems appropriate except
for lines beginning with => or ==. These line markers mean:

  =>    (arrow) line is a link in the format bla bla bla...
  ==    (equal, of all things!) line is preformatted text which MUST NOT be
           transformed by reflow nor proportional font rendering.

   That's it! Let's talk about text styling in some other occasion.

   Finally, I firmly believe trying to accomplish this with a space is a bad
idea: That conspicuous space *IS* markup. Some magical text sequence,
sitting
at the right place, triggering special presentation of text following it.
Pitifully ashamed of itself markup, markup to the core nonetheless.

   Trying to hide the need of an actual line marker behind some half-baked
one-space convention seems particularly unsuitable to me. Besides... What'd
be
the point? Having our poor author repeatedly misinterpreting which line is
each kind in his own document?

   It doesn't even work all the time. Using a space opens a whole new can of
worms. For one: Have you noticed I've been opening every paragraph with 3
spaces? This is quite common, at least it is in my country.

   In my view the issue arises from trying to abuse the meaning of the space
character. A space is, well, some white space. It separates things, it is
invisible, and you can only perceive it because of an absence between said
things. Overloading such an entity to mean something totally unrelated,
depending on the happenstance of being inserted at the beginning of a line
or, God forbid!, at the end, is simply calling for trouble in the long run.

If you happen to have endured my prose all the way down here, many thanks
for
your attention. You're a remarkably forgiving reader.

Best regards,
Andram



Archive home | About this archive