Re: [XeTeX] Translation commands for package dramatist to put in the marathi.ldf file
On Mon, Apr 13, 2020 at 02:39:34PM +0530, RD Holkar wrote: > thank you for the inputs. Now I feel that it is better to have a package > for this purpose. The package is a better idea also as one may > incorporate traditional marathi aspects of drama in it. If you change your mind, I am happy to include the translations in Polyglossia anyway. You do not have to write a pull request, just open an issue on GitHub and write the translated strings. Best, Arthur
[XeTeX] Subject prefix back on the XeTeX mailing list
Hello, After some discussion we decided to put the subject line prefix back; Karl just made the change and also set Mailman’s “munge from” option (https://wiki.list.org/DOC/Mailman%202.1%20List%20Administrators%20Manual#line-163). Best, Arthur
Re: [XeTeX] Fake italics for some characters only
On Wed, Dec 05, 2018 at 04:06:12PM +, John Was wrote:
> But the braces are
> certainly needed in *usage*: \overstrike{b}{p}
The braces are not needed in this example. Just try
\overstrike b p
or even
\overstrike bp
> But if you wanted a simple macro, say one that reversed two
> arguments, you could have e.g.
>
> \def\swap#1#2{#2#1}
>
> with no extra braces aside from those needed to open and close the
> definition. You would still need them in *usage*, of course.
Not necessarily. See for example
\swap12
or
\swap A\TeX
You seem to have developed an intuitive understanding of how TeX
interprets macro definitions and invocations, which can work in many
situations, but that’s not the right explanation.
> But we're rather far from the original question by now!
Quite. But that’s no excuse to spread your misunderstandings on a
public mailing list.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Fake italics for some characters only
On Wed, Dec 05, 2018 at 02:47:26PM +, John Was wrote:
> Ah, another quirk of LaTeX.
Of TeX. As you can see in your own example:
> \def\overstrike#1#2{\setbox0=\hbox{#1}\setbox1=\hbox{#2}\copy0
>\kern -0.5\wd0 \kern -0.5\wd1 \copy1 \kern -0.5\wd1 \kern 0.5\wd0}
the arguments are surrounded by curly braces in the macro definition.
With the definition you wrote:
>>> \def\Textit#1{{\italictrue \textit #1}}
\textit would use only the first token of #1 at the end of the
definition. This has nothing to do with LaTeX macros or syntax.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Velthuis to Roman translit
On Mon, Jul 30, 2018 at 09:25:19AM +0530, Shree Devi Kumar wrote: > https://github.com/Shreeshrii/xetex-itrans/blob/master/wikner-skt-iast.map > has a draft map based on the velthuis-devanagari map, but currently it does > not support the initial Capitals (eg. AA needs to convert to Ā, "S to Ś). Don’t the rules on lines 111, 113, and 115 take care of the former? A <> Asvara I <> Isvara U <> Usvara Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] depcomp erorr when building (and workaround)
Belated response: On Wed, Sep 07, 2016 at 01:20:27PM -0400, Scott Kostyshak wrote: > I run the following commands: > > git clone git://git.code.sf.net/p/xetex/code xetex-code && > cd xetex-code && > ./build.sh > > This gives the following error: > > /bin/bash: > ../../../../source/texk/web2c/web2c/../../../build-aux/depcomp: No such > file or directory > > I suppose this has to do with autoconf versions or something like that. The origin of the problem seems to be libtool, specifically the utility libtoolize; I was able to reproduce the problem with libtool version 2.4.6 (from 2015), while an older machine with libtool 2.4.2 (from 2011) didn’t have the issue. Compilation was also fine on the newer machine with libtool 2.4.2. By trial and error I found that the following simple line near the top of configure.ac did the trick: AC_REQUIRE_AUX_FILE([depcomp]) I can’t really claim to know what I’m doing, but it seems to work. I’ve committed that line to the repository, so that compilation should work with a fresh copy; alternatively, in an old working directly, I’ve found that git clean -dfx did the trick of restoring a clean slate. Then you of course need to run git pull. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] which TeX-based software
> Second, about unicode, my experiences are mixed. I use Japanese as my main > language of communication. I found that "plain XeLaTeX" is not really > adequate for Japanese as it lacks many common features; LuaLaTeX performs > better, but still not as good as the pre-UTF-8 special "Japanese LaTeX" > called "platex". In other words, even if XeLaTeX can typeset all unicode > characters, you still need proper fonts, and special typesetting (such as > indents, hyphenation rules, etc) may not be perfect. In yet other words, the features you miss are about Japanese typesetting, not Unicode. This is an important distinction since the original poster doesn’t need to typeset Japanese. As a an aside, if you’re talking about pTeX you should really mention its UTF-8 extension, upTeX. > If you are looking for something which based on TeX but closer to DTP > software, check out ConTeXt. ConTeXt has been used for many complex, > professional typesetting jobs, and the developers are very active in trying > to find new solutions if needed. IIRC the current version of ConTeXt supports > at least LuaLaTeX which provides support for UTF-8 The version that’s currently actively developed, Mark IV (mkiv) is focused on LuaTeX, while the earlier version, Mark II, is more or less frozen and supports pdfTeX and XeTeX. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Are the new etex changes reflected in XeTeX? (was XeTeX bugs in bidirectional typesetting)
> https://sourceforge.net/p/xetex/bugs/134/ Great, thanks David. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Are the new etex changes reflected in XeTeX? (was XeTeX bugs in bidirectional typesetting)
> If you do find time to look at this... the other main issue besides \specials > where the current model causes problems is the inability to specify direction > while in vertical mode. The restriction to hmode was probably needed in > tex-xet > so the extra nodes got added at safe places but in tex--xet it's less > clearly needed. Do you want to make a bug report for this? It’s good to discuss these issues between us, but when it comes to implementing and distributing changes, it’s best to have a record of them in the bug tracker; XeTeX’s is on Sourceforge as you know: https://sourceforge.net/p/xetex/bugs/. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] handbook of XeTeX
Hi Maïeul, > Is there a project of uping it ? Yes, I plan to update it. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] ucharclasses needs some help for XeTeX 0.99996
Hi Mike, Many thanks to both of you for your hard work; sorry I couldn’t contribute more; this week has been rather busy for me, with various tasks, and a funeral to attend tomorrow. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX - PDF-x1a
Hi Ross, >> Unfortunately it's not really possible at the moment; the package pdfx >> aims at producing different standards of the PDF/A and PDF/X families >> but is aimed at pdfTeX. To my knowledge there has been no serious >> effort to port it to XeTeX. > > There has now! > I have successfully produced a validating PDF/A-2u document from > the Serbian version of the TeX-Live documentation for 2015. This is excellent news! Thank you for your effort. > #1 > What is the name of this primitive please? \mdfivesum, for consistency with other XeTeX primitives where the initial "pdf" has been stripped (not my choice). See http://tug.org/pipermail/xetex/2015-July/026072.html > Luatex and pdftex have the \pdfminorversion primitive to set the required PDF > version. AFAIK there is no way how XeTeX could communicate such a requirement > to xdvipdfmx. The only way is to call xelatex -no-pdf ... and xdvipdfmx -V4 > ... (default is PDF 1.5 but PDX/x-1a:2003 requires PDF 1.4). None has been imagined, indeed. It would be good to put our heads together to think about an interface allowing XeTeX and xdvipdfmx to better communicate with each other, but I'm not really up for it right now. > This "-z 0" is needed because the XMP Metadata packet must *not* > be compressed, but must remain readable as plain text, in UTF-8 encoding. > With "-z 1" or higher, the Metadata is compressed. > > With texlive-sr.pdf the filesize difference is enormous: > ~798 kb with "-z 1" > ~10.4 Mb with "-z 0" That is significant indeed. > I've been unable to find a way to specify that parts of the generated PDF > be uncompressed while other parts can be. We don't have one at the moment. How does pdfTeX deal with that? Thanks for all your work, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX
On Fri, Mar 18, 2016 at 12:07:26PM +, Philip Taylor wrote: > You will, I am sure, be > aware that I had not pursued the topic for some time That's simply not true. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Request for help compiling XeTeX from git
Hi Mojca, > Is there any better command than ./build.sh shortcut that I should be > using? Can I somehow run separate steps for configure, make, test? XeTeX’s build.sh only sets a number of variables and runs configure and make, so if you’re scripting the process, it does indeed make sense to call configure & make directly. > I'm always confused by the complex configure scripts, but this time > I'm scripting it, so I don't mind using a slightly more elaborate > approach. Yes, of course. Sorry the build is failing for you. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX
On Thu, Mar 17, 2016 at 11:58:34PM +, Philip Taylor wrote: > The key point is this : only *TeX (where *TeX is any derivative > of TeX; I do not wish to suggest modifying TeX itself out of respect for > Don's wishes) /knows/ whether (e.g.,) an overfull \hbox has been > generated during a *TeX run; other utilities can try to guess (e.g., by > scanning the log file, or the DVI file, or the PDF, or whatever) but > they cannot /know/. Of course they can /know/: by inspecting the log file. It contains the exact transcript of the TeX run, and thus reflects all of TeX's knowledge about what happened when compiling the file; as far as overfull \hbox'es, etc. are concerned. Do you *understand* what I /mean/? Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Command \providelength already defined
On Thu, Feb 11, 2016 at 06:32:36PM +0100, Ulrike Fischer wrote: > Am Thu, 11 Feb 2016 16:33:22 + schrieb Arthur Reutenauer: > > >> It may be that polyglossia is more careful about re-defining commands. > > > > As I said, polyglossia isn't the package that defines that command, > > neither is dialogue. It could be interesting to investigate in more > > details but I really don't have the time right now. > > The one is moredefs (Mark Swift, 2001) which uses \newcommand and so > clash if the commands are already defined. The other makecmds > (Maintainer: Will Robertson) which uses \def and so overwrites > everything. Thanks, Ulrike. I did see the definition in moredefs that was easy to find. I suppose the best way forward would be to update moredefs and related packages (since it is part of a bundle that also includes dialogue). Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Command \providelength already defined
> It may be that polyglossia is more careful about re-defining commands. As I said, polyglossia isn't the package that defines that command, neither is dialogue. It could be interesting to investigate in more details but I really don't have the time right now. (And last time I did that kind of exercise it turned out that the package author had been dead for ten years and nobody had volunteered to take it over, so you'll have to forgive me for focusing on other things.) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Command \providelength already defined
> Sure, just write > > \let\providelength\relax > > before the second package is loaded. Or just load dialogue before polyglossia. For what it's worth, none of these packages define \providelength themselves, they're defined in packages they include. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
On Mon, Feb 01, 2016 at 07:52:27PM -0700, Dominik Wujastyk wrote: > I'm going to let this one go. And no-one can blame you, Dominik :-) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] not enough \XeTeXcharclass registers
On Sun, Jan 31, 2016 at 05:33:49PM +, Jonathan Kew wrote: > Arthur, if you have a chance to look at this and see if I missed anything > obvious, that would be great - thanks. No obvious issue for all I can say, apart for the comment change I just pushed. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
Hi Dominik, On Fri, Jan 22, 2016 at 12:07:17PM -0700, Dominik Wujastyk wrote: > I've just tried to provide the short examples, but I can't get the problem > to manifest in a small sample yet. The student has a lot of included > files, so it's non-trivial to whittle it down to the minimal case. I may > be able to give more time to it this weekend. > Dominik Don't spend too much time on it if it's too complicated. It's also a hint that the issue can't be too common. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
Hi Dominik,
> I left {CMU Serif Italic} as the document font, and added
> \XeTeXinputnormalization=1 to the preamble
>
> This also produced PDF that printed *correctly* in all cases. This is
> obviously the least fiddly solution.
I'm glad this worked for you, but like Zdeněk I’m a little surprised
that it made any difference. Could you possibly compile a short
examples of both PDF files and send it to this list, together with their
sources? A few characters would suffice (as long as they do exhibit the
problem, of course). I may not have time to analyse the issue right
now, but it will be most useful for future reference.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
> but perhaps an Adobe rendering engine might handle things better. Yes, that's sound advice too. Whenever I've had problems with strange font rendering, printing from Adobe Reader (or Acrobat Reader as it was called earlier) very often helped. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
Answering for Dominik, as that is easy to check by inspecting the PDF file (the original one, obviously): > I assume you have already considered: are the fonts embedded in the PDF? Yes. > Did he enter the characters as precomposed combinations or by using > combining marks? First option more likely, I imagine. Irrelevant, but you're right, it's the first option. > This is a real shot in the dark, but here goes: > Is it possible that, at some point in the process, the precomposed > characters were decomposed and then put back together in a way that affected > the output? Possible in general, but that's not what happened here. The problematic characters are coded in the PDF as single glyphs. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
> I haven't encountered anything quite like this before, and it baffles me. > I've tried outputting the PDF to PS and printing that. Printing the PDF to > another PDF. I've tried using Evince not Okular. Always the same > problem. Everything points to the printer or the printer driver. Or a combination of the printer, the printer driver, and the font. I notice you use CMU for the characters that exhibit the problem; could you, or rather your student, try another font, like for example Latin Modern? I'm not certain Latin Modern fully supports the character set you need, but it's worth giving it a try. This problem is by no means uncommon, and is usually encountered with printers that do interpret PostScript and are in a way too smart for their own good. I have experienced similar issues for fifteen years (not too often, fortunately). Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Discretionary hyphens don't work in paragraphed footnotes
On Thu, Oct 08, 2015 at 01:01:37PM +0100, David Carlisle wrote: > Here is a plain tex example, not quite as minimal as I'd like but out > of time for now. > > This hyphenates with pdftex but not xetex Many thanks David, that's really helpful. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] OT script and language features not working
> I'm sure I am not writing the
> commands right, but without examples to follow I am lost and hope that
> someone can help. Minimal example below.
Language and script are selected the same way as features, with the
keys Language and Script respectively. You thus have several commands
at your disposal, either (untested code)
\fontspec{FaliscanCDS}
\addfontfeatures{Script=Old Italic,Language=Faliscan}
or
\fontspec[Script=Old Italic,Language=Faliscan]{FaliscanCDS}
or -- the best choice in an actual document
\newfontfamily\olditalicfont[Script=Old
Italic,Language=Faliscan]{FaliscanCDS}
and use then \olditalicfont for your text in Faliscan.
These commands of course need the Faliscan language to be defined with
\newfontlanguage.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Adobe Professional Fonts and Diacritics
On Thu, Sep 10, 2015 at 02:02:13PM +0200, hanne...@staff.uni-marburg.de wrote:
> In the first case, writing Sanskrit in transliteration, one would write
> typically within an English, other Euopean,
> or Japanese (or whatever) environment that constitutes the main language.
> One just uses a few additional diacritics
> in latin alphabet and would not switch to another languange, since word
> division has to be added by hand anyway.
> The other case is the full use of Devanagari in a Sanskrit environment.
I see. That's an understandable use case, but it's too specific for a
reasonable user interface. You're expecting "\begin{sanskrit}" (or some
equivalent command) to deactivate some setups you've done for Sanskrit
at the document level: that's not something we can reasonably support.
You know that the default document font will work well with your setups,
and not with the Devanagari font you're using within the sanskrit
environment; that's of course why you want to deactivate it. But
Poylgossia can't know that, and some other users may very well expect
the exact opposite: a user whose document has very little Sanskrit in it
could very well decide to use the sanskrit environment for the Sanskrit
texts, and want to have the font fixes activated within it, and only
there. That does in fact sound like a much more common use case to me.
What you should do is define your own switches to deactivate the
redefinitions, and a new environment such as (untested code):
\newcommand\activatesanskritchars{%
\catcode`\ṝ=\active
% Definitions as suggested by Ulrike
}
\newcommand\deactivatesanskritchars{%
\catcode`\ṝ=\letter
}
\newenvironment{mysanskrit}{%
\deactivatesanskritchars
\sanskrit
}{%
\activatesanskritchars
\endsanskrit
}
and use "\begin{mysanskrit}" instead of "\begin{sanskrit}". As Ulrike
says, this is really a font problem anyway, it should be solved only for
documents that use that font (or by changing the font, of course).
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Adobe Professional Fonts and Diacritics
> Is there an easy way to bind the redefinition to certain lanugage envirnoment?
I can add that to Polyglossia, but I need to think a bit about the
interface, particularly for Sanskrit that can used with many scripts.
The best would probably be for you to start suggesting an interface,
but:
> If we redefine ṭ in the way described, then we cannot use it when we switch
> to Sanskrit
> printed in Devanagari. Most convenient would be an automatism that would
> switch off
> the redefinitions whenever we say \begin{sanskrit]
That can't work, since you're working with Sanskrit in both cases (in
Latin transliteration, or in Devanagari). The script is the
discriminating criterion in this case.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX - PDF-x1a
On Thu, Sep 03, 2015 at 10:44:19AM -0400, Adam Drissel wrote: > I need to be able to use XeTeX while still producing a PDF in x1a format > (PDF/A, PDF-x1a). Do you have any idea how I can do this using XeTeX? Unfortunately it's not really possible at the moment; the package pdfx aims at producing different standards of the PDF/A and PDF/X families but is aimed at pdfTeX. To my knowledge there has been no serious effort to port it to XeTeX. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Alternate Ξ glyphs in GFS Neohellenic
On Tue, Sep 01, 2015 at 02:56:22PM +0200, BPJ wrote: > according to the type specimen[1] there are three different Ξ glyphs in the > OTF version of the font GFS Neohellenic[2] but I can only access two of them > -- of course not the one I want at this time, the one without vertical or > diagonals! Peeking inside the font with FontForge hasn't made me any wiser. > Does anyone know how to access them all? For some strange reason the glyph you want is not accessible through OpenType features, as a look into the GSUB table confirms, but is included as a separate character from the Private Use Area (U+E004); that's why copy-pasting from the PDF file works for this particular glyphs, as Phil showed; but it's obviously a bad idea to do so because you would need to input all Ξ as this PUA character, and then your PDF files won't be searchable. I have no idea why the authors of the font did it like that, but I consider this a bug -- as it stands now, the font only has two different glyphs for Ξ, as Apostolos observed, and a pseudo-character that's graphically a Ξ, but not in the right place. I dare not think that the creators of the font *wanted* you to use the zigzagging glyph, or maybe the one with the vertical bar, instead of the more standard one with just three horizontal bars, but it's certainly tempting! Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Incorrect rendering of Vedic Sanskrit accents
> First, this is only describing how Uniscribe handles this situation; > its not clear that makes this behaviour a normative part of the Indic > script specification. Well, unfortunately, Uniscribe was for years the reference implementation, and there was no formal Indic script specification, so this description was in a way normative, if by default. But, as you point out, it's quite dated now anyway. And clearly not relevant to your main issue. I really hope that someone can pick it up and analyse the actual issue with Vedic Sanskrit accents. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Incorrect rendering of Vedic Sanskrit accents
> Also, the original version of xetex was developed by SIL (SIL > also has some useful fonts), and SIL works with such minority languages > exclusively. So while it may be possible for the *tex engine or fonts to > omit the dotted circle, it doesn't seem to be a very high priority. Please don't make assumptions on what is and isn't a priority based on who sponsored development years ago. There is no plan or agenda on font and script support, much less on this particular issue, that should be considered only on its merits. And there are for sure bugs to be fixed in many areas, needless to say, in XeTeX and fonts and other programs and utilities. But that shouldn't encourage idle speculations. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Incorrect rendering of Vedic Sanskrit accents
On Fri, May 22, 2015 at 04:49:58PM -0400, Stephen Moye wrote: > Atta boy! You tell 'em! Take THAT! Was that really meant for the list? Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Bug fixes and new features related to Unicode character codes, surrogates, etc
While working on these bugs, we also discussed how surrogate characters were handled in XeTeX. Surrogate characters are the 2048 code points that are used in UTF-16 to encode characters with code points above 65536: a pair of them makes up one Unicode character; however they're not meant to be used in isolation, even though they have code points like other characters (they're not just byte sequences). Right now, XeTeX allows isolated surrogate characters, and also combines sequences such as d835dc00 into one Unicode character. We want to flag the former case but are not sure how: should we make the characters invalid (with catcode 15)? Or we could map them to the standard "unknown" character (U+FFFD). The latter case is more nasty and should definitely be forbidden -- the ^^ notation should only be used for "proper" characters (so instead of the above, the Unicode code point of the resulting Unicode character should be used, in this case ^1d400). Any thoughts? Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Media9 buttons in RTL text
> I do realize the usual MWE requirement, and I did not provide one at first
> because really what I was trying to find out was not related to a specific
> example, but more the matter of whether Luabidi was likely to be upgraded
> so as to be as fully functional as XeTeX bidi, as Vafa had suggested last
> fall.
I don't know about that and leave it for Vafa to answer.
> And I was hard pressed to express it clearly, as it was so
> confusing to me as it was!!
That's understandable :-)
> RE: the misguided switching to Lua: I was not happy with that myself;
> indeed I did so only because it was the only solution proposed to me last
> October, and I was well aware that such a quirky solution was likely to
> cause problems. Indeed it was only a few weeks that I was able to follow
> this procedureŠ so my suspicion was vindicated.
So I realised. But just in case, I think I'll change Polyglossia to
use luabidi instead of bidi if it's loaded with LuaTeX. I had started
doing that in May 2013 but found out the output was very poor with
right-to-left as well as Indic-script languages, so I rolled back and
inserted the warning you saw ("[Hebrew] is not supported with LuaTeX,
etc."). I will leave that warning, but will now load luabidi. With all
its shortcomings, that may still prove useful for some users and will
mean they'll have one less hoop to jump through if they really want to
use LuaTeX for, say, Hebrew or Hindi.
> I have found, as you say, that an MWE is often very difficult to produce,
> in that I tend to use many packages in fairly complicated ways, and
> "minimal" in such cases can well be rather large and then I don't expect
> the people on the other end to have the means to work with it. Such is
> life :(
Fair enough, but my point was that you shouldn't try to make it
smaller than necessary. I fully appreciate that the resulting example
may still be large, possibly too much so to let people navigate through
it easily, but if it stops exhibiting the concrete problem it's not
useful at all.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Media9 buttons in RTL text
Dear Karljürgen, I am glad that you were able to find a solution to your problem with the help of David. I did note your plea for help (already back in October), and of course your private email to me two days ago, but while I spent many hours trying to figure out what you were trying to do and how to achieve it, I had no idea how to move forward from the particular situation you were in 48 hours ago, especially considering your in my opinion arbitrary and misguided decision to switch to LuaTeX. If you'll allow me a piece of advice, I would encourage you to in the future always start by producing a concrete document that exhibits the problem, explaining why you expect it to produce a different result (a so-called minimal working example). As you've seen today, doing so has prompted someone to reply to you almost instantly with a working solution. It is very hard for anyone to give actual help without it. I know very well it can be hard for yourself to produce such a document, but by the same token you're the only one who can do it - the example you've sent to this list in reply to Ulrike a few days ago being typical of a fake minimal example, that does not address a real problem. And in working on making an actual minimal example, you'll probably understand the underlying technical issues yourself a little better. I want to improve how Hebrew, amongst other, is handled in Polyglossia. I don't think I can include David's solution to your problem in any meaningful way, but I'll have a think about it (maybe mentioning it in the documentation would be possible). I'll keep in touch with you about that. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] printing of characters above "FFFF with \string \meaning (and potentially \Uchar)
> Obviously the non-BMP issue needs to be tackled, but I wonder if \Uchar > could be added in any case. It would bring functionality in this area > closer to LuaTeX and presumably the high chars business can be viewed as > a separate issue. I tend to agree. There must be an issue with misinterpreted UTF-16 for characters outside of the BMP, but whatever it is, having \Uchar work for characters of the BMP will be a net improvement for most users. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] additional beginL endL nodes in math
> Fair enough. My thought was simply that if a sufficiently large number > of users are dependent (even tacitly) on the current behaviour, then > opting-in to the new should not be out of the question ... That's the eternal question, isn't it - to which extend should a buggy behaviour be preserved for backward compatibility? In this case I'm rather glad that Khaled didn't hesitate to break said compatibility. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] additional beginL endL nodes in math
> In that case (and this is partially off-topic), what is the correct > mechanism by which one should instruct XeTeX (current version : TL-2014) > to reverse that stretch of text ? \beginR, \endR, it's in the subject of this thread. >I have a 544pp book that goes to > print on Friday, and it contains Hebrew fragments which this thread has > caused me to re-examine; it would indeed seem that they are being set > incorrectly, LTR instead of RTL ... No comment. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] additional beginL endL nodes in math
> I do not understand. If system A performed function Y until now, yet > its designer/maintainer wishes it to perform function Y' henceforth Khaled's point is that XeTeX did not work correctly on the issue at hand until he made the change we're discussing. It's unfair to characterise his change as a change in behaviour of the TeX engine, it was a bugfix. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Quotes and dashes
Hi Sasi, > Although I had written about this problem earlier and got some responses Did you read them? >am > giving a minimal working example below. It gives a pdf that has rectangles > where I have placed quotes and dashes: These rectangles are usually a sign that the font you're using doesn't contain the characters in question. Try using another font, that should solve the problem. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] rendering of U+0903
> The problem is that AFAIK the Indic scripts are not yet implemented in > luatex. Actually it is, at least for Devanagari. This is fairly recent (2-3 years). > The dotted ring is not a part of the glyph. the Unicode shaper > (HarfBuzz in XeTeX) knows that visarga is a dependent vowel (matra) and > since a consonant is missing, it takes the dotted ring from the font (it > should exist as a glyph per Microsoft's recommendation). That's interesting, thanks for the explanation. But Manfred doesn't want LuaTeX to produce the same output as XeTeX, he wants it the other way round. What you're saying implies that it's not really possible with a conformant font. > I have quite a lot of texts in Hindi, if you develop such a shaper in lua, > I can offer testing. You should get in touch with Hans and others on the ConTeXt list. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] rendering of U+0903
Have you tried using a non-breaking space (U+00A0) as the base letter? Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyphenation around „ß“
> And why does Jonathan's example > use the reformed orthopgraphy patterns when we are trying > to hyphenate words with eszet ? It works with the 1901 patterns too. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyphenation around „ß“
> Well, "LUATEX uses a finite state hash to match the patterns against the > word to be hyphenated.", so it would seem to me that LuaTeX's behaviour > cannot be considered as normative. If indeed LuaTeX finds hyphenation points that XeTeX misses, using the same patterns, it is an improvement. But I would be a little surprised; is it absolutely certain that both engines really do find the same patterns? Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Letterly fonts
> For example the above links has Hangul in the body which surprisingly > isn't rendered by DejaVu font which should have a very wide range of > Unicode glyphs. The DejaVu fonts don't seem to cover Hangul, nor any other East Asian script, for that matter. See http://dejavu-fonts.org/ that mentions at the bottom that the only scripts supported by all font styles are Latin, Greek, Cyrillic, Armenian, and Georgian. A half dozen other scripts is supported by some families, but Hangul is not among them. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex error: The font "Code2000" cannot be found.
> What do you mean by "same English fonts as latex"? TeX Live comes with > more than 27 thousand fonts and all of them work with latex. He means Computer Modern. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] texlive13/harfbuzz problem with nastaleeq font
> Amazing! When a feature was ignored, it had the desirable effect, and > caused frustration when properly taken into account. It's not that uncommon, actually. But still amazing when you realise it happened. Now I'd like to know how Akira figured out you needed to set "-ccmp" too :-) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Ligatures
> Type1 smallcaps fonts used to do that, not sure why, but probably > because some applications were doing ligature replacement incrementally > and I think it propagated to some (early?) Adobe OpenType fonts. Also, > some fonts seem to use such smallcap ligatures to fix bad interaction > between ‘liga’ and ‘smcp’, but that is the wrong way to fix it. Interesting. In any case, that should be considered a bug in the font as you said. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Ligatures
> Thank you. This is just what I needed. Incidentally, the tag +liga > yielding ligatures for fi, ff, fl, ffi and ffl is the default. > It shoul be disabled for small caps: I'm pretty sure this is taken care of by the font. Have you observed a small caps "fi" ligature? I don't even see why a font designer would draw such a glyph. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Ligatures
> The fontspec manual describes it. The keywords are rlig, hlig, clig, etc. For more details on OpenType tags, you might want to check the specification, and match the list of tags defined in the font at hand with it: http://www.microsoft.com/typography/otspec/featuretags.htm Also, the question at the beginning of this thread has been answered over two weeks ago, on the day it was originally asked. Apparently, the relevant feature tag for Linux Libertine is 'hlig' (Historical Ligatures). Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Latin Modern, from TFM to Unicode
Hi Doug, In addition to the answers that have already been made, I wish to stress one point: > Since there's no mapping from > Unicode, then the outside process either needs to know the absolute glyph > IDs inside the font, or it needs to cause the font to go into some > internal construction mode, like building a ligature, where the font > itself knows the sequence and position of the glyphs to use to construct > the tall symbol. The latter seems impossible, because the font can't > know the threshold height at which to stop construction. Actually it can, and should. A correctly implemented OpenType shaping engine would then use that information to build the final glyph. Unicode and other text encodings are irrelevant here, since all that construction is purely internal to OpenType, including the glyph IDs. > The former > means hard coding internal glyph IDs somewhere outside the font, which > I'm hoping is not fragile, but worrying might be. It is fragile. Don't do it. As Khaled already said, it really sounds like what you need is simply to convert lmex10, and the other fonts you're using, to TrueType format. You'll then have a straightforward way to access the glyphs you need, since they'll have the same position as in the Metafont versions. Latin Modern Math, on the other hand, provides something different: it aims at enabling full OpenType layout, not just to be a clone of TeX's traditional maths fonts in a different format. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi & xwatermark are broken
Thanks. The difference seems to be in the bidi version. I have been using version 13.5 dated 2013/05/28, from TeX Live 2013 pretest, while you (Wilfred) are using version 12.2 dated 2013/04/04 -- presumably from the frozen TeX Live 2012. I can actually reproduce the behaviour you're observing with bidi version 12.3 dated 2013/04/08. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi & xwatermark are broken
> Well, it works OK on my computer, but note that the "DRAFT" shows up in a > rather strange place... Well, that's progress ;-) What version of all these packages are you using? Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi & xwatermark are broken
Yes, I meant in your example. Since the problem is in the interaction between xwatermark and bidi, I'm not surprised that the pages that fail are the ones with watermarks on them. I have no solution for that, and don't really have the time to look into it, sorry. If what you want is to add watermarks to a document that needs bidi, I would suggest to do that in two passes: first produce the document without any watermark, and add the watermark to the PDF afterwards. It would of course be much nicer to do it in one go, but there seem to be insuperable issues with that. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi & xwatermark are broken
> Hi Arthur, I have already tested that but what happen is the output > document is empty. Oh right, I see that now. You mean only the first page, the one that contains the watermark? I hadn't notice before. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi & xwatermark are broken
Hello,
I can confirm that with TeX Live 2013 pretest. The problem is that
xwatermark needs hyperref but postpones it inclusion until the end of
the preamble, and that bidi wants to be loaded last, as you can see from
the error message. Hence both packages fight to be included last.
I can work around the problem by explicitly loading hyperref just
before xwatermark:
\usepackage{hyperref}
\usepackage{xwatermark,loops}
...
\usepackage[RTLdocument]{bidi}
Hope this helps.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Latin Modern, from TFM to Unicode
> Well, you could try to run tftopl, a convertor from TFM to an easier readable > (TeX) Property List file. You could also look into the AFM (Adobe Font > Metrics) file (or the AFT file, whatever it is). Then you'll see the clear > names of the font's glyphs and their encoding. Except that's irrelevant, as you seem to be saying yourself at the end of your email: TeX's font encodings are simply different things from character encodings such as Unicode and other standards such as ISO 8859, ISCII, Windows' code pages, Shift-JIS, etc. And I'm not even sure what you're aiming at in your last paragraph. Indeed, > There is no connection from the manifold of font encodings TeX uses to > Unicode. If you'll find some, it might just be ... that you're calling an apple an orange. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Latin Modern, from TFM to Unicode
>A separate > question: I wasn't aware that an OpenType font even knew anything about > official Unicode code point names, so how does FontBook know which glyphs > have Unicode names and which ones don't?? There is nothing in OpenType about Unicode names. FontBook -- I'm guessing -- simply shows you the names for those glyphs that have a Unicode code point. There is a bijection between code points and names. > With regards to the OpenType font "latinmodern-math.otf" that I've > installed, I desire to know, for all 128 glyph metrics represented by > "lmex10.tfm", what the official Unicode character code points are for the > glyphs that have those metrics in that TFM file. Some glyphs don't have a Unicode code point. Unicode encodes characters, not glyphs, and in some cases the glyphs you see in a font do not correspond to any character. This is in particular the case for those glyphs that you see in Latin Modern Math. These glyphs or part or glyphs can probably be mapped one-to-one to font slots in the original lmex10, but that does not make them characters. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Broken XeTeX
File associations is unlikely to be your problem here: as the message says, xdvipdfmx can't be found. It may be a path problem, or worse; is the xdvipdfmx program at least still present on your system? It should be in the same directory as XeTeX. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Strange error
> It is strange because I am unable to find a package named etoolbox in ctan. Wilfred has already given the link to the package on CTAN, and as he said it is part of TeX Live; in the collection latexextra, to be precise. What's strange is how you managed to install polyglossia without installing etoolbox, as the former lists the latter as an explicit dependency. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeLaTeX, xeCJK, Japanese: some general questions
> Probably a combination of fontspec and xeCJK. I haven't used xeCJK > extensively since I haven't typeset many documents requiring CJK, but the > package is still being developed, unlike zhspacing, which doesn't look like > it's been updated since 2008. xeCJK also explicitly targets all CJK languages, not only Chinese, as mentioned in section 2 of the documentation. > CCT - CCT style (there's no explanation of it in the documentation) CCT was apparently an early extension of TeX for Chinese (see http://www.math.zju.edu.cn/ligangliu/latexforum/tex_cct.htm). I don't know what its punctuation style was concretely, but that xeCJK option is probably aimed at former CCT users who would like to reproduce the same document appearance. CCT seems to still be supported, by the way: there are several ZIP files available for download from ftp://ftp.cc.ac.cn/pub/cct/ and the latest dates from last April. > There was an experimental polyglossia file sent to the list a while ago, if > you search for platex, you should be able to find it. Considering that Wilfred was the one who mentioned them, he should remember it ;-) (http://tug.org/pipermail/xetex/2010-March/016086.html). Links to the different files were posted a little later in the thread by François Charette, the original author and then maintainer of Polyglossia (http://tug.org/pipermail/xetex/2010-March/016103.html). There are apparently two different files for Japanese support, gloss-japanese.ldf and gloss-nihongo.ldf, and another package, genzi.sty. As the current maintainer, however, I can only repeat what François said then: we need someone to produce and actively maintain support files for CJK in Polyglossia. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Turkish dotted I (U+0130) in headers
>> However, \uccode`\i=`\İ gives the intended result but doesn't create >> problems only because I'm working in a monolingual document, such type of >> capitalization should be restricted to Turkish. > > Yes, it should be done in polyglossia. I am sending Cc to Arthur Reutenauer. Thanks, Zdenku. I read the list, you don't need to cc me. I will add that to gloss-turkish.ldf; strange it hadn't been done from the beginning, though! Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] cannot produce labels with non-Latin text when using asymptote with polyglossia, and xelatex
> Can't thank you enough, Arthur. You're welcome :-) I was actually wondering if there was a reason. If you really want maths mode, use any of Khaled's solutions. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] cannot produce labels with non-Latin text when using asymptote with polyglossia, and xelatex
> //label("$\texturdu{ابجد}$",A,S); // program fails when this line is
> uncommented
Why on Earth do you want to type the label text in math mode? Just
remove the dollar signs and you'll be fine.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] longtable and RTL (Arabic)
> I am really sorry, I forgot to attach the files! Here they are:
And I'm sorry too, because I didn't notice your second message ;-)
Next time, if you could reply to yourself, that would make it easier to
follow the thread.
Anyway, your problem is addressed at section 3.1 of the documentation:
For typesetting RTL tables with longtable package, an
experimental package, bidi-longtable package, is provided.
bidi-longtable package should be loaded after longtable package.
I suppose longtable posed special challenges that needed to be
addressed by a separate package. And since bidi seems to protest when
you load longtable after itself, the order you should load the packages
seems to be:
\usepackage{longtable}
\usepackage{bidi}
\usepackage{bidi-longtable}
> P.S.: Strange enough, the English words "Titel" and "Page" are set correctly
> LTR without defining a Latin language in the preamble.
No, I'm guessing that's an artefact of how XeTeX works: back in the
times when it was using ICU, it would ship entire words to be shaped,
and then inserted back into the flow; and the shaping engine knows the
directionality of the different characters. Presumably that same
behaviour has been retained with HarfBuzz; however I'll let Khaled
comment on that, as I haven't looked at the code.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] longtable and RTL (Arabic)
> I would like to ask you for help with longtable and right to left writing > direction, please. As the attached example with polyglossia, longtable You haven't attached anything, it seems; at least I can't see an attachment. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [s...@icu-project.org: [HarfBuzz] Fwd: Patch: Multiple security vulnerabilities in ICU Layout Engine]
Good thing that you anticipated it ;-) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Bug or design flaw in Polyglossia 2012/04/29 v1.2.1
On Sat, Mar 30, 2013 at 10:02:14PM +0100, Peter Dyballa wrote: > Well, any font with Latin support would be sufficient – and using \latinfont > shows the same missing output data, because of missing rules… Yes, but how would Polyglossia decide which font to use? Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Bug or design flaw in Polyglossia 2012/04/29 v1.2.1
On Sat, Mar 30, 2013 at 10:18:49PM +0100, Peter Dyballa wrote:
> Exactly. But when Malayalam uses as punctuation or in calendar dates Latin
> script characters, why is Polyglossia using a Malayalam font to display these
> entities?
Because you told it to. You set up Malayalam to be the main language
of the document with \setmainlanguage{malayalam} and you never changed
the language in the document body, hence Polyglossia uses the font for
Malayalam.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Bug or design flaw in Polyglossia 2012/04/29 v1.2.1
On Sat, Mar 30, 2013 at 08:49:57PM +0100, Peter Dyballa wrote: > When the missing characters are obviously Latin, why aren't they > taken from a Latin script, from \englishfont for example? Because nobody has ever implemented this, nor even come up with a specification for how Polyglossia should behave. In this case you've set up two languages, Malayalam and English. What if you're having a third language, say, German: where should TeX choose the Latin characters from, English or German? I'm really surprised that you expect Polyglossia to switch fonts automatically, because it has never been the case, and if we wanted to implement that now -- which can certainly be very useful in some cases -- I would be wary of breaking many existing documents. Because of the way things work now, users may precisely expect the font not to change automatically. On a minor point, Polyglossia's language switching mechanisms -- as they are devised now -- don't rely on font settings by language, but rather by script: hence \englishfont in your example above is completely useless, and \latinfont would make more sense (which partly addresses my comment in the first paragraph, actually; but again, someone has to write support for that ...) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Unicode 01F01B
On Tue, Dec 18, 2012 at 05:19:40PM +, Arthur Reutenauer wrote: >I can even remember someone stating on this list, a few years > ago, that he wrote a script to hardcode font file paths in the XDV files > XeTeX produces The post dates back to September 2007, in case anyone cares. http://tug.org/pipermail/xetex/2007-September/007403.html It was of course part of a discussion about a font path mismatch, and there have been many such discussions since. (It also contains an interesting and rare example of "foobar" being used to mean "f*cked up beyond all recognition"). Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Unicode 01F01B
What's more, there have been numerous reports that mismatches between the font file XeTeX finds, and the one the PDF driver finds, caused problems. I can even remember someone stating on this list, a few years ago, that he wrote a script to hardcode font file paths in the XDV files XeTeX produces (it was part of a larger, automated workflow, the details of which I can't remember). So while Khaled's change does make it impractical to use two different machines for the XeTeX run and the PDF driver run, it's a fair bet that it fixes more problems than it introduces. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Unicode 01F01B
I can not reproduce the problem either, but evidently your problem is with the program that produces PDF from XDV (either xdvipdfmx or xdv2pdf), not with XeTeX itself. That's what the last two lines you're quoting mean. It would really help if you could tell us what version of these programs you're using. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] sanskrit hyphenation question
On Wed, Dec 12, 2012 at 04:42:39PM +0100, François Patte wrote: > While looking on this page http://tug.org/tex-hyphen/, I have seen that > left-right-hyphenmin for sanskrit are set to (1,5). Why 5? That value for \righthyphenmin has been provided early on in the development of the hyphenation patterns for Sanskrit, I think it was partially the result of an oversight; it's been changed in Polyglossia, as you've seen, the website only needs updating. >In fact, if > we read the gloss-sanskrit.ldf file, it seems that it is (1,3). > > Why 3? I think that results are better with 2. You should provide some kind of justification when you make statements like this. This value was agree upon three or four years ago in the course of a discussion involving, among others, Yves Codet, who is the original author of the hyphenation patterns; he reads this list, so can explain. I suspect that with \righthyphenmin=2, the patterns would produce illegal breakpoints. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with compling an xelatex file
On Mon, Dec 03, 2012 at 07:34:52AM -0600, Herbert Schulz wrote: > You need to use the fontenc package. Also, if you are going to use otf fonts > there is no need for the fontenc package. Herbert of course meant to write "fontspec" in his first sentence ;-) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX Digest, Vol 105, Issue 3
On Mon, Dec 03, 2012 at 05:02:39PM +0530, Sasi Kumar wrote: > ! Undefined control sequence. > l.26 \ocp > \malA=mal-uni01 That looks like something inherited from Omega. Please include the full log file, or at least several lines in the part immediately preceding that error message. The line number reported by TeX refers to the file that was being read at that point of the compilation, not necessarily your own source file. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with compling an xelatex file
On Mon, Dec 03, 2012 at 09:42:34AM +, Arthur Reutenauer wrote:
> No, that's not what the error message says, it says that \setmainfont
> doesn't exist at all. That's because Polyglossia has not been loaded.
And I of course meant fontspec. Oops ;-)
The three lines should thus read:
\usepackage{fontspec}
\setmainfont[Script=Malayalam]{Rachana}
\usepackage{wrapfig}
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with compling an xelatex file
On Mon, Dec 03, 2012 at 09:50:12AM +0100, Lorenz Haas wrote:
> as the error message says: something is wrong with the setmainfont
> statement.
No, that's not what the error message says, it says that \setmainfont
doesn't exist at all. That's because Polyglossia has not been loaded.
It is fixed thus:
\usepackage{polyglossia}
\setmainfont[Script=Malayalam]{Rachana}
\usepackage{wrapfig}
As Lorenz pointed out, there was another problem too, which is also
fixed with the three lines above.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] babel
On Wed, Sep 12, 2012 at 03:34:19PM -0400, Joel C. Salomon wrote: > About a month ago Arthur Reutenauer posted to this list (and some > others) that experimental support for LuaTeX had been added in the > development version he maintains at > <http://github.com/reutenauer/polyglossia>. The support then was too shaky to make a beta release and I expected it would take me a couple of weeks to complete it, but I've been held up by other things in the mean time. I'll make a release to CTAN when it's ready to be tested. (Note that I corrected a typo in the URL of my original announcement, reproduced by Joel.) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Announcing: LuaTeX support in Polyglossia
Thanks Mojca. I've made a lot of changes over the past two weeks, but am not quite ready for a beta release yet. But it's of course great that people are willing to test it. The (temporary) installation instructions are as follows: Copy the files under polyglossia/tex to a location where LuaTeX can find them as TeX files; and the one file in polyglossia/lua to a location where LuaTeX can find it as a Lua file. For all files, you can use the directory where you're compiling, or tex/latex/polyglossia under a local texmf tree. As far as TeX files are concerned, you may want to only copy polyglossia.tex and the file(s) for the language(s) you're testing, instead of installing the 70+ languages. Best, Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] Announcing: LuaTeX support in Polyglossia
Royal Albert Hall, London, 6 August 2012 I have the pleasure to announce version 1.30MM of Polyglossia, that comes with experimental support for LuaTeX. Unfortunately I can't make an upload to CTAN at the moment because the two CTAN'ers are on holidays (can't blame them), but brave users can download the latest version of Polyglossia from my GitHub repository: http://gitub.com/reutenauer/polyglossia It should be enough to just install polyglossia.sty and the gloss files in a local texmf tree, and I encourage users to experiment with it, and to report back to me or to one of the lists I'm emailing this message to; but please restrict your replies to one list only. I suggest lua...@tug.org as the most relevant place to conduct discussions. In fact, I would be glad if users could send me test documents for the languages they're using, as Polyglossia is rather lacking. The XeTeX list is also relevant, since adding LuaTeX support means I'm making heavy changes to polyglossia.sty; they shouldn't, however, affect the XeTeX side of things. But you never know. So again, please report any problem. As this is very much a work in progress, many languages still don't work at all with LuaTeX. I'm working on them, but at the moment any compilation will fail, so I wouldn't advise trying them. This includes -- but I'm afraid won't be limited to -- Arabic, Asturian, Catalan, French, Hebrew, Indonesian, Malaysian, Persian, Serbian, Turkish, Urdu, Vietnamese. And Indian languages won't work at all, as has been discussed on the XeTeX list. Unfortunately, there is no fix for that in the foreseeable future. There are different reasons why the aforementioned don't work at the moment, and I'm aware of them. Actually, setting the British variant of English won't work either (which is ironic, considering the location I send this announcement from, I know). Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
> I remember specifically testing some Nastaliq fonts and Hans fixing some > small issues I found, I just tested again now and IranNastaliq seems to > work OK cool, good to know. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
My wondering was more whether what ConTeXt implements was actually enough for Urdu (and other languages). As far as I know Oriental TeX is only concerned with Arabic texts. But it's entirely possible that Urdu would just work out of the box with ConTeXt / luaotfload's shaping engine. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
> Whenever anything is available for testing, I can try some Czech and > Slovak texts. Thanks. I will let you know when it's ready to be tested. >> Arabic should work fine, but I'm not even sure about Syriac, for >> example. > > How about Urdu? It will be difficult for me but I can try to run some tests. I don't think it would work, actually. I should have written "Arabic Naskh" instead of plain Arabic. Clearly Nastaliq won't work out of the box, as it is not handled by ConTeXt to the best of my knowledge, hence not by luaotfload either. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
Ha, I was wondering how long it would take for someone to notice :-) I just started porting Polyglossia to LuaTeX. I didn't have time to do much yet, but I expect it's going to be a matter of days till all the gloss files work. For the moment, all the languages relying on XeTeX's inter-character token mechanism will fail, but I know how to implement it in LuaTeX. It has been discussed several times already and I don't expect there will be major problems; although of course it will be experimental at first. What's important to understand, though, is that this does not address the underlying issues: LuaTeX still lacks a full OpenType shaping engine, so that won't do anything for Indic scripts, scripts from South-East Asia, Old Korean, nor other "complex" writing systems. Arabic should work fine, but I'm not even sure about Syriac, for example. As for the discussion at hand, I have no intention to participate in it -- although I'm afraid I'm going to be dragged into it. This kind of talk is one of the most demotivating phenomena in open source development, or in any volunteer community, for that matter. Having to go over hundreds and hundreds of emails in a couple of days, few of which seem to focus on concrete issues (when they're not unmitigated drivel), just drains any person's enthusiasm and energy -- not to mention time. As Simon Spiegel asked what the reason was for the seemingly little progress in the XeTeX world in the past couple of years, I can answer for my part: this is it. This kind of endless threads on mailing-lists is the main organic reason why I don't invest more time in development, as far as I'm concerned. And I'm sure this is the case for other core developers too. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
> It says everywhere that luatex supports UTF-8, yet my (very > limited) understanding is that Unicode string support in *lua* > is entirely dependent on third party additions. LuaTeX includes such a third-party addition for UTF-8 string processing, called Selene (http://files.luaforge.net/releases/sln/slnunicode). You just have to use this, instead of Lua's native string library, if you want to process any UTF-8 string in Lua. Its inclusion in LuaTeX even uncovered bugs, which to my knowledge are now fixed. > How does this > affect what one can do with lua in luatex? It does not, really. And this is not relevant to a discussion about XeTeX. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Babel
Javier, that's great news! I suppose you're part of the team developing it? Glad to see the ball gets rolling again for Babel. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Current Hebrew month spelled incorrectly in Polyglossia
Hello,
On Sat, Nov 26, 2011 at 03:41:31PM +, Gareth Hughes wrote:
> It would be good to have the option to choose מרחשון, as that's what I
> would normally write. Could we have a 'marcheshvan' option for
> choosing this more traditional spelling?
In a long overdue action item, I corrected the misspelling that was
mentioned at the beginning of this thread, and added a ‘marcheshvan’
option to both the Hebrew language option of Polyglossia, and the
hebrewcal package. The current syntax is a little suboptimal, i.e. if
you use hebrewcal standalone you can say
\usepackage[marcheshvan]{hebrewcal}
to use the more traditional spelling (both in Hebrew and English), but
with Polyglossia itself you have to say:
\setmainlanguage[calendar=hebrew,marcheshvan=true]{hebrew}
(i.e., just saying “marcheshvan” won’t work at the moment, you have to
say “marcheshvan=true.” The other option is needed because the calendar
is Gregorian by default).
You can check this by setting, for example, \day=17\month=10\year=2012
in a TeX file (that sets the date artificially to 17 October 2012
= 1 Cheshvan / Marcheshvan 5773).
However, now I’m left with a small dilemma: the name of this month has
been spelt, in English, as “Heshvan” for at least 20 years by Babel, and
that’s what Polyglossia has been using so far too. But from what I
understand ‘ch’ is traditionally preferred to transliterate the Hebrew
letter het, and that’s what I’ve been using here. Hence my question:
how should I write the English name of the month in Polyglossia?
Spelling it “marcheshvan” seems more traditional, and that’s what I
would name the option, too; while I’d like to keep “Heshvan” for
compatilibility reasons. Please advise.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How do mapping files affect hyphenation?
> It should be so. I agree with that, that’s the most sensible behaviour. What Ulrike needs are hyphenation patterns suited to the particular transliteration scheme she’s using. Depending on the transliteration, the patterns for other Slavonic languages could be useful; for ISO 9, I expect that Czech or Slovak patterns would actually give a good result. But if it’s a scheme that uses things like “sh” and “zh” for ‘ш’ and ‘ж’, there really needs to be special rules for these clusters (I expect that Czech patterns would break between ‘z’ and ‘h’ in most cases!). Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] How do mapping files affect hyphenation?
I don’t know the technical answer to that question, but considering what you say: >I would have expected the translittered text to be > hyphenated according the original russian rules but actually it is > not hyphenated at all: That hints that the text is hyphenated after transliteration, using Russian hyphenation rules, and these obviously don’t how to hyphenate words written using the Latin script. That doesn’t surprise me all that much. Indeed, transliteration rules could map sequences of characters to one single character in the output (unlikely for Russian, admittedly); and if the hyphenation patterns command a break in the middle of the original characters, where should the transliterated text be hyphenated? Actually, that situation isn’t so unlikely: I could imagine a transliteration system that would for example map “кс” to “x” (as in Александер), and it’s entirely possible to have a breakpoint between ‘к’ and ‘с’ (I didn’t check if that’s the case in the default patterns). Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Georgian in LaTeX?
Hi Adam,
In order to use the Georgian script, all you need is an appropriate
font, and fontspec to load it, with commands such as
\setmainfont[Script=Georgian]{}
or \setotherfont if your main document script isn't Georgian.
There is no Georgian support in Babel. What is Babel doing for you
that fontspec isn't?
As you point out, there is no Georgian support in Polyglossia either,
but if all you want to do is to use the Georgian script, you don't need
anything more than XeTeX and fontspec (and a font). Other than that, if
there are specific requirements for typesetting Georgian and you can
make a detailed specification, I'm happy to add support for it in
Polyglossia.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Current Hebrew month spelled incorrectly in Polyglossia
On Wed, Nov 23, 2011 at 11:22:46PM +1100, Vafa Khalighi wrote: > This is a bug of polyglossia. You can make a bug report He already did. I'll correct the spelling shortly. I have had little time to look into the more serious bugs lately; sorry about that. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] TeX in the modern World. (goes OT) Was: Re: Whitespace in input
On Fri, Nov 18, 2011 at 10:16:31AM +0100, Keith J. Schultz wrote in reply to Ross Moore: > You are probably a little young to know this, but TeX's original output > format was a dvi file. I think I'll have this one framed and sent to Ross for his next birthday. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
> "The latter" is what the TeXbok says (P.~39) : "Once a category code > has been attached to a character token, the attachment is permanent." Yes, because you meant individual tokens (which I understood in retrospect). But in the context of the discussion, you really seemed to be saying that you could not change the \catcode's of characters to be read, which was the point (not that there is much point left to the whole threads any more...) Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
On Tue, Nov 15, 2011 at 02:20:17PM +, Philip TAYLOR wrote: > No ! "A catcode is for life, not just for Christmas" ! Once a > character has been read, and bound into a character/catcode pair, > that catcode remains immutable. Do you mean that as a general good practice in TeX programming, or as a description of how TeX works? The latter is obviously wrong. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Why I do get nonsense characters when I use unicode characters inside \message with XeTeX?
Thanks, it confirms what I suspected (I tried to compile your TeX file but didn't get the same result; the xepersian version was too old on the computer I was using then, I guess). XeTeX really seems to take bytes in account when printing messages to the log file and terminal; not characters. This leads to the problem you experienced. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Why I do get nonsense characters when I use unicode characters inside \message with XeTeX?
Off the top of my head, it could be that XeTeX truncates its output to 79 bytes (not characters), and that some of the UTF-8 byte sequences are (incorrectly) split in half. The two codes you see on either side of the line (DB and B1), when interpreted as hexadecimal digits, are the UTF-8 form of U+06F1 EXTENDED ARABIC-INDIC DIGIT ONE. But it's hard to tell without seeing the actual log file and the original source; clearly the file you attached isn't the whole story, because it does have any \message, and does not use an appropriate font. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX/TeX Live : Setting the default language
Just edit your language.def file. Actually, you can create a one-line file that says "british loadhyph-en-gb.tex" (not hyph-en-gb.tex!) and create the format with fmtutil. Arthur -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
