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
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/t
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 2
,
Jean-François
Le 3 déc. 2017 à 15:34, jfbu a écrit :
>
> Hi,
>
> regarding the character class issue
>
> (which isn't directly the one
> I had reported at http://tug.org/pipermail/xetex/2017-March/027056.html
> and again at top of this re-newed thread)
>
cz/team/wagner.shtml
> http://icebearsoft.euweb.cz
>
> 2017-12-03 12:18 GMT+01:00 jfbu :
>
> Only to point out frenchb.ldf (babel-french) does indeed
>
> \ifdim\the\XeTeXversion\XeTeXrevision pt<0.4pt
> \FB@nonchar=255 \relax
> \else
> \FB@nonc
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 a écrit :
> Thanks Zdeněk!
>
> Should I thus conclude from this that polyglossia + French is currently
> broken
hus 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 :
> Hi,
>
> I need some help to identify which XeTeX release fixed
> that problem, the mwe is
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
\
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@i
Hi,
the problem is already fixed at XeTeX 0.6 but it shows
with 0.2 (TL2015), I tried to browse the commit history
at sourceforge to check which commit fixed that,
but I am not familiar enough with the repository, and besides
it could have been fixed as a collateral and perhaps a test
file
Le 14/02/2017 à 15:42, Herbert Schulz a écrit :
>
>> On Feb 14, 2017, at 2:36 AM, jfbu wrote:
>>
>> Hi,
>>
>> just to point out that there is interesting effect if the
>> very first \smash. is simply replaced by an x
>>
>> \hrule
>>
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ço
>
> 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
--
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
> mo
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 als
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\font
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 "monotyp
Le 24/01/2016 16:49, Philip Taylor a écrit :
What is "the default monotype font", please ?
sorry about my earlier reply, I am busy with other things
this formulation dates back to my report on fontspec issue tracker
hence "default monotype font" is what got selected by \ttfamily in this MWE:
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
--
Subscription
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/i
20 matches
Mail list logo
