References: <20150915081218.GA31916@hzdr.de>
            <55F88867.90907@morningstar2.co.uk>
            <CANQYN6yqSRZZEJ2HTadtx27AETfpYXkQn_xFuCLHiyaWLQSM6g@mail.gmail.com>
            <55F90A88.6050308@morningstar2.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Message-ID:  <20150916074452.GB13341@hzdr.de>
Date:         Wed, 16 Sep 2015 09:44:52 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Alexander Grahn <A.Grahn@HZDR.DE>
Subject: Re: interface for test on driver being used
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <55F90A88.6050308@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On Wed, Sep 16, 2015 at 07:22:00AM +0100, Joseph Wright wrote:
>On 16/09/2015 01:51, Bruno Le Floch wrote:
>> On 9/15/15, Joseph Wright <joseph.wright@morningstar2.co.uk> 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
>

Thank you all for the feedback,

indeed, my question was motivated by issues arising during the
maintainance of the media9 package.

Therein, the code branches according to the output driver in order to
implement a unified (driver independent) interface for low-level PDF
operations mostly modelled after those provided by PDFTeX, a few after
Adobe's pdfmark specification. This is quite independent from the actual
package's purpose of media inclusion. The interface could be used within
other packages related to PDF features and has, indeed, been used in
the ocgx2 package already.

There are other packages trying to implement such an interface,
e. g. hyperref or navigator. But they turned out to not be useable for
my purposes because the interface they provide is either incomplete or
not sufficently low-level.

This is the list of pdfTeX commands/ pdfmarks:
\pdfobj, \pdflastobj, \pdfannot, \pdflastannot,
\pdfstartlink ... \pdfendlink,
\pdfxform, \pdflastxform, \pdfximage, \pdflastximage, \pdfcatalog,
/BDC & /EMC pdfmarks

I would need tests for

pdfmode (pdftex,luatex)
dvipdfmx/xetex (pdftex,luatex,(u)ptex)
dvips (pdftex,luatex)

Kind regards,
Alexander