Activity for XeTeX - Unicode-based TeX

Hilmar Preuße posted a comment on ticket #205

Hilmar Preuße — Mon, 20 Apr 2026 22:05:05 -0000

I've applied the patch into the Debian TL package, and can confirm that building using gcc-16 works. The issue may be closed.

karl berry modified ticket #205

karl berry — Mon, 20 Apr 2026 22:02:26 -0000

Fails to compile using gcc-16

karl berry posted a comment on ticket #205

karl berry — Mon, 20 Apr 2026 22:01:14 -0000

ICU 76 requires C++17 per https://unicode-org.github.io/icu/download/76.html#icu4c-platform-support . Thanks to Norbert, I (r78759) installed the attached change (more or less) in web2c/configure.ac, and updated our copy of ax_cxx_compile_stdcxx.m4 in Build/source/m4.

Hilmar Preuße posted a comment on ticket #205

Hilmar Preuße — Mon, 20 Apr 2026 12:38:01 -0000

For now I confirm, that the flag -std=c++17 is a working work around. I'll try to contact the ICU maintainers. Many thanks!

Jonathan Kew posted a comment on ticket #205

Jonathan Kew — Mon, 20 Apr 2026 08:18:52 -0000

From a quick look at the log, it seems that the ICU headers on that system are incompatible with this compiler version (or with the particular compiler options being used): /usr/include/unicode/localpointer.h:559:26: error: parameter declared ‘auto’ 559 | template I think this usage of auto was a C++17 feature, so perhaps -std=c++17 would help? Though it looks like gcc16 is expected to default to C++20, and it'd be a bit surprising if something that was accepted...

karl berry posted a comment on ticket #205

karl berry — Sun, 19 Apr 2026 21:51:29 -0000

Thanks for the report, as always. Can you, or anyone, suggest a patch? My minimal C++ knowledge is not up to dealing with this. Also, I wonder if it might be wise to wait until gcc16 is actually released, since it's such bleeding-edge stuff. or are these problems unlikely to change?

Hilmar Preuße created ticket #205

Hilmar Preuße — Tue, 14 Apr 2026 22:03:52 -0000

Fails to compile using gcc-16

Explorer created ticket #204

Explorer — Sun, 21 Dec 2025 09:14:21 -0000

The font selection not find issues for certain CJK fonts with family name?

Anonymous posted a comment on ticket #89

Anonymous — Tue, 04 Nov 2025 23:02:20 -0000

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

karl berry — Sat, 06 Sep 2025 20:08:48 -0000

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

Jonathan Kew — Sat, 06 Sep 2025 17:36:13 -0000

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.

karl berry posted a comment on ticket #203

karl berry — Sat, 06 Sep 2025 17:15:34 -0000

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.

Jonathan Kew posted a comment on ticket #203

Jonathan Kew — Thu, 04 Sep 2025 22:24:50 -0000

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?

Jonathan Kew posted a comment on ticket #203

Jonathan Kew — Thu, 04 Sep 2025 21:56:01 -0000

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....

karl berry posted a comment on ticket #203

karl berry — Thu, 04 Sep 2025 21:37:46 -0000

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...

karl berry posted a comment on ticket #203

karl berry — Thu, 04 Sep 2025 21:24:54 -0000

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...

Jonathan Kew posted a comment on ticket #203

Jonathan Kew — Wed, 03 Sep 2025 11:56:29 -0000

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.

karl berry posted a comment on ticket #203

karl berry — Tue, 02 Sep 2025 20:50:50 -0000

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

Anonymous — Tue, 02 Sep 2025 09:40:23 -0000

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"...

karl berry created ticket #203

karl berry — Mon, 01 Sep 2025 21:15:20 -0000

strange behavior with large \romannumeral

Anonymous posted a comment on ticket #202

Anonymous — Tue, 18 Jun 2024 10:59:21 -0000

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).

Jonathan Kew posted a comment on ticket #202

Jonathan Kew — Tue, 18 Jun 2024 09:47:09 -0000

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

Anonymous — Tue, 18 Jun 2024 03:07:01 -0000

Incorrect hyphenation inside short directinality switch with system font

karl berry posted a comment on ticket #201

karl berry — Wed, 22 May 2024 21:32:06 -0000

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

Yannis Haralambous — Wed, 22 May 2024 16:58:00 -0000

Implementing ICU ubidi_setClassCallback() to allow directionality change for PUA characters

Jonathan Kew modified ticket #200

Jonathan Kew — Tue, 21 May 2024 21:47:52 -0000

Bug: texlive-xetex/jammy,now 2021.20220204-1 all on Ubuntu 22 requires harfbuzz-1.4.2

Jonathan Kew posted a comment on ticket #200

Jonathan Kew — Tue, 21 May 2024 21:47:52 -0000

Closing this at Karl's request.

karl berry posted a comment on ticket #200

karl berry — Tue, 21 May 2024 21:14:30 -0000

Glad you found a way through, Jean.

Anonymous posted a comment on ticket #200

Anonymous — Tue, 21 May 2024 08:44:16 -0000

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

Jean Ye — Sat, 18 May 2024 02:05:20 -0000

Bug: texlive-xetex/jammy,now 2021.20220204-1 all on Ubuntu 22 requires harfbuzz-1.4.2

Anonymous posted a comment on ticket #185

Anonymous — Mon, 08 Apr 2024 14:09:41 -0000

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...

karl berry posted a comment on ticket #185

karl berry — Mon, 12 Feb 2024 17:03:59 -0000

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 ...

karl berry posted a comment on ticket #185

karl berry — Sat, 10 Feb 2024 18:36:10 -0000

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

Anonymous — Wed, 07 Feb 2024 21:26:09 -0000

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

Anonymous — Sat, 13 Jan 2024 14:44:24 -0000

Incorrect version check on pdftex

Andreas Scherer posted a comment on merge request #5

Andreas Scherer — Sat, 04 Nov 2023 23:17:40 -0000

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

Anonymous — Wed, 30 Aug 2023 08:21:23 -0000

It looks like xdvipdfmx is still overwriting the Producer metadata field. Can we fix it please?

Anonymous posted a comment on ticket #185

Anonymous — Mon, 07 Aug 2023 11:39:59 -0000

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

Anonymous — Mon, 07 Aug 2023 11:39:57 -0000

Thank you!

Dmitriy Alexandrov posted a comment on ticket #195

Dmitriy Alexandrov — Sun, 06 Aug 2023 11:00:31 -0000

Related MR: https://sourceforge.net/p/xetex/code/merge-requests/6/

Anonymous created merge request #6 on Code

Anonymous — Sun, 06 Aug 2023 10:57:54 -0000

Fix zlib build (bug #195)

Glenwing posted a comment on ticket #198

Glenwing — Sun, 11 Jun 2023 22:09:05 -0000

Forgot to mention: This is XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022) (preloaded format=xelatex 2023.1.7)

Glenwing created ticket #198

Glenwing — Sun, 11 Jun 2023 21:45:06 -0000

Opentype Stylistic Set not working on scaled parentheses

Just A. Man posted a comment on ticket #56

Just A. Man — Wed, 15 Mar 2023 18:50:21 -0000

Output with XeTeX, Version 3.141592653-2.6-0.999994 (TeX Live 2022/Debian) still bad.

Just A. Man posted a comment on ticket #87

Just A. Man — Wed, 15 Mar 2023 18:47:25 -0000

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).

Just A. Man modified a comment on ticket #125

Just A. Man — Wed, 15 Mar 2023 18:43:49 -0000

As of now, I get the expected =: https://i.imgur.com/cbRnVpE.png . The bug report can be closed.

Just A. Man modified a comment on ticket #125

Just A. Man — Wed, 15 Mar 2023 18:43:17 -0000

As of now, I get the expected =: https://i.imgur.com/cbRnVpE.png

Just A. Man modified a comment on ticket #125

Just A. Man — Wed, 15 Mar 2023 18:42:28 -0000

As of now, I get the expected =:

Just A. Man posted a comment on ticket #125

Just A. Man — Wed, 15 Mar 2023 18:41:13 -0000

As of now, I get the expected =:

Just A. Man posted a comment on ticket #128

Just A. Man — Wed, 15 Mar 2023 18:39:45 -0000

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 .

Just A. Man posted a comment on ticket #129

Just A. Man — Wed, 15 Mar 2023 18:33:26 -0000

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

Xiao Hanyu — Sun, 05 Mar 2023 02:29:47 -0000

I kind of prefer approach 2 here, by modifying build.sh and force the project to use gcc/g++.

Xiao Hanyu modified a comment on ticket #197

Xiao Hanyu — Sun, 05 Mar 2023 02:29:00 -0000

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...

Xiao Hanyu modified a comment on ticket #197

Xiao Hanyu — Sun, 05 Mar 2023 02:28:32 -0000

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...

Xiao Hanyu modified a comment on ticket #197

Xiao Hanyu — Sun, 05 Mar 2023 02:28:02 -0000

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...

Xiao Hanyu modified a comment on ticket #197

Xiao Hanyu — Sun, 05 Mar 2023 02:27:44 -0000

Xiao Hanyu posted a comment on ticket #197

Xiao Hanyu — Sun, 05 Mar 2023 02:27:05 -0000

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...

Xiao Hanyu created ticket #197

Xiao Hanyu — Sun, 05 Mar 2023 02:25:56 -0000

Project failed to build on environment with clang

Xiao Hanyu created ticket #196

Xiao Hanyu — Sat, 04 Mar 2023 14:02:16 -0000

Current master branch failed to build on ubuntu 20.04

Xiao Hanyu created ticket #195

Xiao Hanyu — Sat, 04 Mar 2023 09:47:04 -0000

XeTeX's zlib failed to build with autoconf 2.70+ version

Bruno Voisin posted a comment on ticket #194

Bruno Voisin — Sat, 21 Jan 2023 20:18:17 -0000

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.

Bruno Voisin created ticket #194

Bruno Voisin — Sat, 14 Jan 2023 16:09:27 -0000

PDF file gives incorrect output when included with XeTeX

Jonathan Kew posted a comment on ticket #193

Jonathan Kew — Mon, 28 Nov 2022 09:05:17 -0000

Good to hear it's fixed, thanks.

Jonathan Kew modified ticket #193

Jonathan Kew — Mon, 28 Nov 2022 09:05:17 -0000

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

Anonymous — Mon, 28 Nov 2022 09:04:18 -0000

And already fixed. This issue can be closed. See https://github.com/MiKTeX/miktex/issues/1232

Anonymous posted a comment on ticket #193

Anonymous — Fri, 25 Nov 2022 20:54:16 -0000

Already reported to MikTex: https://github.com/MiKTeX/miktex/issues/1232 Can be deleted.

Anonymous created ticket #193

Anonymous — Fri, 25 Nov 2022 13:22:26 -0000

xelatex.exe: error while loading shared libraries: icuuc72.dll: cannot open shared object file: No such file or directory

Jonathan Kew posted a comment on ticket #192

Jonathan Kew — Fri, 18 Nov 2022 09:35:40 -0000

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

Anonymous — Fri, 18 Nov 2022 08:52:43 -0000

Horizontal positioning of an hbox in a right-to-left bidi document doesn't work as expected

Anonymous posted a comment on ticket #151

Anonymous — Wed, 05 Oct 2022 08:39:35 -0000

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

Nico Schlömer — Thu, 28 Jul 2022 08:45:34 -0000

xetex/dvipdfm can't produce opaque white background

note286 created ticket #190

note286 — Thu, 21 Jul 2022 04:41:49 -0000

Redundant space in PDF metadata

Anonymous created ticket #189

Anonymous — Sun, 16 Jan 2022 02:26:42 -0000

\IfFileExists returns incorrect result when a file is under a directory and its name contains non-BMP character.

Anonymous created ticket #188

Anonymous — Wed, 24 Nov 2021 15:29:48 -0000

Error when using package transparent

Doug Ransom created ticket #187

Doug Ransom — Tue, 16 Nov 2021 18:29:49 -0000

mdframed braking in xelatex

karl berry created ticket #186

karl berry — Tue, 20 Jul 2021 22:38:54 -0000

hb_font_funcs_set_glyph_func and other harfbuzz deprecations

Peter Williams posted a comment on ticket #174

Peter Williams — Tue, 08 Jun 2021 15:08:13 -0000

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

Anonymous — Tue, 08 Jun 2021 15:03:24 -0000

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

Anonymous — Tue, 08 Jun 2021 15:03:22 -0000

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

Anonymous — Sat, 05 Jun 2021 23:41:23 -0000

Unwanted line break with \raggedleft, \centering or \raggedright

Jonathan Kew posted a comment on ticket #184

Jonathan Kew — Mon, 17 May 2021 09:27:06 -0000

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{....} inside a group, by surrounding it with { ... } braces, the problem goes away because the...

Giorgio Audrito created ticket #184

Giorgio Audrito — Mon, 17 May 2021 08:41:52 -0000

Wrong color after many definecolor in xelatex

Anonymous created ticket #183

Anonymous — Thu, 06 May 2021 17:47:30 -0000

libpdfbox-java CVE-2019-0228

Anonymous posted a comment on ticket #162

Anonymous — Sun, 21 Mar 2021 22:14:26 -0000

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

Anonymous — Sun, 21 Mar 2021 22:14:25 -0000

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

Anonymous — Fri, 19 Mar 2021 19:49:45 -0000

Improve support for stacked diacritics

Clément Pit-Claudel created ticket #181

Clément Pit-Claudel — Wed, 17 Mar 2021 16:12:18 -0000

Enabling beamer notes breaks overlays in XeLaTeX

Just A. Man modified a comment on ticket #82

Just A. Man — Tue, 09 Mar 2021 18:30:32 -0000

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.

Just A. Man posted a comment on ticket #82

Just A. Man — Tue, 09 Mar 2021 16:26:19 -0000

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

Anonymous — Thu, 21 Jan 2021 14:17:18 -0000

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

Anonymous — Thu, 21 Jan 2021 14:17:17 -0000

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

Anonymous — Thu, 21 Jan 2021 14:17:16 -0000

Dvipdfmx always subset fonts to be embedded. If "no subsetting" is a requirement for embedding, then dvipdfmx can't embed the font.

karl berry created ticket #180

karl berry — Sat, 19 Dec 2020 18:31:48 -0000

LuaTeX math primitives

William P created ticket #179

William P — Thu, 10 Dec 2020 13:02:19 -0000

Movies embedded with pdfpc don't play

Matt Jolly posted a comment on ticket #166

Matt Jolly — Thu, 12 Nov 2020 02:45:01 -0000

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}

Peter Williams created ticket #178

Peter Williams — Thu, 29 Oct 2020 13:08:32 -0000

Mistaken UTF16 decoding in get_next

Jonathan Kew modified a comment on ticket #177

Jonathan Kew — Mon, 12 Oct 2020 16:42:27 -0000

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.

Jonathan Kew modified a comment on ticket #177

Jonathan Kew — Mon, 12 Oct 2020 16:40:51 -0000

Plain TeX's ~ is just an active-character macro that inserts \nobreak\, so my suggestion was simply to make U+00A0 do the same.

Jonathan Kew posted a comment on ticket #177

Jonathan Kew — Mon, 12 Oct 2020 16:39:48 -0000

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

Anonymous — Mon, 12 Oct 2020 16:38:11 -0000

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.)