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
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0 (Apple Message framework v1081)
Content-Type:
text/plain; charset=us-ascii
Date:
Mon, 14 Nov 2011 16:30:20 +1030
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
Message-ID:
In-Reply-To:
Content-Transfer-Encoding:
8bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (55 lines)
Hi Brent,

Thanks for writing! Just a real quick reply to get my thoughts out there... 

On 13/11/2011, at 9:50 PM, Brent Longborough wrote:

> First, if there's a better place for the substance of this email, please
> let me know and I'll go there rather than filling up your inbox.

We certainly don't mind our inboxes clogged.
In the future, however, probably better to direct such messages to LaTeX-L for wider discussion.


> Now, the meat: in a recent post on TeX.sx, Joseph was sufficiently
> incautious to say "Feature requests always welcome!". Here goes:

> 
> 1.	I've already mentioned publicly that it would be nice to have xcoffin
> (semi-)primitives to provide the equivalent of \TotalHeight, \Height,
> \Depth, and \Width for an arbitrary selected coffin, outside the context
> of \SetXxxPole. I know it's easy to do for myself, but a single, common,
> supported method would be "more comforting".

Agreed, I think. Can you provide an example of what you'd like (even better with what you currently might use as a workaround) just so we're 100% clear on the context?


> 2.	In the area of Diagnostic Functions, for those of us who are slightly
> spatially challenged, a suggestion for an additional diagnostic that
> might be useful for "complex funerals". This would be called something
> like "\DisplayIntersectingPoles", and although I'm not sure what its
> parameters would look like, here's how it might work: it would calculate
> a handle position based on two intersecting poles, and then the draw
> poles as lines between this handle and the respective centerline poles
> of the two coffins involved.

We have discussed rules & coffins in the past, and this would be a good application for that. I agree it would be nice when debugging some alignment aspects. I'm not aware of any actual plans to implement this in the near term, however. At the time I don't think we really knew how the interface would/should work.


> 3.	(I accept that you might consider this one a bit cheeky; I don't even
> know if it's possible): for coffins containing text, provide a means of
> defining left and right poles that align with the glyph outlines,
> excluding sidebearings. I realise this is quite challenging even to
> specify --- what to do, for example, when a glyph's ink protrudes into
> the sidebearing. I can also accept, up front, that this has nothing to
> do with xcoffin per se; but it would be a very useful feature.

This isn't so cheeky when you consider the use case. Lining up glyphs by their ink would definitely be a feature when designing titlepages and the like.

I'm going to go out on a limb and suggest this won't be provided in the medium-term by the base package for one main reason: calculating side-bearings is only possible in XeTeX and LuaTeX, so pdfTeX would not be able to support this feature. (Although graceful degradation *could* be an option here.)

I'm not actually aware of a user-friendly way to access side-bearings in LuaTeX, but it would be easy to imagine a package that provided such facilities for both unicode engines and then a hook into the coffins code to allow these poles to be calculated somewhat automatically.

Cheers,
-- Will

ATOM RSS1 RSS2