Yes, this appears to be a bug; thanks for reporting. I think a workaround would be to add \hskip0pt before the \endL command.
Bug: texlive-xetex/jammy,now 2021.20220204-1 all on Ubuntu 22 requires harfbuzz-1.4.2
Closing this at Karl's request.
xelatex.exe: error while loading shared libraries: icuuc72.dll: cannot open shared object file: No such file or directory
Good to hear it's fixed, thanks.
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...
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...
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.
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}...
Thanks for working on this! I'll try to get the patches applied soon.
Hi Karl - yes, I expect switching to use pplib should be fine, and the patch looks straightforward from a quick glance. Just curious about the title of this issue; is that a copy/paste error or something? I don't see what the connection with Bengali dotted circle would be....
"Bad native font flag in `map_char_to_glyph'"
OK, thanks. It doesn't reproduce for me either. I think we can close this.
Not that I'm aware of. However, there have been various bug-fixes since this was filed, so it'd be good to confirm whether the issue still exists in the current version (e.g. TeX Live 2019 release).
Logic typo in the WEB source
This has been fixed for v. 0.999991.
Extend \Ucharcat to produce \active chars
Add \expanded to XeTeX
Round out pdfTeX-derived utilities
Reorder lines
That sounds like something that would best be handled by the xdvipdfmx output driver.
Sorry about the lack of action here -- I keep meaning to check over this and merge, just haven't found the spare brain cycles. I do want to see this done for TL'19, and obviously it would be better done well in advance so that there's opportunity for testing....
This does look a lot like issue #146; perhaps the fix there was not correct/sufficient.
Sorry, I just got home from a work trip overseas, and haven't had a chance to look into this in any detail yet. (I suspect it's probably fine, but would like to make sure I understand what's being added.) Can you point me at documentation of the new primitives (particularly \expanded), to help understand exactly how it's supposed to work? (Apologies if this has been posted somewhere already, and I've missed it...)
Isn't that the expected behavior if you're running it in \nonstopmode? Which may be the default mode if it's being run from some kind of front-end/shell/editor.
I have just corrected this code (I hope!) in commit 2b6736ba29e38f604ddab239c661c18366e8c41b. Any testing would be much appreciated.
Ouch! Indeed, that doesn't look right. We'll need to figure out whether the "obvious" change will actually have the right effect here, or if there are further implications. Have you tested this at all?
hyphenation for longer words
This was implemented in the form of a new integer parameter \XeTeXhyphenatablelength (default value is 63, for backward compatibility; maximum is 4095). This has been available since version 0.99996 (in TeX Live 2016).
non letters in discretionar causing dropped nodes
I believe this should be fixed by commit 6a6805694f5509fe1c08ef2669ec3f514bc1649d, just pushed to the repository. Testing appreciated!
This should be fixed by commit a9146aa0a329e5ebd61759a94f1ff498b36aa4b3.
xelatex will produce invalid utf-8 sequence if it encounters undefined command
I believe this is fixed; closing. Please re-open or file a new bug if there are still problems with this.
\scriptscriptsize mu-value "leaks" out.
XeTeX selects the wrong optical size
This should be fixed in commit 242516c203c28f2f1ef854c2552e12fb15bd3cf8.
\uchyph=0 for native Unicode fonts
Thanks again! Applied patch in ce73a6dc9b367ba75ade8d855efee4542198f3c4.
\primitive\vrule\q incorrectly swallows \q
xetex crash on enough invalid utf-8
Should be fixed in b7ef352d2c0dd164f339eaf3d522cc752bb185c4.
\primitive\vrule\q incorrectly swallows \q
Thanks, applied the patch in a7f38e428b829f9f993c38fe1896b5fb6f59dd14.
Incomplete error messages of \strcmp and \mdfivesum
Thanks for the patch! Applied in 124ca6cf94bb27ab5ccb9017e6347bf12c5a9d04.
Fixed in 49e5f5ec9383e4cb2d54c64436974720c30d3d6d for version 0.99999.
\input| doesn't work correctly on Mac OS X
This was fixed in commit 27d28a6bb056d4865d61e2596d17d4f6befa024d.
\ifcat and \span, \cr, \crcr
Thanks for looking into this! Patch applied.
Thanks for the patch, Akira; looks fine. I applied it to the SF repository, so this should be fixed for the next version.
not stripping trailing tabs (et al.)
Fix applied, thanks.
I'd be surprised if designers were to release fonts only in WOFF form, unless those fonts are specifically licensed only for webfont use, given the explicitly stated purpose of the WOFF format. (FWIW, my inclination here, if/when I find time to work on it, is still to modify XeTeX so as to ignore WOFF files returned by fontconfig.)
Exit status of driver xdvipdfmx should influence exit code of xelatex
Ah, thanks - yes, the history value itself doesn't become the exit code directly, as you note. I think that's OK, it's sufficient that scripts, batchfiles, etc., can detect that an error occurred.
I have just committed a change that should fix this, afaics -- if the driver fails, xetex should exit with a new status of 4 (to distinguish this, fwiw, from the existing TeX-level error statuses). (Note that this is currently untested. Feedback welcome.)
Exit status of driver xdvipdfmx should influence exit code of xelatex
Yes, I'll try to get to this shortly. It should be pretty trivial (I think).
I agree, if the driver returns a failure code we should propagate that.
Thanks for the report and analysis. This has been broken ever since xetex was extended to allow supplementary-plane characters to be treated as "first-class" codepoints with their own \catcode, etc., even though the internal processing continues to work with 16-bit code units (i.e. we use utf-16). I will commit a fix shortly, and bump the version number to 0.99998 as this is a visible (if rarely-encountered!) behavior change. Re your additional point: On a related note, I think define(p,relax,256)...
That would be a question for the texlive list, I think. (I don't know how feasible...
That would be a question for the texlive list, I think: http://tug.org/mailman/listinfo/tex-live....
I think it's likely this will be fixed by 4d9ba8ff700093e247675fafba1a24f53ec1686e,...
Should be fixed by 9785737384bfe6080b8231f666ddf5b3861c957a, I think; please tes...
Should be fixed by 9785737384bfe6080b8231f666ddf5b3861c957a, I think; please tes...
I think it's likely this will be fixed by 4d9ba8ff700093e247675fafba1a24f53ec1686e,...
I imagine the parens were so that the current directory (outside the subshell) will...
The current source is maintained in the TeXLive svn repository. (If you're referring...
That should basically work for xetex, AFAICS. xdvipdfmx will take a bit more work,...
Have you checked whether such "subscription" fonts actually allow extraction of the...
Fix pushed to utf16-issues branch; will merge to master shortly.
This isn't primarily an issue with ^^^^^ notation, but rather a problem with control...