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
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
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 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
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 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
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
>
> 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,
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
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,
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 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,
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
\
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
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
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
,
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)
>
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
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,
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
20 matches
Mail list logo