Closed jspitz closed 7 months ago
The first problem is fixed at a9dbdc53bb0a8
For the other problems, bisect points at 26cb857dd2fd3df8fe
@Udi-Fogiel when I compile the polyglossia manual after your recent changes, I get a bunch of errors:
One is:
! Undefined control sequence. \lgem ...\setbox 0\hbox {l}\xpg@if@char@available {00B7}{\setbox 2\hbox {\ch... l.986 ... geminated l, as in \textit{co\l.laborar}
Sorry, I'll refrain from removing commands in the future.
And then a number of errors similar to this:
! Package polyglossia Error: The current latin monospace font does not contain the "Hebrew" script! (polyglossia) Please define \hebrewfonttt with \newfontfamily co mmand.
This blocks the release of polyglossia 1.66.
Please try again, I think I have fixed it in e547f2b
Yes, seems to be fixed. But we better test still a bit before releasing.
Here is a minimal code that reproduce the problem
\documentclass{article}
\usepackage{polyglossia}
\setmainlanguage{english}
\setotherlanguage{hebrew}
\newfontfamily\hebrewfont[Script=Hebrew]{Linux Libertine O}
\begin{document}
\texthebrew{\texthebrew{שלום}} \texttt{Hello}
\end{document}
I'm not saying that \localnumeral
should use \foreignlanguage
with lang=local
(and it did not before my changes), but there seems to be a problem that is more fundamental.
I believe the cause of many of the font problems is the fact that we assign many parameters globally, when we shouldn't.
Here is a minimal code that reproduce the problem
\documentclass{article} \usepackage{polyglossia} \setmainlanguage{english} \setotherlanguage{hebrew} \newfontfamily\hebrewfont[Script=Hebrew]{Linux Libertine O} \begin{document} \texthebrew{\texthebrew{שלום}} \texttt{Hello} \end{document}
OK, the problem here is that we need a stack to store embedded matrix languages on a nesting level > 1. I fixed this at a0503414af76b using a stack rather than a simple string-storing macro.
OK, the problem here is that we need a stack to store embedded matrix languages on a nesting level > 1. I fixed this at a050341 using a stack rather than a simple string-storing macro.
Yes, it fixed this specific problem, but I don't see why there is a need for stacks in the first place. If the parameters were local, we won't have to track them all the time.
Please go ahead if you know what you are doing.
@Udi-Fogiel when I compile the polyglossia manual after your recent changes, I get a bunch of errors:
One is:
And then a number of errors similar to this:
This blocks the release of polyglossia 1.66.