Activity for XeTeX - Unicode-based TeX
-
Explorer created ticket #204
The font selection not find issues for certain CJK fonts with family name?
-
Anonymous posted a comment on ticket #89
I'm still having this issue! My Tex Live is 2025 - I'm using Charis SIL and trying to use \widehat on a Mac. This is my MWE: \documentclass{article} \usepackage{unicode-math} \setmathfont{XCharter Math} \usepackage{fontspec} \DeclareMathAlphabet\mathcal{OMS}{cmsy}{m}{n} \begin{document} $\widehat{\mathcal{C}}$ \end{document}
-
karl berry posted a comment on ticket #203
I sent Hans the plain TeX example, but I don't think he did anything with it. Feel free to write him yourself if you want, or let's just forget the whole thing. Sorry for the noise. So many more important things to spend time on ...
-
Jonathan Kew posted a comment on ticket #203
I guess my remaining question, then, would be whether Hans has reproduced the issue with that simplified example, or has he only encountered it within ConTeXt? If it's somehow unique to his machine, or if he can't reproduce it outside of the ConTeXt system, then I don't see anything actionable here at the moment. I'm not going to attempt to understand and debug a whole ConTeXt environment.
-
I can't run anything on Windows, so no, I can't confirm :(. There's nothing post-TL25(or pre-TL25) that would affect this, as far as I know. Nothing serious has changed in the xetex sources in years, apart from the JP devs making it work better with over-BMP chars. Anyway, Hans was using the released TL25 binary. Thanks for looking into it so carefully. Guess there's nothing to be done.
-
Nope, I can't reproduce this. I installed TL2025 on Windows, and I get exactly the same result from xetex there as I do on macOS, and the same as I get from pdftex: see screenshot. Can you confirm that your example does produce the unexpected results on Windows for you? Are you using the exact same xetex version, or is there maybe a post-TL2025 build that's broken something?
-
Thanks for looking further. Weird! My guess is there's some kind of compiler or standard-library option in Akira's build that is causing overflow to be handled differently from what we see on the other platforms. I've started an install on a Windows machine to see how it behaves for me....
-
P.S. If you have any time/interest in looking into things, just glancing over the open bug list shows a variety of things that presumably affect people's real-life output. Stacking diacritics (182), all the rtl stuff, etc. Unfortunately almost all the bugs are reported from "nobody" so it's hard to tell what might be important, i.e., from the latex team. P.P.S. There's also #185, where Ross Alexander sent in patches to purportedly "fix" an observable minute line breaking difference with the other...
-
This runs under initex. And it shows that the problem is apparently Windows-specific, as Hans is running on Windows. i get the same results for pdftex and xetex in tl25 on x86_64-linux, as you did. What's different in Akira's build is not something I want to delve into ... \catcode`\{=1 \catcode`\}=2 \catcode`\^=7 \newlinechar=`^^J \font\tenrm=cmr10 \tenrm \def\space{ } % \setbox0\hbox{\romannumeral 3910725} \message{^^J[3910725: \the\wd0 \space cf. 32722.85156pt]^^J} % \setbox0\hbox{\romannumeral...
-
Hi Karl - that was me, I just hadn't logged in to SF when I first posted. (Only realized when it went into the moderation queue.) Regarding debugging, I know it's been sadly neglected, but if there were a simple plain- or ini-based testcase for this, there's some chance it might be an obvious fix. But I can guarantee I'm not going to dig through layers of ConTeXt macros to figure out what it's doing. Maybe it's sufficiently obscure that it won't really affect anyone, though.
-
Hello anonymous - thanks for your reply. If I thought anyone would ever actually debug xetex again, I'd ask Hans or figure out how to reproduce it outside of ConTeXt. Or figure out exactly how to run it in ConTeXt. As it is, there are far, far, more important bugs already submitted, so I'm not inclined to spent more time on this obscurity ...
-
Anonymous posted a comment on ticket #203
A context-free (just plain-TeX-based) testcase would be helpful here. It's not immediately clear to me what ends up going into the \hbox in the example. FWIW, I tried the following, which I thought might be more-or-less equivalent: \newcount\i \i=0 \newcount\step \step="FFF \newcount\stop \stop="FFFFFF \loop \ifnum\i < \stop \setbox0=\hbox{\romannumeral\i} \immediate\write16{!!!! \the\wd0} \advance\i by \step \repeat \end but did not see the behavior described. I do see the logged dimension "wrapping"...
-
strange behavior with large \romannumeral
-
Anonymous posted a comment on ticket #202
Thanks for confirming, and for the nice workaround. Note that there was a problem with TeX--XeT and hyphenation before https://tex.stackexchange.com/questions/141769/bidi-and-hyperref-change-hyphenation, but now I guess this is related to how XeTeX shapes chunks of text (using ICU and HarfBuzz) when a system font is used (but I know nothing about the source code).
-
Yes, this appears to be a bug; thanks for reporting. I think a workaround would be to add \hskip0pt before the \endL command.
-
Anonymous created ticket #202
Incorrect hyphenation inside short directinality switch with system font
-
Hi Yannis - as far as I know, no one is developing XeTeX any more. If you can make a patch, I can apply it. Otherwise, I doubt this will happen. Sorry, but that's the reality to the best of my knowledge. (Jonathan or Arthur or anyone, you can chime in if it's something you can work on.)
-
Yannis Haralambous created ticket #201
Implementing ICU ubidi_setClassCallback() to allow directionality change for PUA characters
-
Bug: texlive-xetex/jammy,now 2021.20220204-1 all on Ubuntu 22 requires harfbuzz-1.4.2
-
Closing this at Karl's request.
-
Glad you found a way through, Jean.
-
Anonymous posted a comment on ticket #200
Addressed by compiling the newest harfbuzz-8.5.0 with the "--with-graphite2=yes" option, and pointing LD_LIBRARY_PATH to harfbuzz-8.5.0's installation path. cd /root apt-get install ragel wget https://github.com/harfbuzz/harfbuzz/releases/download/8.5.0/harfbuzz-8.5.0.tar.xz tar -xvf harfbuzz-8.5.0.tar.xz cd harfbuzz-8.5.0 ./configure --prefix '/usr/local/harfbuzz-8.5.0' --with-graphite2=yes make make install export PATH=/usr/local/harfbuzz-8.5.0/bin:$PATH export LD_LIBRARY_PATH=/usr/local/harfbuzz-8.5.0/lib:$LD_LIBRARY_PATH...
-
Jean Ye created ticket #200
Bug: texlive-xetex/jammy,now 2021.20220204-1 all on Ubuntu 22 requires harfbuzz-1.4.2
-
Anonymous posted a comment on ticket #185
Hello Karl, I noticed there is an error in your example where the problem size is 10.95pt but the example has 10.90pt, which works. \fi at 10.90pt \loggingall \1 \test{Dest-Addr} % unwanted line breaks right after hyphen char % none of 10.94pt nor 10.96pt can reproduce the problem with xetex. I did find where a rounding error does happen in XeTeX_err.c. At 10.95pt in the function measure_native_mode (around line 2100) width = positions[totalGlyphCount].x; node_width(node) = D2Fix(width); This is...
-
Here is a version of the test document that runs under -ini, and also runs with both xetex and luatex. Reply posted to the thread following https://tug.org/pipermail/tex-live/2024-February/049883.html ...
-
Just adding references to other/original reports: https://github.com/lvjr/tabularray/issues/16 https://tex.stackexchange.com/q/600010/2388
-
Anonymous posted a comment on ticket #185
This is a rounding issue where D2Fix rounds the double by addiing 0.5 before it converted into an integer, effectively rounding the number, rather than just truncating it. If the +0.5 is removed (so it just (int)(d * 65556.0) then this issue (and a number of issues I've had with tblr environments) goes away. I suspect (and this is a guess) that the rounding up exceding the size of the box calculated somewhere else.
-
Anonymous created ticket #199
Incorrect version check on pdftex
-
Andreas Scherer posted a comment on merge request #5
See also Bug Ticket 171: https://sourceforge.net/p/xetex/bugs/171/ XeTeX is included in https://ctan.org/pkg/knuth-pdf and https://ctan.org/pkg/knuth-hint
-
Anonymous posted a comment on ticket #93
It looks like xdvipdfmx is still overwriting the Producer metadata field. Can we fix it please?
-
Anonymous posted a comment on ticket #185
A plaintex example \parindent=0pt \def\test#1{% \setbox0=\hbox{#1} \vbox{\hsize=\wd0 \leftskip0pt plus 1fil #1} % emulate \raggedleft etc. \vbox{\hsize=\wd0 \rightskip0pt plus 1fil #1} \vbox{\hsize=\wd0 \leftskip0pt plus 1fil \rightskip\leftskip #1} \par } \font\1="[lmroman10-regular]" at 10pt \1 \test{Dest-Addr} % ok \font\1="[lmroman10-regular]" at 10.95pt \1 \test{Dest-Addr} % unwanted line breaks right after hyphen char % none of 10.94pt nor 10.96pt can reproduce the problem \font\1="[lmroman10-regular]"...
-
Anonymous posted a comment on ticket #195
Thank you!
-
Dmitriy Alexandrov posted a comment on ticket #195
Related MR: https://sourceforge.net/p/xetex/code/merge-requests/6/
-
Anonymous created merge request #6 on Code
Fix zlib build (bug #195)
-
Glenwing posted a comment on ticket #198
Forgot to mention: This is XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022) (preloaded format=xelatex 2023.1.7)
-
Opentype Stylistic Set not working on scaled parentheses
-
Just A. Man posted a comment on ticket #56
Output with XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022/Debian) still bad.
-
Henri's bug is still there with XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022/Debian) (preloaded format=xelatex 2023.2.17).
-
As of now, I get the expected =: https://i.imgur.com/cbRnVpE.png . The bug report can be closed.
-
As of now, I get the expected =: https://i.imgur.com/cbRnVpE.png
-
As of now, I get the expected =:
-
As of now, I get the expected =:
-
As of now, the second output looks bad (but is no longer garbage). Running xelatex on \documentclass{article} \pagestyle{empty} \usepackage{unicode-math} \newcommand{\pSymbol}{\prec} \begin{document} \(\not\prec_a\) \(\not\pSymbol_a\) \end{document} yields https://i.imgur.com/8SeM0hl.png .
-
As of today, the font file has been renamed, and the code should read \documentclass{article} \usepackage{unicode-math} \setmathfont[Extension=.otf]{LibertinusMath-Regular} \begin{document} \(\scriptstyle \left(\right)\) \end{document} Running xelatex on it does produce () now. The bug report can be closed.
-
Xiao Hanyu posted a comment on ticket #197
I kind of prefer approach 2 here, by modifying build.sh and force the project to use gcc/g++.
-
Shitty format, revised: To override this and force to use gcc for compiling libs/icu, there're several ways: call build.sh with CC=gcc CXX=g++ ./build.sh modify build.sh: diff --git a/build.sh b/build.sh index 4e556321..f21c859a 100755 --- a/build.sh +++ b/build.sh @@ -189,7 +189,7 @@ fi if [ "$ONLY_MAKE" = "FALSE" ] then - TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS $CONF_OPTIONS || exit 1 + CC=gcc CXX=g++ TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS...
-
Shitty format, revised: To override this and force to use gcc for compiling libs/icu, there're several ways: - call build.sh with CC=gcc CXX=g++ ./build.sh - modify build.sh: diff --git a/build.sh b/build.sh index 4e556321..f21c859a 100755 --- a/build.sh +++ b/build.sh @@ -189,7 +189,7 @@ fi if [ "$ONLY_MAKE" = "FALSE" ] then - TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS $CONF_OPTIONS || exit 1 + CC=gcc CXX=g++ TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS...
-
Shitty format, revised: To override this and force to use gcc for compiling libs/icu, there're several ways: 1. call build.sh with CC=gcc CXX=g++ ./build.sh 2. modify build.sh: diff --git a/build.sh b/build.sh index 4e556321..f21c859a 100755 --- a/build.sh +++ b/build.sh @@ -189,7 +189,7 @@ fi if [ "$ONLY_MAKE" = "FALSE" ] then - TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS $CONF_OPTIONS || exit 1 + CC=gcc CXX=g++ TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS...
-
Shitty format, revised: To override this and force to use gcc for compiling libs/icu, there're several ways: 1. call build.sh with CC=gcc CXX=g++ ./build.sh 2. modify build.sh: diff --git a/build.sh b/build.sh index 4e556321..f21c859a 100755 --- a/build.sh +++ b/build.sh @@ -189,7 +189,7 @@ fi if [ "$ONLY_MAKE" = "FALSE" ] then - TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS $CONF_OPTIONS || exit 1 + CC=gcc CXX=g++ TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS...
-
Shitty format, revised: To override this and force to use gcc for compiling libs/icu, there're several ways: 1. call build.sh with CC=gcc CXX=g++ ./build.sh 2. modify build.sh: diff --git a/build.sh b/build.sh index 4e556321..f21c859a 100755 --- a/build.sh +++ b/build.sh @@ -189,7 +189,7 @@ fi if [ "$ONLY_MAKE" = "FALSE" ] then TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS $CONF_OPTIONS || exit 1 CC=gcc CXX=g++ TL_MAKE=$MAKE ../source/configure $CONFHOST $CONFBUILD $WARNINGFLAGS...
-
Project failed to build on environment with clang
-
Current master branch failed to build on ubuntu 20.04
-
XeTeX's zlib failed to build with autoconf 2.70+ version
-
Bruno Voisin posted a comment on ticket #194
Please forget about this report. I just realized the problem only happens when viewing XeTeX's PDF output with macOS's Preview (Ventura version), not with Acrobat or Ghostscript. So the bug must be in macOS. I just reported it. Sorry for the noise.
-
PDF file gives incorrect output when included with XeTeX
-
Good to hear it's fixed, thanks.
-
xelatex.exe: error while loading shared libraries: icuuc72.dll: cannot open shared object file: No such file or directory
-
Anonymous posted a comment on ticket #193
And already fixed. This issue can be closed. See https://github.com/MiKTeX/miktex/issues/1232
-
Anonymous posted a comment on ticket #193
Already reported to MikTex: https://github.com/MiKTeX/miktex/issues/1232 Can be deleted.
-
Anonymous created ticket #193
xelatex.exe: error while loading shared libraries: icuuc72.dll: cannot open shared object file: No such file or directory
-
This is not a XeTeX issue, it's the expected result of how the e-TeX right-to-left support works. For a simplified example, try \TeXXeTstate=1 \hsize 13cm \noindent \beginR \hbox{This horizontal box should contain enough text so that its width is the same a} \noindent \beginR \kern 3cm \hbox{This horizontal box should contain} \noindent \beginR \kern 3cm \hbox{This horizontal box should contain enough text so that} \noindent \beginR \kern 3cm \hbox{This horizontal box should contain enough text so...
-
Anonymous created ticket #192
Horizontal positioning of an hbox in a right-to-left bidi document doesn't work as expected
-
Anonymous posted a comment on ticket #151
I experienced a similar problem due to this bug. I need transparent PNGs and Gimp likes to use 16bits per color element. Since xetex assumes the data is 8 bit, it gets horribly mangled and most of the image just goes clear. Luckily, you can force 8 bits per color element if you remember to select that option before export, but thats the work-around
-
Nico Schlömer created ticket #191
xetex/dvipdfm can't produce opaque white background
-
note286 created ticket #190
Redundant space in PDF metadata
-
Anonymous created ticket #189
\IfFileExists returns incorrect result when a file is under a directory and its name contains non-BMP character.
-
Anonymous created ticket #188
Error when using package transparent
-
Doug Ransom created ticket #187
mdframed braking in xelatex
-
hb_font_funcs_set_glyph_func and other harfbuzz deprecations
-
Peter Williams posted a comment on ticket #174
Actually maybe it's fairer to say that the #defines expect the cur_chr to be offset by XETEX_INT, but that doesn't happen in conv_toks in this case.
-
Anonymous posted a comment on ticket #182
Update 2: Antonis Tsolomitis recently uploaded a new version of New Computer Modern, which contains the stacking diacritics, to the CTAN. If you want to reproduce the bug, use those fonts instead of the one contained in mwe.zip.
-
Anonymous posted a comment on ticket #174
I believe that this is because the XeTeX_feature_name #define in the C code has gotten out of sync with the value of XeTeX_feature_name_code in the WEB. Cf https://github.com/tectonic-typesetting/tectonic/issues/714
-
Anonymous created ticket #185
Unwanted line break with \raggedleft, \centering or \raggedright
-
I think this is a problem at the macro level rather than in the xetex engine itself. As far as I can see, each \color{...} command here expands into a \special{color push ...} in the output, so that the output driver pushes a new color onto its stack; but the colors are never popped from the stack, and eventually it reaches its maximum size (looks like 128 entries). If you put each usage of \color{....} <text> inside a group, by surrounding it with { ... } braces, the problem goes away because the...
-
Giorgio Audrito created ticket #184
Wrong color after many definecolor in xelatex
-
Anonymous created ticket #183
libpdfbox-java CVE-2019-0228
-
Anonymous posted a comment on ticket #162
A little suggestion: Source Han Sans uses vmtx table for vertical metric advances, which should be used by default. The code should still be kept for backwards compatibility for fonts that do not include a vmtx table on the prerestique that the glyph placement is correct in those fonts. A little more in-depth: it seems that XeTeX was expecting that the vertical 2 em dash glyph to be start from ascender down to (descender - 1em). However, this might cause the font bounding box metrics (eg. FontBBox,...
-
Anonymous posted a comment on ticket #182
Update: there was a bit of confusion about character U+0315 and its behavior, so ignore the results of test 10, 11 and 12 for New Computer Modern; XeLaTeX is working properly because Times shows the proper behavior of the diacritic in these tests.
-
Anonymous created ticket #182
Improve support for stacked diacritics
-
Clément Pit-Claudel created ticket #181
Enabling beamer notes breaks overlays in XeLaTeX
-
Feeding xelatex with \documentclass{minimal} \begin{document} ( \special{pdf:bcontent} 1 \special{pdf:btrans scale 2} 2 \special{pdf:etrans} 3 \special{pdf:econtent} ) \end{document} on TeX Live 2019/Debian results in the file in the attachment. The output doesn't look right to me, though it is unclear on what "the right position" in https://www.tug.org/TUGboat/tb30-1/tb94cho.pdf should be.
-
The same (presumably erroneous) output with XeTeX, Version 3.14159265-2.6-0.999992 (TeX Live 2020/Debian) (preloaded format=xelatex 2020.10.26) and dvipdfmx Version 20200315. If anyone can test a later version after 2020-07-02, please feel free.
-
Anonymous posted a comment on ticket #159
As shown in xetextest-2019.log PDF output driver (dvipdfmx) failed to process the input for some reasons. Error 139 (driver return code) generating output; file xetextest.pdf may not be valid. It is not possible to verify the problem further since the "corrupted" pdf is not provided and the problem can't be reproduced since your installation is not clear at all.
-
Anonymous posted a comment on ticket #82
The ChangeLog entry 2020-07-02 of dvipdfmx says * pdfdoc.c, spc_pdfm.c: Possible fix for a bug that pdf:btrans inside pdf:bcontent and pdf:econtent does not work correctly.
-
Anonymous posted a comment on ticket #100
Dvipdfmx always subset fonts to be embedded. If "no subsetting" is a requirement for embedding, then dvipdfmx can't embed the font.
-
LuaTeX math primitives
-
William P created ticket #179
Movies embedded with pdfpc don't play
-
Matt Jolly posted a comment on ticket #166
I've observed similar behaviour - I believe that for Noto Sans it picks Light Italic or similar. I've worked around it by specifying the fonts explicitly: \setmainfont[% BoldFont={Noto Sans ExtraBold}, ItalicFont={Noto Sans Italic}, BoldItalicFont={Noto Sans SemiBold Italic} ]{Noto Sans}
-
Mistaken UTF16 decoding in get_next
-
Plain TeX's ~ is just an active-character macro defined as \def~{\nobreak\ }, so my suggestion was simply to make U+00A0 do the same thing.
-
Plain TeX's ~ is just an active-character macro that inserts \nobreak\, so my suggestion was simply to make U+00A0 do the same.
-
Plain TeX's ~ is just an active-character macro that inserts \nobreak\, so my suggestion was simply to make U+00A0 do the same.
-
Anonymous posted a comment on ticket #177
Thanks, that makes sense and works indeed. I’m a bit surprised because that means TeX’s ’~’ doesn’t insert U+00A0 (I guess it just inserts some fixed-width blank space then ? Anyway that’s out of the scope of this ticket.)
-
It depends on the font being used; unless you (or some macro package) defines it in another way, U+00A0 will simply print that character from the current font. Some fonts (rather weirdly, in my opinion) have a different width for U+00A0 than for U+0020. What might be preferable would be to define U+00A0 as a macro, e.g.: \catcode"A0 = \active \def^^a0{\nobreak\ } but of course this may depend on what other packages etc are in use. Alternatively, try another font. For example, if I add \usepackage{fontspec}...
-
Anonymous created ticket #177
Non-breaking space is too wide
-
Anonymous posted a comment on ticket #176
I've opened a PR to xetexref, see https://github.com/wspr/xetexref/pull/14. --- muzimuzhi from GitHub
-
Anonymous posted a comment on ticket #56
This plaintex example shows that the \pdflastypos is still wrong: \ifdefined\directlua \let\pdfsavepos \savepos \let\pdflastxpos \lastxpos \let\pdflastypos \lastypos \fi \pdfsavepos \write-1{saved pos: \the\pdflastxpos, \the\pdflastypos} % both pdftex and luatex give 50644704 for \pdflastypos, % but xetex gives 48462072, which is 2182632 (about 33.3pt) smaller content \bye
-
Anonymous posted a comment on ticket #176
Shouldn't this be reported to https://github.com/wspr/xetexref/issues instead?
-
I confirm that the original example no longer compiles, and that the bug reported on 2016-02-26 is gone. There is a typo there; the proper source code of the example should have been \documentclass{article}\pagestyle{empty} \usepackage{unicode-math} \begin{document} \(|^a\) \(\vphantom{|}^a\) \end{document} The ouput is attached.
-
Anonymous posted a comment on ticket #77
I’ll try to reproduce on my curernt setup, but that probably won't be before this week end or the next. As for making the font available for download, I’ll have to check the licence, but I’m guessing that will be complicated. If I’m able to reproduce, I’ll probably need to find another font that is concerned as well.
1 >
