Re: [XeTeX] Ghostscript 9.53

2021-02-23 Thread jfbu
Hi,

I realize only now thanks to mail of Akira
and also testing by a friend on a system
with older Ghostscript that the file I reported
problems with actually is not XeTeX compatible
even with older Ghostscript.

I focused on gs 9.53.3 due to all warnings

But my friend reports compilation is very
slow also with older gs (I don't know the version)
Then when compilation completes the animation
in the pdf is broken.

At my locale, compilation also finally completes
after 2 to 3 minutes. And the pdf animation
(from animate package and pstricks code)
is even more broken. (this might be the 9.53.3 effect).

In brief, my alarm was unwarranted as the problem
existed earlier.

Best,

Jean-François




[XeTeX] latin-1 encoded characters in commented out parts trigger log warnings

2021-02-21 Thread jfbu
Hi,

consider this

\documentclass{article}
\usepackage{xstring}
\begin{document}
\end{document}

and call it xexstring.tex

Then xelatex xexstring triggers 136 warnings of the type

Invalid UTF-8 byte or sequence at line 35 replaced by U+FFFD.

Looking at file

/usr/local/texlive/2020/texmf-dist/tex/generic/xstring/xstring.tex

I see that this matches with use of latin-1 encoded characters in comments.

Notice that it is a not a user decision here to use a latin-1
encoded file.

In fact I encountered this in a file I was given where
xstring package was loaded by another package.

Regards,

Jean-François




[XeTeX] Ghostscript 9.53

2021-02-20 Thread jfbu
Hi,

Recently I updated Ghostscript and it is now at 9.53.3

It seems xelatex compilation stalls and possibly never
completes on some documents which I have been given
and use pstricks. Here is a shortened console output

$ xelatex foo.tex 
This is XeTeX, Version 3.14159265-2.6-0.92 (TeX Live 2020) (preloaded 
format=xelatex)
restricted \write18 enabled.
entering extended mode
(./foo.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-02-06>

 uses animate package and pstricks

   
   
  
  
  
  
  
  
  
  
 [2] (./foo.aux)

which looks good but then I get about a hundred

    WARNING: .setopacityalpha is deprecated (as of 9.53.0) and will be 
removed in a future release
    See .setfillconstantalpha/.setalphaisshape for the improved solution


which are emitted slower and slower and slower
until finally I have to kill the job

   WARNING: .setopacityalpha is deprecated (as of 9.53.0) and will be 
removed in a future release
   See .setfillconstantalpha/.setalphaisshape for the improved solution
^C(see the transcript file for additional information)
Error 2 (driver return code) generating output;
file foo.pdf may not be valid.
Transcript written on foo.log.


With the latex+dvips+ps2pdf route, compilation succeeds
but the ps2pdf steps output abouts 220 warnings as above to stdout

Also I have to use the -dALLOWPSTRANSPARENCY else the ps2pdf crashes,

I did not know whether to post this to tlbuild or here.
I did a quick check of archives of past few months.
Quite probably the Ghostscript thing has been discussed probably
one or two years ago.
I understand my install is double-faced.
On the texlive side it is darwin-legacy.


However I felt there was a specific xetex issue because
I have to CTRL-C with xelatex, not with ps2pdf.

Regards. 






Re: [XeTeX] problem with discretionary

2017-12-03 Thread jfbu

Only to point out frenchb.ldf (babel-french) does indeed

  \ifdim\the\XeTeXversion\XeTeXrevision pt<0.4pt
\FB@nonchar=255 \relax
  \else
\FB@nonchar=4095 \relax
  \fi

whereas I see no similar thing in gloss-french.ldf

There seems to be two problems now, whereas
I only had one initially

- my mwe does not compile with xetex 0.2

- possibly, polyglossia-french has an issue with
xetex 0.4 and later

Jean-François

Le 3 déc. 2017 à 11:58, jfbu <j...@free.fr> a écrit :

> Thanks Zdeněk!
> 
> Should I thus conclude from this that polyglossia + French is currently 
> broken ?
> indeed the file gloss-french.ldf uses hardcoded 255 at various locations.
> 
> I am a bit lost though because my test mwe
> 
> \catcode`@ 11
> \XeTeXinterchartokenstate=1
> \newXeTeXintercharclass\french@punctthin 
> \XeTeXcharclass `\; \french@punctthin
>  \XeTeXinterchartoks 255 \french@punctthin = {\nobreak\thinspace}%
> \catcode`;\active
> \def;{\discretionary{\char`\;}{}{\char`\;}}
> a;b
> \bye
> 
> compiles fine with current XeTeX, but not with TL2015 XeTeX.
> 
> (the @ thing is only to stay close to control sequence names from 
> gloss-french.ldf)
> 
> To clarify, the \def;{\discretionary{\char`\;}{}{\char`\;}} is analogous to
> the kind of things Sphinx does in verbatim listings to allow linebreaks,
> but isn't the exact thing.
> 
> Anyway, it does not originate from polyglossia nor
> gloss-french.ldf but is a Sphinx add-on inside code listings.
> 
> If the problem can be solved by a patch at macro level, that would
> be best, because it would allow the CPython internationalization
> team to build their PDF docs without worrying about which XeTeX
> they use, I notice some of their team uses Debian 2013.
> 
> Best
> 
> Jean-François
> 
> Le 3 déc. 2017 à 11:01, Zdenek Wagner <zdenek.wag...@gmail.com> a écrit :
> 
>> Hi,
>> 
>> please, notice that the number of character classes was increased from 256 
>> to 4096, so 255 no longer works as a boundary but 4095 must be used. I use 
>> the following code that I took from some other package:
>> 
>> \edef\CSat{\the\catcode`\@} % in order to work in plain XeTeX
>> \catcode`\@=11
>> \ifdefined\e@alloc@intercharclass@top
>>   \chardef\CSboundary=\e@alloc@intercharclass@top
>> \else
>>   \ifdefined\XeTeXinterwordspaceshaping
>> \chardef\CSboundary=4095 %
>> \def\newXeTeXintercharclass{%
>>   \e@alloc\XeTeXcharclass\chardef
>>   \xe@alloc@intercharclass\m@ne\@ucharclass@boundary}
>>   \else
>> \chardef\CSboundary=255
>>   \fi
>> \fi
>> \catcode`\@=\CSat
>> 
>> Afterwards I use \CSboundary instead of a fixed number. It thus works both 
>> with the old and new XeTeX.
>> 
>> 
>> Zdeněk Wagner
>> http://ttsm.icpf.cas.cz/team/wagner.shtml
>> http://icebearsoft.euweb.cz
>> 
>> 2017-12-03 10:19 GMT+01:00 jfbu <j...@free.fr>:
>> Hi,
>> 
>> I need some help to identify which XeTeX release fixed
>> that problem, the mwe is
>> 
>> \catcode`@ 11
>> \XeTeXinterchartokenstate=1
>> \newXeTeXintercharclass\french@punctthin
>> \XeTeXcharclass `\; \french@punctthin
>>  \XeTeXinterchartoks 255 \french@punctthin = {\nobreak\thinspace}%
>> \catcode`;\active
>> \def;{\discretionary{\char`\;}{}{\char`\;}}
>> a;b
>> \bye
>> 
>> In  real life it appeared in a Polyglossia+French context
>> with the semi-colon make active to insert a \discretionary
>> similar to the above. There is no issue in lualatex.
>> 
>> It is currently seen at Python upstream (CPython) when
>> they try to build French docs (via Sphinx)
>> 
>> https://bugs.python.org/issue31589
>> 
>> and it would be nice to pinpoint which XeTeX release
>> precisely is ok. I know 0.2 is bad and 0.6 is good,
>> but can't easily bisect.
>> 
>> Best,
>> 
>> Jean-François
>> 
>> 
>> 
>> 
>> --
>> Subscriptions, Archive, and List information, etc.:
>>   http://tug.org/mailman/listinfo/xetex
>> 
> 



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] are the intercharclasses mentioned in interchar.pdf correct?

2017-03-27 Thread jfbu

Le 27 mars 2017 à 18:36, David Carlisle  a écrit :

> For newer xetex the package needs to be updated for the larger range,
> the test used in teh latex format
> 
> is
> 
> \ifdim\the\XeTeXversion\XeTeXrevision\p@>0.3\p@
>  \chardef\e@alloc@intercharclass@top=4095
> \else
>  \chardef\e@alloc@intercharclass@top=255
> \fi

hi David,

I don't know the details here but
as

*\message{\number\dimexpr0.1pt}
65530
*\message{\number\dimexpr0.2pt}
65531
*\message{\number\dimexpr0.3pt}
65531
*\message{\number\dimexpr0.4pt}
65532
*\message{\number\dimexpr0.5pt}
65533
*\message{\number\dimexpr0.6pt}
65533
*\message{\number\dimexpr0.7pt}
65534
*\message{\number\dimexpr0.8pt}
65535
*\message{\number\dimexpr0.9pt}
65535

it looks a bit of luck that it jumps at 0.4.

Just in case people need to distinguish 0.8 from 0.9
or 0.5 from 0.6 if that is actually relevant
to XeTeX and want to copy this method ;-)

Jean-François





--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] misaligned math if \smash used in subscripts

2017-02-14 Thread jfbu
Le 14/02/2017 à 15:42, Herbert Schulz a écrit :
> 
>> On Feb 14, 2017, at 2:36 AM, jfbu <j...@free.fr> wrote:
>>
>> Hi,
>>
>> just to point out that there is interesting effect if the
>> very first \smash. is simply replaced by an x
>>
>> \hrule
>> $$
>> \hbox{$\left)\vbox to15pt{}\right.$}_{x} % or also _{\hbox{x}}
>> \hbox{$\left)\vbox to15pt{}\right.$}_{\smash.}
>> \hbox{$\left)\vbox to15pt{}\right.$}_{\smash.}
>> $$
>> \hrule
>>
>> Jean-François
> 
> 
> Howdy,
> 
> I only see a single sub-scripted x from the first line. This is with a fully 
> updated TeX Live 2016 originally installed by the MacTeX package.
> 

Hi Herb

I should have reproduced David's lines selecting an OpenType font

\font\m= "[latinmodern-math.otf]/OT:script=math;language=DFLT;" at 10pt
\font\sm= "[latinmodern-math.otf]/OT:script=math;language=DFLT;" at 7pt
\font\ssm= "[latinmodern-math.otf]/OT:script=math;language=DFLT;" at 5pt

\textfont0=\m
\scriptfont0=\sm
\scriptscriptfont0=\ssm


\Umathcode`.= 0 0 `.


The code snippet

>> \hrule
>> $$
>> \hbox{$\left)\vbox to15pt{}\right.$}_{x} % or also _{\hbox{x}}
>> \hbox{$\left)\vbox to15pt{}\right.$}_{\smash.}
>> \hbox{$\left)\vbox to15pt{}\right.$}_{\smash.}
>> $$
>> \hrule

in my post was supposedly following those lines


The effect is that the presence of the x changes the size of the second
parenthesis, Also tested on TL2016.

best

Jean-François





--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] misaligned math if \smash used in subscripts

2017-02-14 Thread jfbu
Hi,

just to point out that there is interesting effect if the
very first \smash. is simply replaced by an x

\hrule
$$
\hbox{$\left)\vbox to15pt{}\right.$}_{x} % or also _{\hbox{x}}
\hbox{$\left)\vbox to15pt{}\right.$}_{\smash.}
\hbox{$\left)\vbox to15pt{}\right.$}_{\smash.}
$$
\hrule

Jean-François


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?

2017-01-28 Thread jfbu
> 
> Three related issues were filed in the fontspec bug tracker, one of which
> has been closed:
> 
>   https://github.com/wspr/fontspec/issues/97
>   https://github.com/wspr/fontspec/issues/98
>   https://github.com/wspr/fontspec/issues/99
> 

Thanks,
Jean-François





--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?

2017-01-25 Thread jfbu
Hi


Le 25 janv. 2017 à 11:13, Zdenek Wagner  a écrit :

> It seems equally clear to me that the fault cannot lie in the fontspec 
> package,
> since it can be demonstrated with a pure XeTeX example as Jean-François
> has shewn ...  Whether the fault lies in the XeTeX engine or in the font is 
> moot,
> I believe.
> 
> It might be set in the font and XeTeX just reads it. I do not know how to 
> look inside the font but I heard somewhere, that such mono fonts do exist. 
> 


I know about lmvtt, for T1 encoding which is a "variable" variant of lmodern 
mono font
for traditional TeX engine, but this has to be requested by specific option,

also Michael Sharpe's newtxtt has such an option (and I use such a "variable 
space" 
mono font extensively in a package doc)

Perhaps Latin Modern Mono has it in the font, and luaotfload intercepts this so 
that
one does not see the phenomenon in the plain LuaTeX example,

Anyway, this will now break all XeLaTeX documents with verbatim parts, and 
default fonts, since the LaTeX 2017/01/01 recently uploaded to CTAN.

Arguably most XeLaTeX users will have set-up their own choice of fonts in
the document, thus the impact may not be that big "in the wild".

Best,

Jean-François



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?

2017-01-25 Thread jfbu

Le 25 janv. 2017 à 10:50, Ulrike Fischer  a écrit :

>> 
> 
> There was once a long discussion about this xetex problem around
> here http://tug.org/pipermail/xetex/2011-February/020072.html

Hi, 

[somewhat peripheral question]

in http://tug.org/pipermail/xetex/2011-February/020099.html
(and also in one earlier post) in the thread pointed out by Ulrike,
Matthew Skala commented on a WordSpace issue with fontspec.

Has this issue been fixed since in fontspec ?

Jean-François




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


[XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?

2017-01-24 Thread jfbu
Hi,

test file

% Tested with TeXLive 2016, up-to-date.

% xetex
\XeTeXtracingfonts=1
\font\test="[lmmono10-regular.otf]"\test

% result otherwise with luatex:
% (I don't know how to load font with luatex without luaotfload.sty)
%\input luaotfload.sty
%\font\test=[lmmono10-regular]:\test

\the\fontdimen2\font
\quad
\the\fontdimen3\font
\quad
\the\fontdimen4\font

\nopagenumbers
\bye

xetex: 5.25pt 2.625pt 1.75pt

Requested font "[lmmono10-regular.otf]" scaled 1000
 -> /usr/local/texlive/2016/texmf-dist/fonts/opentype/public/lm/lmmono10-regula
r.otf
 [1] )

luatex:5.25pt 0.0pt 0.0pt



% Local variables:
% TeX-engine: xetex
% End:

The stretch and shrink causes issues in code listings.

This impacts LaTeX now that Unicode engines
use the Latin Modern fonts in opentype format by
default with it.

LaTeX test file:

\documentclass{article}

\begin{document}
\ttfamily

\the\fontdimen2\font
\the\fontdimen3\font
\the\fontdimen4\font

\fontname\font

\showoutput
\thispagestyle{empty}
\end{document}
% Local variables:
% TeX-engine: xetex
% End:

xelatex: 5.25pt2.625pt1.75pt  "[lmmono10-regular]:"
lualatex:5.25pt0.0pt0.0pt [lmmono10-regular]:

Best,

PS: as I don't currently subscribe to the list, could you please
CC my address if replying thanks.

Jean-François




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


[XeTeX] shrinkability and stretchability of interword space with default monotype font

2016-01-24 Thread jfbu
Hi,

some years ago I noticed that the interword space with the 
default monotype font had some stretchability and shrinkability,
which results in problems in verbatim environments when
the line is long enough to go into the right margin.

I raised an issue there

https://github.com/wspr/fontspec/issues/139

which was not very well formulated, and besides I probably
posted at the wrong place, as this isn't a fontspec issue, 
as stressed again by recent comment by David there:

https://github.com/wspr/fontspec/issues/139#issuecomment-174298868

Should I raise an issue on http://sourceforge.net/p/xetex/bugs/ ?

please CC to my address as I don't currently subscribe to the list,

best,

Jean-François






--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] shrinkability and stretchability of interword space with default monotype font

2016-01-24 Thread jfbu

Le 24/01/2016 16:49, Philip Taylor a écrit :

What is "the default monotype font", please ?



the one selected by \ttfamily under LaTeX or by \tt
under Plain TeX in absence of any specific font loading
packages

Best,
Jean-François


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex


Re: [XeTeX] shrinkability and stretchability of interword space with default monotype font

2016-01-24 Thread jfbu

Le 24 janv. 2016 à 16:49, Philip Taylor  a écrit :

> What is "the default monotype font", please ?


Phil,

sorry about the confusion.

I understand now, I made the error four years ago in the title
of my fontspec report. I was meaning to say "monospace". 

And currently I don't know why "monotype" or "teletype" come
to my mind in this context.

Then today I only copied without thinking my earlier formulation,
hence perpetuating the error.

Jean-François
PS to Herbert: please CC to me if you reply as I don't subscribe to the list.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex