ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Mikael Sundqvist <mickep@gmail.com>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: [NTG-context] Re: redefine space to be the same as \␣ similar to knuthian approach
Date: Fri, 18 Aug 2023 18:20:29 +0200	[thread overview]
Message-ID: <CAHy-LL_24Z0rK_3X02+26VRexxtp=Nod58zm2KGfD8Dcj+wH=A@mail.gmail.com> (raw)
In-Reply-To: <z36wk45quofui4tx4zplrwywtz6fpze3nexw2kqxuwhpldcr5s@5k6quyyl7ceo>

Hi,

It is extremely difficult to follow what you write.

On Fri, Aug 18, 2023 at 11:43 AM Carlos <linguafalsa@gmail.com> wrote:
>
> If I have the following, with these linebreaks as in:
>
> {\par But a system cannot be successful if it is too strongly
> influenced by a single person. {\obeylines Once the initial design is
> complete and fairly robust, the real test begins as people
> with many different viewpoints undertake their own
> experiments.}}

Is that the complete document? What do you have in mind with obeying
lines in the middle of a paragraph?

>
> and opted to load another font, other than cmr that is, a \frenchspacing
> approach wouldn't be further required

cmr? Not used in ConTeXt for a long time. (And what does the changing
of font have to do with this?)

>
> Bear with me here, in the current state, for example, and as long as say
>
> «…person.␣{\obeylines Once the initial is
> complete…» though feasible enough, leaves any prior \␣ at the mercy of
> whatever fontsize and/or set width happens to be. And this is just plain
> wrong.

What?

>
> Likewise, if a word sequence such as \TeX\ occurs as in {\ss The separation
> of any of these four components would have hurt \TeX\ significantly. }

Likewise what?

>
> The next sentence: «If I had not participated…» does not get any
> \nofrenchspacing which is equally and doubly problematic. It shows lack of
> consistency. And this ought not to be an ‹either› ‹or› scenario. But
> rather, an and conjunctional construct. It fails both ways.

Consistency of what? Spacing? Where? Can you make a complete example?
(You can show space amount with \showmakup[space])

>
> Furthermore, with the same token, if width is specified with a
>
> \setuplayout[width=15cm]

OK, here the game changes...

>
> Anything less than 12.895pt, especifically for that use case, wwould
> throw anything, particularly control sequences such as \TeX\ out
> of whack, and conversely, once a value of that very pt or pica or
> whatever is lowered, it brings that nonfrenchspacing right back on.
> And if width increments occur, then it follows that any control sequence kerning
> also gets thrown off as a result.

Of course the width influences the spacing. That is how the paragraph
builder works (and really, why it often looks good).

>
> It seems so far, that with lmtx, any standalone file, document, minimal
> working example that does not load cmr at the outset does not produce
> an acceptable outcome either. By saying acceptable I meant to say it
> namely from a typographical point of view. Nothing else.

I have no clue of what you talk about here.

>
> from the TeXbook 380-381
>
> «\obeylines doesn’t say ‘\def^^M{\par}’, so we must make any desired changes to
> \par before invoking \obeylines. (2) The \uncatcodespecials operation changes a
> space to category 12; but the \tt font has the character ‘␣’ in the ⟨space⟩ position, so we
> don’t really want ␣12 . (3) The \obeyspaces macro in Appendix B merely changes the
> ⟨space⟩ character to category 13; active character ␣13 has been defined to be the same
> as \space, a macro that expands to ␣10 . This is usually what is desired; for example,
> it means that spaces in constructions like ‘\hbox to 10 pt {...}’ won’t cause any
> trouble. But in our application it has an undesirable effect, because it produces spaces
> that are affected by the space factor. To defeat this feature, it’s necessary either to
> say \frenchspacing or to redefine ␣13 to be the same as \␣. The latter alternative is
> better, because the former will discard spaces at the beginning of each
> line.»
>
> «In theory, this seems like it ought to work; but in practice, it fails in two ways. One
> rather obvious failure—at least, it becomes obvious when the macro is tested—is that
> all the empty lines of the file are omitted. The reason is that the \par command at the
> end of an empty line doesn’t start up a new paragraph, because it occurs in vertical
> mode. The other failure is not as obvious, because it occurs much less often: The \tt
> fonts contain ligatures for Spanish punctuation, so the sequences ?‘ and !‘ will be
> printed as ¿ and ¡ respectively. Both of these defects can be cured by inserting
>
> and
>
>
> «When INITEX creates a brand new TEX, all characters have a space factor code
> of 1000, except that the uppercase letters ‘A’ through ‘Z’ have code 999. (This
> slight difference is what makes punctuation act differently after an uppercase letter; do
> you see why?) Plain TEX redefines a few of these codes using the \sfcode primitive,
> which is similar to \catcode (see Appendix B); for example, the instructions
> \sfcode‘)=0
>  \sfcode‘.=3000
> make right parentheses “transparent” to the space factor, while tripling the stretcha-
> bility after periods. The \frenchspacing operation resets \sfcode‘. to
> 1000.»

Everything you cite above is very likely true for plain TeX, but maybe
not for ConTeXt...

/Mikael

PS I do not think that your emails come out well. In order to get
help, I would suggest a strategy that not so much only sounds as
nagging and complaints. One thing that has been lacking is a clear
explanation of what you really try to achieve.
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

  reply	other threads:[~2023-08-18 16:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-18  9:39 [NTG-context] " Carlos
2023-08-18 16:20 ` Mikael Sundqvist [this message]
2023-08-18 18:17   ` [NTG-context] " Carlos
2023-08-18 18:54     ` [NTG-context] unsubscribe Thomas Floeren via ntg-context
2023-08-18 18:26   ` [NTG-context] Re: redefine space to be the same as \␣ similar to knuthian approach Carlos
2023-08-18 18:48     ` Carlos
2023-08-18 18:58       ` Wolfgang Schuster
2023-08-19 13:32         ` Carlos
2023-08-19 14:06           ` Mikael Sundqvist
2023-08-20 13:38           ` Wolfgang Schuster
2023-08-20 15:51             ` Carlos
2023-08-20 16:41               ` Wolfgang Schuster
2023-08-20 16:58                 ` Hans Hagen via ntg-context
2023-08-20 16:41               ` Hans Hagen
2023-08-21 12:22                 ` Carlos
2023-08-21 12:55                   ` Thomas A. Schmitz
2023-08-18 21:24       ` Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHy-LL_24Z0rK_3X02+26VRexxtp=Nod58zm2KGfD8Dcj+wH=A@mail.gmail.com' \
    --to=mickep@gmail.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).