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:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Wed, 12 Jan 2011 08:50:18 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
On 06/01/2011 11:12, Frank Mittelbach wrote:
>  > 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.

The current scaling/resizing code is meant to be equivalent to graphicx
scaling operations for graphics. It seems likely that user-level 'box'
functions for LaTeX3 will actually use coffins. After implementing the
rotation code, looking at graphicx suggested that resizing should also
be provided. (This will be needed for including graphics in LaTeX3
documents, for example.) So the aim here was not so much complex design
layouts as getting on with implementing something that will be needed at
some stage.

The same argument also applies to boxes with stretchable components.
However, this is 'to be done'. As Frank says, this may be an area where
an alternative interface is in the end the best approach.
-- 
Joseph Wright

ATOM RSS1 RSS2