[XeTeX] The status of XeTeX

[Philip Taylor]

May I ask whether XeTeX is still being "actively" ( or even passively) developed ?  I ask because, once again, I came up against a fundamental limitation of XeTeX yesterday — the fact that a font can be defined to be of a specific colour, but the colour model is restricted to RGB.  Given that (IMHO), the vast majority of XeTeX output is intended for print rather than for on-screen display, would it be possible to add support for additional colour models (and specifically for CMYK) in a future instantiation of the \font primitive ?

[Adam Twardoch (Lists)]

Phil,

Looking at the Sourceforge activity:
https://sourceforge.net/p/xetex/code/commit_browser
the latest source is v0.99999 which was prepared in February 2018 for TeX
Live 2018.

The changes seem to be bugfixes and seem to mostly originate from Japanese
contributors. They are summarized at

https://sourceforge.net/p/xetex/code/ci/master/tree/source/texk/web2c/xetexdir/NEWS

and there have been a few minor changes after that. It looks like
"features" were last added in 2016. It seems like XeTeX does not have very
active development or maintenance, but there is some.

I would encourage you to file a feature request at
https://sourceforge.net/p/xetex/feature-requests/

If it's recorded, it's possible that at some point someone will address it.

On Sun, 16 Sep 2018 at 19:31, Philip Taylor <***@rhul.ac.uk> wrote:
May I ask whether XeTeX is still being "actively" ( or even passively)
developed ? I ask because, once again, I came up against a fundamental
limitation of XeTeX yesterday — the fact that a font can be defined to be
of a specific colour, but the colour model is restricted to RGB. Given
that (IMHO), the vast majority of XeTeX output is intended for print rather
than for on-screen display, would it be possible to add support for
additional colour models (and specifically for CMYK) in a future
instantiation of the \font primitive ?

[Philip Taylor]

Thank you Adam — I will do as you suggest.  Karljürgen's comment is interesting, and may well reflect reality, but nonetheless I believe that support for CMYK (and perhaps for other colour models) would be a worthwhile addition to an invaluable piece of software.

** Phil.
--------

I would encourage you to file a feature request at  
https://sourceforge.net/p/xetex/feature-requests/

[Karljürgen Feuerherm]

I think that historically what you say about print is true... but I produce many many PDFs (syllabi, documentation, slide presentations) and for all intents and purposes non of them go to print anymore; simpler and cheaper to view on screen.

Still interested in the answer though!

Karljürgen

Sent from my iPhone

May I ask whether XeTeX is still being "actively" ( or even passively) developed ? I ask because, once again, I came up against a fundamental limitation of XeTeX yesterday — the fact that a font can be defined to be of a specific colour, but the colour model is restricted to RGB. Given that (IMHO), the vast majority of XeTeX output is intended for print rather than for on-screen display, would it be possible to add support for additional colour models (and specifically for CMYK) in a future instantiation of the \font primitive ?
--
<Signature>
Philip Taylor
--------------------------------------------------
http://tug.org/mailman/listinfo/xetex

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mail

[Apostolos Syropoulos]

Post by Philip Taylor
the fact that a font can be defined to be of a specific colour, but the colour model is restricted to RGB.

And what is wrong in using the color or xcolor (or event the xespotcolor) packages?

A.S.
----------------------
Apostolos Syropoulos
Xanthi, Greece

[Philip Taylor]

Post by Apostolos Syropoulos
And what is wrong in using the color or xcolor (or event the xespotcolor) packages?

The colour (etc) packages are intended to offer colour support for engines such as TeX and PdfTeX that do not offer intrinsic colour support at the primitive level.  XeTeX /does /offer intrinsic colour support at the (\font) primitive level, but that support is currently limited to the RGB colour model.  The colour (etc) packages can, of course, be used with XeTeX, and for some operations their functionality may well be beneficial or even necessary (if one does not want to use \pdfliteral or similar mechanisms), but they do not extend the functionality of the XeTeX \font primitive and are therefore not of direct benefit in the context of the original proposal.  Furthermore, if they are to be used in conjunction with XeTeX rather than with XeLaTeX, they require additional packages such as "miniltx" or "eplain" to be loaded, thus adding considerable overheads (while at the same time reducing robustness, since such packages can and do evolve over time) if one simply wishes to
have one or more fonts rendered in a particular (non-black) colour, functionality which XeTeX natively supports.
/-- //
//<Signature>
Philip Taylor/


--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
ht

[Zdenek Wagner]

Post by Apostolos Syropoulos
And what is wrong in using the color or xcolor (or event the xespotcolor) packages?

The colour (etc) packages are intended to offer colour support for engines such as TeX and PdfTeX that do not offer intrinsic colour support at the primitive level. XeTeX /does /offer intrinsic colour support at the (\font) primitive level, but that support is currently limited to the RGB colour model. The colour (etc) packages can, of course, be used with XeTeX, and for some operations their functionality may well be beneficial or even necessary (if one does not want to use \pdfliteral or similar mechanisms), but they do not extend the functionality of the XeTeX \font primitive and are therefore not of direct benefit in the context of the original proposal. Furthermore, if they are to be used in conjunction with XeTeX rather than with XeLaTeX, they require additional packages such as "miniltx" or "eplain" to be loaded, thus adding considerable overheads (while at the same time reducing robustness, since such packages can and do evolve over time) if one simply wishes to
have one or more fonts rendered in a particular (non-black) colour, functionality which XeTeX natively supports.
/-- //
//<Signature>
Philip Taylor/

It is not IMHO neded to use large packages, you can change colours
directly by an appropriate \special. However, this may cause issues
with a colour stack. Suppose that you have an important paragraph that
should be printed in blue. Within this paragraph you will refer to a
footnote that will have to be printed in red. The important paragraph
is long and will continue to the next page. The footnote is long as
well and will continue on the next page. Will the colours survive?

And in addition to the texts, we need rules so we should be able to
set colours of \vrule and \hrule as easily as a colour of a font.
Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

--------------------------------------------------
http://tug.org/mailman/listinfo/xetex

--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/ma

[Philip Taylor]

Post by Zdenek Wagner
And in addition to the texts, we need rules so we should be able to
set colours of \vrule and \hrule as easily as a colour of a font.

Agreed (and also background colours for boxes and pages), but I would be reluctant to propose too much in a single "Request for enhancement"; I would sooner gain support for CMYK in the \font primitive now, and wait for support for coloured rules (and boxes, and pages), rather than risk delaying things (or jeopardising them completely) by asking too much in a single proposal.

[Zdenek Wagner]

Post by Philip Taylor

Post by Zdenek Wagner
And in addition to the texts, we need rules so we should be able to
set colours of \vrule and \hrule as easily as a colour of a font.

Agreed (and also background colours for boxes and pages), but I would be reluctant to propose too much in a single "Request for enhancement"; I would sooner gain support for CMYK in the \font primitive now, and wait for support for coloured rules (and boxes, and pages), rather than risk delaying things (or jeopardising them completely) by asking too much in a single proposal.
--

I agree. I just wanted to support your request.

Post by Philip Taylor
<Signature>
Philip Taylor

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz



--------------------------------------------------
Subscriptions, Archive, and List information, etc.: