LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 12 Nov 2018 16:38:05 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
Hi Kelly,

> While working on my class, I’ve been thinking about the available tools and
> where 2e is necessary vs. what can be replaced with L3 methods.
> 
> I know that there isn’t a consensus on how boxes should work, so things like
> `\parbox` and friends should still be used (unless coffins happen to work
> better for a given use case).
> 
> However, I think there’d be no harm in providing an L3 interface for dims and
> skips. I know that the 2e kernel already provides tools for this, and so an L3
> interface would have some redundancies. I think an `xskips` package would still
> be useful because:
> 
>    1. it would provide more tools than 2e does; and
>    2. it would harmonize with the other L3 design-level interfaces.

that's a good question what harmonizes with L3 design-level interface.

Remember that we think of the designer level of more or less free of 
programming, i.e., you make declarations (possibly using CamelCase 
syntax but you don't "program" (or if you do, because the features you 
are looking for require that it would be in a clearly separate section 
that is actually package code only not separated out --- and then that 
kind of code would be direct expl3).

So what is the purpose for example of \VerticalSpace? would it have a 
natural place to live and if so why?

I guess our ask here would be use cases for the commands you proposed to 
get a feeling whether they should and if so in what form they should be 
provided but not embark on making a copy of the expl3 code interfaces 
1-2-1 into CamelCase unless we all agree on seeing a good reason for it.

There are of course boundary cases, eg

a function for setting length parameters should naturally support 
evaluations of its value argument (which right now \newlength doesn't 
offer (unless you load calc.

But already the distinction between skips and dimens (that exist on the 
programming level but not on the 2e user level in the setters) is 
something to ponder. An I would be interested to see examples why the 
distinction os sensible on the designer level (I'm not convinced it is)
I mean, why shouldn't there be a single set of design-level setters.

As for allocation, to what extend are they needed on the design level? 
Aren't they only needed when you are actually asking for some programmed 
code?

> I have attached the raw .sty code which contains what I think are appropriate
> tools for the designer level. Of course, this would become a proper .dtx file
> with documentation and examples.

So rather than documenting that suggestion, I would ask for convincing 
examples for each of the proposed functions that are design tasks that 
should live in a class file rather than programming tasks that should 
live in package/modules that offer building blocks for titles building 
blocks for headings etc etc.

I'm not saying none of them are, maybe some are the right choice for the 
design level, but instead of embarking on providing stuff that we later 
regret, let us first better understand the needs. So if you have the 
time I would very much look forward in seeing how you intend to use each 
and every of these functions.

best
frank


ps while we are at it, uses of \parbox and friends (or coffins) would be 
also very much of interest. where do you use them and how ...

ATOM RSS1 RSS2