LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Thu, 6 Jan 2011 12:12:07 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (33 lines)
Joseph Wright writes:
 > On 05/01/2011 18:42, Frank Mittelbach wrote:
 > > Joseph did a cleaner reimplementation of that recently. This new
 > > implementation is working very nicely and it is available from the svn for
 > > people who want to play with it.
 > 
 > I have updated a snapshot to CTAN, as part of xpackages. You can 
 > therefore download xpackages.tds.zip for testing [once Robin has 
 > installed it, of course :-)].

ah, Joseph already announced this ... me too late as usual.

 > > Basically what xcoffins currently does is to provide a fairly natural way
 > > for specifying how boxes (called coffins for some reason) are to be
 > > aligned to each other including rotation and with Joseph's implementation
 > > also scaling.
 > 
 > Scaling here means 'stretching the content of the box', i.e. 
 > graphic(s/x)'s \scalebox and \resizebox.

I might add that the stretching and scaling is a part that I'm least convinced
off. Not that it is wrong or should be taken out, but that I doubt that this
particular functionality is often needed. There are use cases for it, I
guess. But in many cases a designer wouldn't want to loose control over font
sizes which will be the result of such type of scaling.

There is another type of scaling/sizing which stretches the inner glue of a
box and which isn't implemented. Again I don't think that there are many
applications for it, but I would expect equal number of use cases for this
type too. So perhaps we should consider this as well.

frank

ATOM RSS1 RSS2