LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML 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, 16 Sep 2015 07:22:00 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
On 16/09/2015 01:51, Bruno Le Floch wrote:
> On 9/15/15, Joseph Wright <[log in to unmask]> wrote:
>> On 15/09/2015 09:12, Alexander Grahn wrote:
>>> Good morning,
>>>
>>> There is a number of functions in the new l3sys package for testing the
>>> current engine, but I am still missing a public interface for testing
>>> the driver. The l3drivers package internally uses some mechanism to
>>> distinguish between pdfmode, dvips, dvipdfmx and xdvipdfmx. Will there be
>>> such a testing be included in the public interface of expl3 one day?
>>>
>>> Currently, I am still using a combination if the `ifpdf' package and the
>>> \*_if_engine* functions for the purpose of driver detection.
>>>
>>> Kind regards,
>>> Alexander
>>
>> Hello Alexander,
>>
>> Adding material to l3sys is on the 'to do' list but there are several
>> things there for 'soon'! I can certainly look to add a DVI/PDF test
>> (definitely one to do).
>>
>> In terms of drivers, we could/should move that code to l3sys anyway. The
>> question of to what extent any code of this form should be outside of
>> the kernel is tricky: for say drawing I can imagine something akin to
>> pgf's system layer with a low-level public interface on top (there are a
>> limited number of well-defined operations). For what you want (I'm
>> guessing) that's not so clear: I've not looked in detail but I assume
>> the entire set up for movie inclusion is highly system-dependent.
>>
>> Joseph
> 
> I think it makes sense indeed to provide a conditional for the driver
> in use.  However, we should provide wrappers for most operations
> (drawing, graphics inclusion, color handling) and explicitly advise
> people to use these wrappers rather than the driver conditional.
> Movie inclusion is a bit special and may be beyond what we want to
> provide wrappers for.  But maybe it could make sense to include a
> trimmed-down version of media9 as a team-supported package?
> 
> Bruno

Quite: I can see how to abstract graphics inclusion, basic drawing
operations, etc. but probably not the complexities of movie inclusion!

Joseph

ATOM RSS1 RSS2