Re: [XeTeX] xetex crash: interaction between interchar and linebreaklocale mechanisms
On 9/9/2023 4:20 PM, Ulrike Fischer wrote: Am Sat, 9 Sep 2023 15:39:51 -0400 schrieb Mike Maxwell: I haven't tried LuaTeX in recent years, but it sounds like if you ran Burmese through it and used the HarfBuzz shaper instead of the default(?) shaper, it might work for Burmese. Yes that should work fine, luahbtex is the default engine for lualatex since tl 2020 and harfbuzz can be used with latex + fontspec by using the option Renderer=Harfbuzz see e.g. https://tex.stackexchange.com/a/515934/2388 Thank you, that is good news! At this point, what are the advantages of Xe(La)TeX vs. Lua(La)TeX? Apart from the crash Andrew reported, and the staleness of XeTeX's development. Or maybe putting it differently, are there any situations that require XeTeX? Mike Maxwell
Re: [XeTeX] xetex crash: interaction between interchar and linebreaklocale mechanisms
Back in 2018, I was trying to use LuaTeX to typeset multiple scripts. (We needed its capability to tell you where on the page bounding boxes were.) LuaTeX worked ok for some scripts, but failed for example for Tamil, where glyphs don't always appear in the same order on the page as their underlying characters do. This sort of issue arises with many Indic scripts, and something similar would probably happen with Burmese, which in some ways is an even more complex script than other Indic ones. At the time, I recall the LuaTeX developers saying they were not interested in solving this issue, and that instead script-specific libraries should be developed. (I'm going by memory here, I don't have links to that discussion, although see here: https://tex.stackexchange.com/questions/.) Since that time, Khaled Hosny has conducted an "experiment" (his term) in using HarfBuzz in LuaTeX (https://tug.org/TUGboat/tb40-1/tb124hosny-harfbuzz.pdf, as reported in 2019), and Kai Eigner also did similar work (https://github.com/tatzetwerk/luatex-harfbuzz). The LuaTeX wikipedia page says LuaTeX "includes" the HarfBuzz engine (and links to the above two reports). I haven't tried LuaTeX in recent years, but it sounds like if you ran Burmese through it and used the HarfBuzz shaper instead of the default(?) shaper, it might work for Burmese. I'll be interested to hear what you find. Mike Maxwell On 9/9/2023 2:29 PM, Andrew Goldstone wrote: Thanks--it turns out that xelatex still segfaults if I attempt to combine ucharclasses and \XeTeXinterwordspaceshaping=2 in a longer document. I do think this is a bona fide xetex bug but don't have the knowledge of the xetex source to trace it further. As for lualatex it seemed to have more trouble than xelatex with the complex ligatures in Burmese. The lineation issues are a lower priority for my colleague than simply being able to typeset his mixed-script text, so I'll help him to a workaround with xetex, if no other suggestions for fixes are forthcoming. All best, Andrew Sat, Sep 9, 2023 at 5:37 AM Ulrike Fischer <mailto:ne...@nililand.de>> wrote: Am Wed, 6 Sep 2023 10:40:16 -0400 schrieb Andrew Goldstone: > I believe this is the same issue as was raised on StackExchange in 2019 > https://tex.stackexchange.com/questions/503498/trouble-with-stacked-consonants-burmese-script <https://tex.stackexchange.com/questions/503498/trouble-with-stacked-consonants-burmese-script> > but I couldn't find any further discussion of a fix for the crash. I don't think that there is a fix and the xetex development is rather stale. Personally I would try with lualatex. -- Ulrike Fischer http://www.troubleshooting-tex.de/ <http://www.troubleshooting-tex.de/>
Re: [XeTeX] diacritics stacking using anchor points
math.aegean.gr/~atsol/tmp/NewCM10-Regular.otf <https://myria.math.aegean.gr/~atsol/tmp/NewCM10-Regular.otf> thanks for any help, Antonis. -- Mike Maxwell "Digital objects last forever--or five years, whichever comes first." --Jeff Rothenberg
Re: [XeTeX] strange case of overlapping graphics
>>> There is no overlapping if pdflatex ix used but the images >>> are distorted, If it's the case that s.t. is wrong with the image (and okular, gwenview and gimp are compensating somehow), could you import the image into one of these other programs, then export it from there? On 6/10/2021 10:35 AM, Janusz S. Bień wrote: On Thu, Jun 10 2021 at 16:23 +02, Zdenek Wagner wrote: Yes, there is something strange. I can reproduce the behaviour with xelatex. I prefer to stick to xelatex. There is no overlapping if pdflatex ix used but the images are distorted, see my result (after additional pdfcrop to remove the white space on the page). ddjvu can generate pdf directly, but the results are distorted in a very similar way... The picture itself looks fine in okular, gwenview as well as in gimp, both "file" and "exiftool" show the right dimensions. Zdeněk Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml On Thu, Jun 10 2021 at 9:26 -05, Herbert Schulz wrote: [...] Howdy, Also note that removing the height option from the first image will put the images side by side. Yes, I can reproduce this. Best regards Janusz -- Mike Maxwell "Digital objects last forever--or five years, whichever comes first." --Jeff Rothenberg
Re: [XeTeX] XeLaTeX for files using pstricks
On 4/23/2021 4:55 PM, Herbert Schulz wrote: The xelatexTR engine used by those files does exactly that... What is this xelatexTR? I just installed TeXLive 2021, and there doesn't seem to be any such file. Mike Maxwell
Re: [XeTeX] how to suppress doted circle next to a glyph
In my experience, a dotted circle is an indication that there's a
non-base character which needs a base character before it, but there's
no suitable base character. If you type a Unicode Combining Acute
Accent (U+0301), but there's no base character (like a vowel) preceding
it, you'll get such a dotted circle.
If I'm not mistaken, U+1133E is the Grantha Vowel Sign Aa. Maybe it
needs a consonant to its left?
On 9/25/2020 4:28 PM, François Patte wrote:
Bonjour,
I want to use some glyph using the command \symbol. In some case I get a
glyph with a dotted circle, how can I get the glyph without this circle?
For instance, if I type \symbol{"1133E}, I get this as a result after
compilation: ጾwith a dotted circle before.
Is it possible to eliminate the circle? And how?
Thank you.
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
FSF
https://www.fsf.org/blogs/community/presenting-shoetool-happy-holidays-from-the-fsf
--
Mike Maxwell
"I may not remember, but I never forget."
--Social Crimes, Jane Stanton Hitchcock
Re: [XeTeX] startup time
On 7/3/2020 2:28 PM, Zdenek Wagner wrote: There are several options: 1. Dump your own format with your styles. You will have to regenerate the format after update of any of these style files and you will have to take care of dependencies 2. Install TeX on a fast disk such as SSD 3. Increase your RAM and use larger disk cache, on my Linux computers the unchanged files can remain in cache for hours I already have 2 and 3, although afaict 3 has little if any effect, because the processing time appears to be taken up with macro expansion (or whatever it is that tex does while processing the preamble). 1 is what I was looking for, but how do you do it? I tried xelatex -ini but it chokes on the \documentclass; or when I try it on my style sheet alone, it chokes on the \ProvidesPackage. Apparently it works with plain TeX, but not with LaTeX? And I'm not sure this would do what I want anyway; what it means to "be xeinitix"; a web search for that term was unproductive (unless you're looking for some kind of gas warning light). Can you give me a lead on how to do #1?
[XeTeX] startup time
I've noticed (and you probably have too) that a good proportion--maybe half, for a 30 or so page document--of the runtime for a xelatex document is startup: reading the style files. Since I re-use the same style files for most papers, I seldom have a mistake in those, so it seems a waste to re-run them every time I want a PDF of a new version of my doc (or every time xetex finds a mistake in my doc). Is there no way to save the results of loading that, so that it could be re-loaded more quickly next time? -- Mike Maxwell "I may not remember, but I never forget." --Social Crimes, Jane Stanton Hitchcock
Re: [XeTeX] Discretionary line-breaks in Tamil
On 9/29/2019 3:02 PM, Suki Venkat wrote: Then went on to hack the hyph-ta.texfile and did "mktexfmt xelatex" to produce nice results using XeLaTeX. It turned out the uni200B was not defined in the font, although uni200C and uni200D were defined. Then managed define uni200B in fontforge and it does seem to produce the same result even if the uni200B (ZWSP or DLB) is defined in the font or not. I'm speaking from ignorance here--I know nothing of the internal workings of xetex--but it seems to me that the question of defining a glyph for U+200B is beside the point. It should not, it seems to me, have a glyph. Instead, xetex should break the line or not when it encounters this code point, and then--regardless of the line break--delete the character. It's a zero width character, and its height is irrelevant (unlike a strut), so there's no shape to show. -- Mike Maxwell "I am, by a flood, borne back to that wondrous period, ere time itself can be said to have begun; for time began with man." --Herman Melville, Moby Dick
Re: [XeTeX] Xetex equiv to luatex's \directlua{}
On 3/24/2018 6:13 AM, Philip Taylor (RHUoL) wrote: maxwell wrote: I'm just finishing up a project that involved typesetting text in several languages, while outputting an XML file that defined in X/Y coordinates the position and size of the bounding box surrounding each line of text in the PDF. [...] [I]s there any way I could have done something similar using xetex? That is, called another programming language to output box positions and sizes. I suppose it's possible to write to an XML file in xetex natively, but I'm not sure how I could get the positions and sizes of boxes. Is it possible that these three PdfTeX/XeTeX primitives might help : * \pdfsavepos Saves the current location of the page in the typesetting stream. * \pdflastxpos Retrieves the horizontal position saved by \pdfsavepos. * \pdflastypos Retrieves the vertical position saved by \pdfsavepos. Thanks--playing around last night, I found a way (I think) to do what I wanted to do using the \zsavepos macro in the zref package. In case anyone is interested, there's an example here: https://tex.stackexchange.com/questions/10343/ What I still can't do is determine in xetex what the text contents of a box is. I can do that in luatex; the Lua function nodeText() here-- https://tex.stackexchange.com/questions/228312/ does that. I don't think there's an equivalent in xetex. Combining luatex and xetex, I think I have an (untested) solution to my problem: first running my document through luatex to get the line boxes and their contents, and then running it through xetex to get the proper shaping, telling it where to put each line box and what to put in the box. Very much a kludge, and I suppose the output won't be perfectly justified, but for our purposes that won't matter. -- Mike Maxwell "My definition of an interesting universe is one that has the capacity to study itself." --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Xetex equiv to luatex's \directlua{}
On 2018-03-23 16:44, David Carlisle wrote: there are several ways to get the box output in classic tex (or xetex) although perhaps the easiest (and safest in terms of not accidentally affecting the typeset positions) is to use \showoutput so all boxes are (somewhat verbosely) logged in the log file, and then parse that with perl or python or whatever to get whatever lengths you need, David David, do you have a life? Everywhere I see some conversation about TeX, your name is there... Anyway, I just now tried your idea (thanks!), but I'm not clear how to parse the results. When I run a small example with xelatex, I see lines like - .\vbox(608.40024+0.0)x360.0, shifted 54.0 ..\vbox(12.0+0.0)x360.0, glue set 12.0fil (some lines omitted) ..\vbox(541.40024+0.0)x360.0, glue set 503.14648fil (some lines omitted) ...\hbox(7.71974+2.25569)x360.0, glue set - 0.17555 \hbox(0.0+0.0)x17.0 \TU/lmr/m/n/10.95 Now -- (where the word "Now" is the first word in one of the lines of PDF output). I think the first hbox is a line of text in the output, but I don't know what to make of those numbers. They seem to be approximately the same for every line's hbox in the trivial example I wrote (except for the number after "glue set", which is different for each one), so maybe they translate into the horizontal position and/or size of the line's hbox. And maybe the vbox line is the entire paragraph's box, where the numbers translate into the vertical position and/or size of the vbox. But I'm not sure how to go from those numbers to the position (in points) of each hbox in the output PDF. Is there a guide somewhere to interpreting this trace? I didn't see anything on-line. Mike -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] Xetex equiv to luatex's \directlua{}
I'm just finishing up a project that involved typesetting text in
several languages, while outputting an XML file that defined in X/Y
coordinates the position and size of the bounding box surrounding each
line of text in the PDF. I used Luatex, because that made it possible
to call Lua from Luatex using the \directlua{} command) to pass
information to Lua, and to return information from Lua to Luatex using
tex.print(). I also used Lua to write the XML file.
Too late, I discovered that LuaTeX botches the rendering of one of the
languages, Tamil. Tamil has a complex script, with some typical Indic
script features; so presumably LuaTeX would also mess up on other
languages with complex scripts. XeTeX of course does just fine at
rendering text in complex scripts.
As I say, it's too late to change now, but is there any way I could have
done something similar using xetex? That is, called another programming
language to output box positions and sizes. I suppose it's possible to
write to an XML file in xetex natively, but I'm not sure how I could get
the positions and sizes of boxes. My style sheet defines a command,
\outputpara{}, that requires the user to specify the X-position of the
paragraph, and hence of lines in the paragraph, where line breaks are of
course decided on the fly. The command optionally specifies the
Y-position of the paragraph, but the Y-position of each line in the
paragraph--except the first--is determined by the usual TeX algorithms.
Getting TeX to tell me those Y-positions, as well as the vertical size
of the box, was the difficult part. But maybe I was missing something
obvious?
Mike Maxwell
University of Maryland
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Devanagari ASCII to Unicode mapping
On 2/18/2018 4:10 AM, ShreeDevi Kumar wrote: >> The LDC *might* still have the encoding converters laying around somewhere. These will be very useful, if they can be made available. There is a need for easily converting legacy documents to Unicode. One of the applications for which someone was looking for these recently was for checking for plagiarism in student projects/thesis. I'd suggest contacting them. Their website is ldc.upenn.edu There's a "Contact us" tab near the upper right-hand corner of their page. -- Mike Maxwell "My definition of an interesting universe is one that has the capacity to study itself." --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Devanagari ASCII to Unicode mapping
On 2/17/2018 11:58 AM, ShreeDevi Kumar wrote: Before unicode, devanagari fonts used the ASCII range (legacy fonts) - however AFAIK there is no standardization in the mapping, though various families of fonts had similar mapping. see http://hindi-fonts.com/tools for converters from different mappings to unicode. So, ASCII to Unicode mapping for Devanagari will change based on the font used. Indeed! In 2003, DARPA held a "surprise language exercise", the goal of which was to produce (very basic) MT etc. tools for Hindi, in a month's time. I had been involved in the prep for it to ensure that there would be no roadblocks (at the time, I was working at the LDC). One of the things that Bill Poser and I verified was that there was a Unicode encoding for Hindi/Devanagari. There was, but that was the wrong question. The right question was whether any Hindi website used Unicode. The answer to that was that the BBC and Colgate did, but hardly anyone else. A few Indian government sites used ISCII, which wouldn't have been bad, but most places used proprietary encodings that went along with a proprietary font. Worse, these were not simple code-point-to-character encodings; it was as if the Latin letter 'l' had been encoded as 'l', but then 'd' had been encoded as 'c' + 'l', 'b' as 'l' + a sort of backwards 'c', 'p' as a lowered 'l' _ the backwards 'c', etc. It was a mess, and for awhile it was unclear whether the exercise would fail because most of the data we needed was in these weird proprietary encodings. (It eventually succeeded.) There are some notes here-- http://languagelog.ldc.upenn.edu/myl/ldc/hindi_fonts_and_conversions.html --that Mark Liberman of the LDC made at the time concerning some of the issues. Most of it is long out of date (and the links are probably broken), and these proprietary encodings have thankfully been replaced by Unicode; but if you're dealing with documents from that era, you might still run into them. The LDC *might* still have the encoding converters laying around somewhere. -- Mike Maxwell "My definition of an interesting universe is one that has the capacity to study itself." --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Devanagari ASCII to Unicode mapping
On 2/17/2018 11:08 AM, Daniel Greenhoe wrote: Does anyone know where I can find an ASCII to Unicode mapping for Devanagari? For example, it seems that the Devanagari glyph "ब" is encoded as 0x61 (hex) in ASCII (lower case 'a' for the Latin alphabet), but is 0x092C in the Unicode standard: http://www.unicode.org/charts/PDF/U0900.pdf So what I am asking for is a map (or table) that maps 0x00-0x7F in Devanagari ASCII to 0x0900-0x097F in Unicode. In addition to the ASCII-to-Devanagari transcription system that Philip Taylor mentioned, you may be interested in the ISCII encoding for Brahmi-derived writing systems, including Devanagari: https://en.wikipedia.org/wiki/Indian_Script_Code_for_Information_Interchange This is _not_ an ASCII-to-Devanagari encoding, rather it leaves the ASCII range intact, and encodes Devanagari (etc.) in the range 128 (actually, 161)-255. It was afaik never widely used, but there were (and probably still are) fonts for it. I don't imagine those fonts would be terribly high quality by today's standards, e.g. I'd be surprised if they handled conjunct characters. FWIW, there was a similar encoding called TSCII for Tamil. iconv can be used to map TSCII to other encodings, but for some reason it doesn't seem to have ISCII in its reportoire (it does include VISCII, but that's a legacy Vietnamese encoding). -- Mike Maxwell "My definition of an interesting universe is one that has the capacity to study itself." --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec and fonts without certain styles
On 10/26/2017 5:33 AM, Ulrike Fischer wrote:
If you set the font explicitly the messages disappear:
...
\setmainfont{Scheherazade}[Script=Arabic,ItalicFont=*,BoldFont=*,BoldItalicFont=*]
Thanks, that's the answer I needed!
--
Mike Maxwell
"My definition of an interesting universe is
one that has the capacity to study itself."
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] fontspec and fonts without certain styles
For many of the fonts we use, there is no italic version (and in some
cases no bold). This is natural for Arabic and Thaana scripts, since
there is no tradition of italicizing them. (Nasta'liq is quite a
different sort of style...)
When I include a font loading command for one of these fonts, like--
\setmainfont[Script=Arabic]{Scheherazade}
or
\newfontfamily\naskhfont[Script=Arabic]{Scheherazade}
--fontspec outputs something that could be taken as a warning, but is
probably more like information:
Could not resolve font "Scheherazade/I" (it probably doesn't exist).
Is there a way to tell fontspec not to bother looking for an italicized
(or bold) version of particular fonts, and thereby prevent its
outputting this message? Adding the parameter
ItalicFeatures={}
(where the {} would normally enclose the path to a font file) does not
turn off the message.
I looked at the code for the \@@_find_autofonts macro in
fontspec-internal.dtx, but it did not enlighten me.
Maybe I should just not worry...
MWE follows my sig line.
Mike Maxwell
University of Maryland
---MWE-
\documentclass{article}
\usepackage{fontspec}
\setmainfont[Script=Arabic]{Scheherazade}
\begin{document}
سلام
\end{document}
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] metalogo and bidi packages
I've installed the new TeXLive 2017. There is a conflict between the
metalogo and bidi packages. I don't suppose this would be a biggie,
except that the xltxtra package loads metalogo. (And something else I'm
using loads xltxtra...)
The conflict is shown in this minimal example:
--
\documentclass{report}
\usepackage{metalogo}
\usepackage{bidi}
\begin{document}
hi
\end{document}
--
The error msg is:
(/home/groups/tools/texlive/2017/texmf-dist/tex/xelatex/bidi/latex-xetex-bidi.d
ef
! LaTeX Error: Command \XeTeX already defined.
Or name \end... illegal, see p.192 of the manual.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.122 ...di@reflect@box{E}}\kern-.1667em \TeX}}$}}
The reverse loading order (bidi, then metalogo) triggers an error msg
from bidi about loading order, and probably wouldn't help anyway.
For the time being, doing the following before bidi is loaded seems to
solve the problem:
-
\let\XeTeX\relax
\let\XeLaTeX\relax
-
Mike Maxwell
University of Maryland
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [INDOLOGY] {भारतीयविद्वत्परिषत्} Re: Issues with Sanskrit 2003 font
On 6/18/2017 4:04 AM, Zdenek Wagner wrote: as far as I know the Devanagari fonts are either Sanskrit with all conjuncts that cannot be switched off or Hindi without the Sanskrit conjuncts. Do other languages that use Devanagari, like Gujarati, use the same conjuncts as Hindi? -- Mike Maxwell "My definition of an interesting universe is one that has the capacity to study itself." --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] new version of HarfBuzz
On 2017-04-24 11:15, Jonathan Kew wrote: On 24/04/2017 15:36, Bobby de Vos wrote: The xetex binary as installed by the Tex Live installer in /usr/local does not seem to load those two libraries. Right; the TL-distributed binaries avoid dynamic linking as far as possible, in order to maximize portability and consistency. The other side of this, of course, is that they don't automatically benefit from library updates. Which brings me back to my original question: will xetex as distributed in TeXLive 2017 include this harfbuzz update? Or is it too late for that? Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] new version of HarfBuzz
On 2017-04-21 13:46, Jonathan Kew wrote: I believe that xetex should be unaffected by that bug, because that was an issue with the harfbuzz interface to graphite, but xetex uses graphite directly without going through the harfbuzz layer (provided you load the font with the /GR option, or whatever the fontspec equivalent of that is). There is certainly a bug in the way certain sequences of characters are output by xe(la)tex. Whether the bug is in xetex, or harfbuzz, or the font itself is beyond my ken. Martin Hosken (who submitted the harfbuzz bug fix) seemed to think that would fix the issue in xetex, but I'm not sure he actually tested it with xetex, which I suppose would require re-compiling xetex. I can supply a simple XeLaTeX file for testing; it requires having the Awami Nastaliq beta font from SIL. I can also put you (or anyone else) in touch with the other developers of that font, although I suppose Martin is the expert on this issue. I can also take this off-line if that would be more appropriate. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] new version of HarfBuzz
I believe (correct me if I'm wrong!) that xetex uses the HarfBuzz engine. There was a bug in this engine that prevented a new Nastaliq font from SIL from working properly. A fix for this bug has just been accepted (I believe it's this one: https://github.com/behdad/harfbuzz/pull/475). It's not clear to me whether this can get into xetex before the next TeXLive release, given the schedule here: https://www.tug.org/texlive/ Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] version issue? font issue
I'm working with a font developer to track down a problem. We've been getting their betas (and before that, their alphas) of a Nasta'liq font. Up until this last version, the joining of characters worked fine; with their latest version, there is no joining. Except it works on their (Windows) machine, it only fails on my (Linux) machine. Not only can't we figure out why the characters don't join when they should on my machine, we don't understand why it would work on one machine and not the other. And since they can't reproduce the issue on their machine, it's hard for them to know how to fix it. The font requires Graphite (in all versions we've tested). I have verified that simply switching between the two beta versions on my machine toggles the joining behavior. My xetex says: XeTeX 3.14159265-2.6-0.6 (TeX Live 2016) ... Compiled with Graphite2 version 1.3.8; using 1.3.8 Their xetex says: This is XeTeX, Version 3.14159265-2.6-0.6 (TeX Live 2016/W32TeX) (preloaded format=xetex) (I'm not sure what version of Graphite they have, but theirs is the one that's working.) My version of xetex is a 64-bit version, theirs appears to be 32-bit, if I'm reading the above correctly. I suppose something could be different in the two versions... I don't have the 32-bit version of xetex installed, but I guess I could do so. (Presumably Windows and Linux versions also differ.) I had previously seen a failure in a similar situation where we had a woff font whose filename was the same except for the ".woff". But this time there are no .woff files laying around. I've also looked for other copies of the font, but find none (and fc-list is pointing to the correct one). Any suggestions on where we should look? Either in the font, or in xetex itself. (There's obviously an issue with the new version of the font, since earlier versions worked; but given that their copy of xetex works on this latest font and mine doesn't, it's possible there's also something amiss with the version of xetex I have.) Michael Maxwell University of Maryland -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] modified changebar.sty
Some years ago, Apostolos Syropoulos modified the changebar.sty file
that comes with the TeXLive distro so that it would work with xelatex,
by adding
\DeclareOption{xetex}{\cb@xetexcheck}
etc.
This code seems to be working, but it never got into the TeXLive distro.
Should(n't) it?
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Fwd: Re: woff file
On 10/5/2016 6:59 PM, Philip Taylor wrote: > Cf. http://tex.stackexchange.com/questions/330195/how-to-set-up- > the-font-scheherazade-for-use-with-xelatex The .woff file does seem to have been the problem. As suggested by Khaled there, I deleted the .woff files (which we didn't need), and the problem seems to have gone away. Thank you, Philip, for bringing the above post to my attention! Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] woff file
We're getting a coredump from xelatex under certain circumstances. It's reproducible for a given input file, but we haven't figured out a minimal file that will cause it. My hypothesis at the moment (and this is about hypothesis #53) is that it's caused by an update I did recently from the SIL Scheherazade font version 1-something to the latest v2.100. I was planning on uninstalling that version and going back to an earlier version, but I noticed s.t. odd. If I take the .xdv output of xelatex and try to run xdvipdfmx on it, I get the following error (not a coredump, xdvipdfmx just exits after this error msg): --- ][30][31][32][33][34][35][36][37][38][39][40][41][42][43][44][45 xdvipdfmx:fatal: Cannot proceed without the font: /groups/tools/fonts/Scheherazade-2.100/web/Scheherazade-Regular.woff --- And of course this filename appears in the .xdv file. The .woff file in fact is there (along with the .ttf files), so I'm not clear why the error msg says it can't proceed without it. But what I really don't understand is why it would want a .woff file in the first place. My understanding is that .woff files are for web pages, not PDFs. Also, I'm not clear how xdvipdfmx knows about the Scheherazade-Regular.woff file. fc-list --verbose doesn't list any such fontfile, and I thought xelatex with the fontspec package just knew about whatever fontfiles fc-list knew about. So my question is, is there any legitimate reason xelatex and xdvipdfmx should want a .woff file? Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] prioritizing OTF fonts
On 2016-07-28 07:28, Herbert Schulz wrote: You can load the font using file names rather than font names. It's a bit more complicated but certainly doable. That resolves any ambiguity the way you wish. Yeah, I was hoping there was an easier way than that, like [prioritizeOTF=true]. (Although I suppose that might need to be done at the level of /etc/fonts/local.conf.) Thank you though! Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] prioritizing OTF fonts
Does fontspec load *only* OpenType fonts? The intro to the fontspec package documentation says The fontspec package allows users of either XETEX or LuaTEX to load OpenType fonts in a LATEX document. Does that mean it doesn't load TrueType etc. fonts, even if there are no OpenType versions of those fonts? Some of the things I've read on-line (like http://tex.stackexchange.com/questions/241927/problem-using-ttf-fonts-with-xelatex) seem to imply that fontspec loads ttf fonts just fine. In which case I'll have a different question: how to ensure that it prioritizes OTF fonts over TTF fonts fc-list finds two such fonts. -- Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Embed full font in PDF
On 2016-07-22 15:10, Zdenek Wagner wrote: ... The customer for whom I prepared a package file for a journal depends on files from authors and thus has no control over authors' computers. Finally he decided not to use DejaVu and other special fonts but only TeX Gyre fonts. Since then they have no problems. DejaVu fonts evolve too quickly and if you upgrade, the page breaks may change and even the total number of pages will be different. It really happend and they were unable to create the final PDF and time was running, I had to create it on my computer with "better" version of the DejaVu fonts. I do not want to dehonest the fonts, I just report my problems in the past. IMHO they are not production ready. Thanks for the advice, I can't remember whether we tried TeX Gyre. Another alternative, which I have not tried yet, seems to be the Fira Sans font, which exists in both proportionally and mono-spaced versions: https://en.wikipedia.org/wiki/Fira_Sans I'm not sure what its code point coverage is, nor whether it handles stacked diacritics; we'll see. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Embed full font in PDF
On 2016-07-22 14:55, Zdenek Wagner wrote: 2016-07-22 20:05 GMT+02:00 maxwell <maxw...@umiacs.umd.edu>: On 2016-07-22 13:29, maxwell wrote: ... Moral of the story: upgrade fonts before complaining. I had an opposite experience a few years ago. It was necessary to downgrade the DejaVu fonts in order to make them work properly with XeTeX. I do not remember the number of the broken version. I also had another experience with these fonts: stacked diacritics don't work with the mono style font. Six years ago, when I initially reported this problem, stacked diacritics would overstrike each other. They no longer overstrike, but the second diacritic winds up instead over the next base character (to the right in a left-to-right script). I should probably use some other sans serif font. As I recall, the problem is that there aren't a lot of sans serif monospaced fonts out there that have combining diacritics; DejaVu was about the only one, last time I looked. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Embed full font in PDF
On 2016-07-22 13:29, maxwell wrote: The new version of Adobe Acrobat (which I have the misfortune to be using at my office) is outputting a warning where we didn't used to get a warning. Namely, it complains about one particular font in our PDFs. The warning is: Cannot extract the embedded font 'LOFCAW+DejaVuSansCondensed. Some characters may not display or print correctly. In fact it displays unaccented characters correctly, but leaves a blank where "accented" characters should appear (à, ö etc.). Well, cancel this: I downloaded the newer version of this font, and it seems to work fine. (I had been using v2.30, I now have 2.36.) Sorry for the noise. Moral of the story: upgrade fonts before complaining. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] Embed full font in PDF
The new version of Adobe Acrobat (which I have the misfortune to be using at my office) is outputting a warning where we didn't used to get a warning. Namely, it complains about one particular font in our PDFs. The warning is: Cannot extract the embedded font 'LOFCAW+DejaVuSansCondensed. Some characters may not display or print correctly. In fact it displays unaccented characters correctly, but leaves a blank where "accented" characters should appear (à, ö etc.). This appears to be a problem for this particular DejaVu font, but not e.g. for CharisSIL. But when I run pdffonts on the output pdf, I don't see any relevant difference between these two fonts: ULCJWW+CharisSIL CID TrueType yes yes yes5 0 ... LOFCAW+DejaVuSansCondensed CID TrueType yes yes yes 809 0 (The information Acrobat gives in the "Fonts" tab of its "Document Properties" dialog looks similar to the above.) I thought maybe the problem was with the subsetting of the font (although as you can see, both the working Charis font and the problematic DejuVu font have only embedded subsets). IIUC, font embedding is the responsibility of xdvipdfmx. So I tried forcing this program to embed all fonts would help, by supplying the -E flag to xdvipdfmx; but this has no effect on the full embedding of this font, it still embeds only a subset. (Is there no way to force xdvipdfmx to embed full fonts, rather than subsets?) And that may not be the problem anyway, since the CharisSIL font is also a subset. I've opened these PDFs in Chrome, and they display all the DejaVu characters just fine. That said, I can't definitively say that the problem is with Acrobat; for all I know, Chrome is silently substituting some similar font for the accented characters (although they look right when I magnify the image--in particular, the 'a' with the grave looks identical to the 'a' without the grave--so if it's another font, it's an exceedingly similar one). Has anyone else run into this problem with the DejaVu fonts and Acrobat? I can make a MWE if that would help; I'm just hoping someone else has already run into this problem and has a work-around :-). Mike Maxwell University of Washington -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi and fontspec
On 6/24/2016 7:27 PM, Gildas Hamel wrote:
I ran into the same problem and noticed it in the numbering of
footnotes and lists. The solution for now, according to Ulrike
Fischer, is to add
\makeatletter\@Latintrue\makeatother to the polyglossia language
settings, because "bidi tests for \if@Latin, so you can get around
the problem by setting it to true."
See:
http://tex.stackexchange.com/questions/312874/polyglossia-or-bidi-bug-d-gets-inverted-to-d/312881#312881
Thanks for the pointer--I'm not using polyglossia, so afaict the above
solution doesn't quite work for me. But I was successful with a slight
variant of this, from
http://tex.stackexchange.com/questions/84293/amsmath-bidi-siunitx-possible-bug
(which addressed what I guess was a different bug, since it was in
2012). This work around is to define \@Latintrue as a name (I think
that's what this does, my tex creds are not good):
\usepackage{bidi}
\csname @Latintrue\endcsname
--
Mike Maxwell
maxw...@umiacs.umd.edu
"I cannot believe that our existence in this universe
is a mere quirk of fate, an accident of history, an
incidental blip in the great cosmic drama. Our
involvement is too intimate. The physical species
Homo may count for nothing, but the existence of
mind in some organism on some planet in the universe
is surely a fact of fundamental significance. Through
conscious beings the universe has generated
self-awareness." --Paul Davies
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] bidi and fontspec
I believe I've run into a bug in the interaction of fontspec and bidi in
the 2016 TeXLive distribution. However, it appears to be so simple to
trigger that I'm wondering whether it's something I'm doing.
The WME is:
\documentclass{report}
\usepackage{fontspec}
\usepackage{bidi}
\begin{document}
The number 12. The number 34.56. Some more text.
\end{document}
The result of running xelatex on the above is the text:
The number .12 The number .56.34 Some more text.
You'll notice that the two numbers appear in reverse order across the
periods--that is, if you have
in the input file, you get
in the PDF. But the digits inside are in the correct order.
Other punctuation that I've tried (including the comma) do not seem to
trigger this bug, only the period. (Hexadecimal digits A-F block the
reversal, too :-).)
Loading fontspec seems to be necessary for this bug to happen. And I'm
not actually invoking either bidi or fontspec.
Can someone reproduce this?
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec and Nikosh font
Not sure if Will is on this mailing list, but I'm cc'ing him using his
email address on the fontspec document. (The doc doesn't have the
co-author's email, Khaled Hosny, but I think I've seen him here.)
On 2016-06-20 17:55, Jonathan Kew wrote:
My guess is that this might be a bug in the TL'16 version of fontspec,
which looks like it is intended to support both the "new Indic spec"
OpenType tags such as 'dev2', 'bng2', etc, as well as the "old Indic"
versions 'deva', 'beng', etc, with preference being given to the v.2
tags. Perhaps that feature is broken?
...
One way to check what's wrong would be to search for the
\newfontscript{Devanagari}{dev2,deva}
declaration around line 2247 in fontspec-xetex.sty, and remove "dev2,"
from it so that it only looks for the old-style 'deva' tag. If that
makes Gargi work without complaint (using [Script=Devanagari] as
before), then you've identified a bug in fontspec and should report it
to Will.
I confirm that omitting 'dev2,' from that declaration causes fontspec
not to emit a warning when I do
\newfontfamily\sanskritfont[Script=Devanagari]{gargi}
and similarly for the Nikosh font, fontspec gives a warning when I do
\newfontfamily\bengalifont[Script=Bengali]{Nikosh}
unless I change
\newfontscript{Bengali}{bng2,beng}
to
\newfontscript{Bengali}{beng}
in fontspec-xetex.sty.
Thanks for the pointer, Jonathan!
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] fontspec and Nikosh font
With the version of fontspec that comes with TeXLive 2016, I'm getting
some warnings that I wasn't getting from the previous version, with the
'gargi' font (and another font). If you want to try it, I'm not sure
where the best (safest) place is to get the gargi font from, but one
place is here:
https://www.azfonts.net/load_font/gargi-1-3.html
(If you think that's unsafe, I could email you a copy of the file.)
The command I've been using to load the font is this:
\newfontfamily\sanskritfont[Script=Devanagari]{gargi}
but now fontspec gives me the warning
* fontspec warning: "script-not-exist"
*
* Font 'gargi' does not contain script 'Devanagari'.
If I run otfinfo --scripts on the font, I get this:
devaDevanagari
IIUC, the first field is the script code that appears in the font file,
while the second field is a human-readable version of that. On the
assumption that the code is what the font knows about, I tried this
command to load it:
\newfontfamily\sanskritfont[Script=deva]{gargi}
But then I get this error from fontspec:
! LaTeX error: "kernel/key-choice-unknown"
!
! Key 'fontspec/Script' accepts only a fixed set of choices.
l.528 ...ntfamily\sanskritfont[Script=deva]{gargi}
Fontspec does load this font without complaint if I do this:
\newfontfamily\sanskritfont[Language=Devanagari]{gargi}
but I'm lying to it, because Devanagari is a script, not a language.
(And elsewhere I'm successfully using Script= with the name of a script,
e.g 'Script=Thaana', where Thaana is the name of a script, Dhivehi is
the name of the language that uses the Thaana script.)
Is this font using a non-standard way of tagging scripts? Or am I
misunderstanding the way these codes are supposed to work?
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] discovering script support
On 2016-06-20 16:20, Zdenek Wagner wrote: otfinfo --scripts font-file.otf Thanks, that's what I needed. For some reason otfinfo doesn't show up with 'apropos' on my machine... Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] discovering script support
Is there a program (preferably a command-line program) that will tell me what scripts an OpenType font supports? The 2016 fontspec is giving me a warning where I wasn't getting one before, e.g. * fontspec warning: "script-not-exist" * Font 'Nikosh' does not contain script 'Bengali'. I've tried fc-list --verbose (including fonts that I know have script info), but afaict fc-list does not display script info. I've tried googling this question, but the word "script" seems to be generic enough that I can't find anything useful. There are plenty of hits with "does not contain script", but not afaict any that tell me how to determine what scripts a font supports. It may of course be possible that this font supports the Bengali script, but doesn't explicitly say that. But it makes me uneasy... Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex, hyperref, and new TeXLive
On 6/16/2016 11:46 AM, Herbert Schulz wrote: kpsewhich hyperref.cfg really return a file in the .../doc/... branch? Oh of course! well spotted. So that is the error. The file is correctly installed in the doc branch but the OP's $TEXINPUTS is incorrectly including the /groups/tools/texlive/2016/texmf-dist/doc tree and worse searching it before the /groups/tools/texlive/2016/texmf-dist/tex tree. Yeap, $TEXINPUTS was being set in order to include several directories of local files, so I assumed it also had to include the necessary paths under texlive/2016/. The problem was that $TEXINPUTS was set to include *all* paths under texlive/2016/texmf-dist/ and the documentation directories are included under "all paths." The trick is to use a trailing colon in the definition of $TEXINPUTS (you probably knew that, but I'm recording it here for the next time I make this mistake :-)), rather than an explicit pointer. The trailing colon selects whatever the appropriate directories under texmf-dist are, rather than all 27 subdirectories. I guess the other solution would be to include links from our texmf-local directory to our other directories of local files. (It would not be as easy to put these local files under texmf-local, because some of them come from other tools we use, e.g. dblatex.) I remain mystified why this problem didn't bite us with older TeXLive distributions (or why it suddenly surfaced with the 2016 version). Thanks for the help! Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex, hyperref, and new TeXLive
With the help of David Carlisle and Herbert Schulz, I've found part of
the problem. For some reason, in the (our?) 2016 version, kpsewhich
points to this hyperref.cfg file:
...texlive/2016/texmf-dist/doc/latex/listings-ext/hyperref.cfg
This .cfg file contains a \hypersetup{...} command that specifies
'ps2pdf'. Changing that to 'xetex' fixes the problem, at least for
xelatex (I'm not sure what would happen with other flavors of latex).
(Update: removing the line entirely, so it specifies neither xetex nor
ps2pdf, works too, and presumably won't cause trouble for other
latices.)
But:
1) Why does kpsewhich find that file, instead of this one:
...texlive/2016/texmf-dist/tex/latex/latexconfig/hyperref.cfg
which does not have any \hypersetup{} command, and which would
presumably not cause the same problem?
2) Why did this change from 2015 to 2016? We did a pretty vanilla
install, I think the only non-default choice we made was to use
'letter' instead of 'a4'.
3) Is this a bug? (meaning should I report it?)
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex, hyperref, and new TeXLive
On 2016-06-15 17:55, David Carlisle wrote:
But surely there are lots of people out there happily using xelatex
and hyperref without any problem, right?
yes but most will use no driver option or specify xetex which works,
the explicit dvipdfm option doesn't but I'm not sure when that
stopped.
We had previously been using the [xetex] option, but that has stopped
working as well--i.e. I just tried my file with
\usepackage[xetex]{hyperref}
and it fails with the same error msg as no parameter, or as with
[dvipdfmx].
this year we moved support to github and made some emergency
updates for luatex changes but as far as I can see nothing's changed
in the xetex code path for hyperref.
Right, an hour ago I did a diff between the 2015 and 2016 copies of
hyperref.sty, and came up with only a couple diffs, which looked
innocent to my inexperienced eye totally. But since then, at Herbert
Schultz's off-line suggestion, I did a "tlmgr --update", and now I get
quite a few other diffs (looks like some of them were to accommodate
Italian section names, but there are a few other diffs). The error msg
remains.
Why is this only showing up now?
No idea, can you send me the full log off list and I'll see if I can
debug
Will do, thanks!
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex, hyperref, and new TeXLive
On 2016-06-15 17:36, David Carlisle wrote: I get the same error with texlive 2015 so I don't think there is any recent change (since support for hyperref moved to github) that has changed this, with texlive 2015: (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def) (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg) ! Package hyperref Error: Wrong DVI mode driver option `dvipdfmx', (hyperref)because XeTeX is running. Mysteriouser and mysteriouser. 2015 worked fine for us, it was only when we updated to 2016 that we encountered a problem. But surely there are lots of people out there happily using xelatex and hyperref without any problem, right? Why is this only showing up now? Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex installation
On 3/13/2016 1:57 PM, Purnendu Chakraborty wrote:
I have tried using different fonts and the problem persists. I had
some Bengali documents which worked fine with an older installation
of TeXLive. The problem appeared once I upgraded my distribution.
Also I tried some standard TeX documents, compiled successfully by
others in different system and I know how the output looks like.
Thus I ruled out font problems. Bengali text looks alright when I
write it in gedit or any other word processor. Please let me also
tell you that not all the conjuncts appear messy but only two of
them.
Then probably the right thing is to create a minimal example which
contains a few conjuncts (those that don't work, plus a sample of those
that do). Then attach the source code for that minimal example--should
be 10-20 lines at most--to an email to this list. That's assuming the
font is free, otherwise it will be difficult for people on this list to
reproduce the problem.
Given that most of us don't know Bangla, it might also be necessary to
attach a PDF of the output you got, and maybe also a PDF of the correct
output (what you get with a word processor).
Note: I have restored Purnendu's original subject line, which got
changed to "XeTeX Digest..." in the last reply.
--
Mike Maxwell
maxw...@umiacs.umd.edu
"I cannot believe that our existence in this universe
is a mere quirk of fate, an accident of history, an
incidental blip in the great cosmic drama. Our
involvement is too intimate. The physical species
Homo may count for nothing, but the existence of
mind in some organism on some planet in the universe
is surely a fact of fundamental significance. Through
conscious beings the universe has generated
self-awareness." --Paul Davies
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] Graphite vulnerability
There is a vulnerability in the Graphite library: http://news.softpedia.com/news/vulnerability-in-font-processing-library-affects-linux-openoffice-firefox-500027.shtml Reportedly the problems have been patched in version 1.3.5 of Graphite2. But the version of xetex I'm using (3.14159265-2.6-0.2, from the TeX Live 2015 distro) says it uses Graphite2 v1.2.3. Will the next TeX Live distro's version of xetex use >= v.1.3.5? -- Mike Maxwell maxw...@umiacs.umd.edu "I cannot believe that our existence in this universe is a mere quirk of fate, an accident of history, an incidental blip in the great cosmic drama. Our involvement is too intimate. The physical species Homo may count for nothing, but the existence of mind in some organism on some planet in the universe is surely a fact of fundamental significance. Through conscious beings the universe has generated self-awareness." --Paul Davies -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] DVIasm
On 2016-02-09 08:22, Wilfred van Rooijen wrote: There are many "gotchas" going from Python 2 to Python 3 - with the change from "print" to "print()" being by far the most irritating (and the most stringently enforced by the Python interpreter). There are several IDEs which can highlight problems and give tips to migrate from Python 2 to Python 3 py2to3 is a command line program that will tell you most of the gotchas in a Python 2 program to their Python 3 program, and (with the -w flag) automagically make the changes: https://docs.python.org/3/library/2to3.html I think the only thing it didn't completely fix in several large programs we ran through it was the encoding conversion of stdin/stdout/stderr. As I recall, it has something to do with Python trying to detect the encoding in the shell environment. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
On 2016-01-21 03:11, Stefan Solbrig wrote: The documentation in the texlive installation contains a document (xetex-reference.pdf) that describes this in detail. (locate the file or type "texdoc xetex" if you have texlive installed.) thanks, that's what I needed! Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] misplaced accents in printout only?
On 2016-01-20 17:59, Dominik Wujastyk wrote:
...
*Input normalization*
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.
Hmmm, is there documentation for this \XeTeXinputnormalization? I can
find some references to it in a web search, but no explanation of
exactly what it does. What does "normalization" mean (NFC, NFD,...)?
Under what circumstances (besides the one Dominik saw) should this
setting be used? I don't want to go through printouts of 300 page
documents looking for misplaced diacritics...
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] Problem with bidi + longtable + caption packages
(Apologies if this isn't the right mailing list--the documentation I
have says I should send this to persian-...@tug.org, but I don't see
that mailing list on the list of TUG mailing lists, nor am I subscribed
to it... and if it does exist, I don't know how to subscribe to it.)
I've encountered a problem in the interaction between the longtable,
bidi, and caption packages. I'll attach the minimal example at the
bottom of this msg, but I have a question. We're running the 2014
TeXLive distro; I never got around to downloading the 2015 distro.
We'll probably do that, but we're having some connectivity issues
(serves me right for not having downloaded it months ago), and there are
some hoops to jump through, so it won't be instant gratification.
The issue we've found is that we want table captions to be ragged right,
rather than centered. Ordinarily, the caption package handles this
fine. But when I have a longtable, and I use the bidi package as well,
I can only get centered captions for long tables (ordinary floating
table captions work fine).
I've tried numerous variants of the code below, e.g. telling the caption
pkg to do ragged right only in one or the other of the places, loading
the bidi bpackage before or after the \captionsetup command (it cannot
be loaded before the caption pkg is loaded), etc.
Did anyone else notice this last year, and if so, has it been fixed in
the 2015 distro?
Mike Maxwell
University of Maryland
---Minimal example follows-
\documentclass{report}
\usepackage{longtable}
%Tell the caption pkg to do ragged right at load time:
\usepackage[singlelinecheck=off
,justification=raggedright
]{caption}
\usepackage{bidi}
%Tell the caption pkg again:
\captionsetup{singlelinecheck=off
,justification=raggedright
}
\begin{document}
\begin{longtable}{}
\caption{A long table}%Should be ragged right, but is centered instead
\tabularnewline
{} & {} & {} & {}
\tabularnewline
\end{longtable}
\end{document}
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with bidi + longtable + caption packages
On 10/20/2015 9:34 PM, Herbert Schulz wrote: On Oct 20, 2015, at 7:55 PM, maxwell <maxw...@umiacs.umd.edu> wrote: I've encountered a problem in the interaction between the longtable, bidi, and caption packages. >> ... The longtable environment is like a tabular environment, not the same as a floating environment like the table environment. It's floats that take the caption. Actually, the longtable package supports captions too, and the caption package (which allows further customization, http://www.ctan.org/pkg/caption) explicitly supports longtable: - Package support The caption package was adapted to the following packages which deals with captions, too: float, floatflt, fltpage, hyperref, hypcap, listings, longtable, picinpar, picins, rotating, setspace, sidecap, subfigure, supertabular, threeparttable, wrapfig, and xtab - 99% of our tables use ordinary tables, but 1% of our tables won't fit on a single page and require longtable. These need captions the same way regular tables do (there's also a continuation caption on the second and following pages of longtables). I didn't show a bunch of rows in my example to keep it minimal; the actual table where we first noticed the problem was just over a page in length. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Incorrect rendering of Vedic Sanskrit accents
On 2015-05-22 10:14, David M. Jones wrote: ... P.S. There's actually a third class of bug that is clearly visible in the table at the top of my document, but which I didn't mention explicitly: XeTeX won't typeset one of the Devanagari combining characters in isolation without adding a prothetic dotted circle (U+25CC). I was waiting for someone who knows more about this than I do to answer, but I'll display my ignorance. Afaik that's not a bug, that's the way combining characters are *supposed* to render when they don't have any character to combine with. There's a way to prevent that; I _think_ it's to precede the combining character by a non-breaking space (U+00A0). But I haven't tried that. Mike Maxwell University of Maryland -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Incorrect rendering of Vedic Sanskrit accents
On 2015-05-22 14:24, Bobby de Vos wrote: Some minority languages (that is, not the dominate language using a particular script) often use combining marks in ways not envisioned in order to extend the script to cover all the sounds in the minority language. So for those minority languages, having a dotted circle show up is not very helpful. Yes, but most font providers don't have such minority languages in mind. (SIL would be an exception.) That said, I've worked with such minority languages (including ones that are just in the process of defining their writing systems), and I don't recall a case where it was necessary to use a combining character without a base character. 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. That's of course not the same as saying it's never necessary, and the OP's need to show it in tables is one valid (IMO) use case. If it can be done with the method I mentioned, then that's probably good enough, at least for that use case. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] conformance (was: color=FFFFFF...)
On 3/29/2015 1:26 PM, Philip Taylor wrote: Zdenek Wagner wrote: Professional Acrobat contains Prepress Tools that can verify PDF and fix quite a lot of problems. It costs money but a damaged book may cost even more. And there is also a PitStop plugin that may be useful. Many print houses have it and complain if the supplied PDF does not conform to PDF/X. Yes, well ... I do have a licenced copy of Adobe Acrobat Pro, and it tells me that the PDF output from XeTeX is seriously PDF/X deficient ... I suppose I should worry about this--or actually, since I'm interested in producing archival PDFs of linguistic documents, I should worry about PDF/A. The wikipedia article about PDF/A (http://en.wikipedia.org/wiki/PDF/A) has a section about establishing conformance, but there are no links to such tools. There is a list here: http://www.pdfa.org/2011/08/validating-pdfa/ But those appear to all be commercial tools (although the one at http://www.intarsys.de/en/prod/pdfa-live may be good enough for our needs). And a rather old GitHub project to do validation here: https://github.com/gbm-bailleul/padaf A rather long discussion here (despite its having been declared out-of-scope!): http://stackoverflow.com/questions/569129/how-can-i-test-a-pdf-document-if-it-is-pdf-a-compliant It would be nice if xdvipdfmx had a switch to produce PDF/A (and maybe PDF/X) conformant documents. I don't know how easy that would be; there seem to be a lot of considerations. -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec and scaling
On 2015-01-20 04:55, Zdenek Wagner wrote: If I understand the scaling attribute correctly, let say, you have scaling=1.4 and you request \normalsize which id 10pt. Fontspec will multiply it and request 14pt font size instead. If there is an optical size available, it will be used. This last was my question: will the scaling attribute in Fontspec automatically use an optical size (or since scaling will probably not result in an exact optical size, will Fontspec scale the closest optical size). ...how do I know whether a font supports optical sizes (and which specific sizes it has)? fontinfo -z FILENAME There isn't any 'fontinfo' program on our Linux system, and I couldn't find such a program in a websearch. (There is a Firefox plugin by that name, written by Jonathan Kew, but that doesn't seem to be what you're referring to. Also some libraries for Python etc.) There is however a font information dialog box in FontForge. One of its tabs is Size. For the font I'm working with (MvElaafNormal.otf.ttf), the design size shows up as 0.0 pts. I suspect that means there are no optical sizes in this font. But none of the other fonts I looked at with FontForge (including Charis SIL and several free Adobe fonts) have anything but 0.0pts in the design size. Maybe it's only very high end fonts that have multiple optical sizes? In which case I've been on a wild goose chase worrying about whether Fontspec's scaling function will choose the appropriate optical size... Mike Maxwell University of Maryland -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec and scaling
On 1/17/2015 3:57 PM, Zdenek Wagner wrote: 2015-01-17 20:39 GMT+01:00 Mike Maxwell maxw...@umiacs.umd.edu: ...I guess my question is: _If_ a font provides optical sizes, then presumably telling Fontspec which point size to use causes it to choose the optical size provided in the font (assuming one exists for the requested point size). If this is correct, then to re-phrase my original question: If instead of specifying a point size for a particular font/stretch of text, I tell Fontspec to use scaling, then does it choose the closest optical point size provided in the font (and maybe magnify/demagnify it slightly if the scaling doesn't result in an exact optical point size)? Or does Fontspec instead magnify/demagnify the glyphs from the document's default point size? See section 7.6 (page 21) of the fontspec manual, it is explained there. I read that, but it doesn't refer to the 'scaling' attribute (it does use \scalebox in example 16, but I presume that's different). Maybe the fact that it doesn't mention scaling is my clue; scaling simply resizes whatever optical size is already chosen? If that's correct, then I should be using the 'OpticalSize' attribute instead of 'scaling'. But how do I know whether a font supports optical sizes (and which specific sizes it has)? Are such sizes embedded within a single font file, or do TTF fonts that support this have separate files for specific sizes? There's nothing obvious in the output of fc-list -v. -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec and scaling
On 1/17/2015 9:08 AM, Zdenek Wagner wrote: Fontspec does not do any magic. It just provides human friendly interface to the raw commands. It is somewhere in between the raw commands and GUI selection. It cannot in principle emulate optical sizes but it has properties for selecting them if they are available in the font. Thanks for the response. I guess my question is: _If_ a font provides optical sizes, then presumably telling Fontspec which point size to use causes it to choose the optical size provided in the font (assuming one exists for the requested point size). If this is correct, then to re-phrase my original question: If instead of specifying a point size for a particular font/stretch of text, I tell Fontspec to use scaling, then does it choose the closest optical point size provided in the font (and maybe magnify/demagnify it slightly if the scaling doesn't result in an exact optical point size)? Or does Fontspec instead magnify/demagnify the glyphs from the document's default point size? -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] fontspec and scaling
I have a question about how scaling is done in fontspec.
We produce some multi-script documents (grammars). It's sometimes the
case that for the non-Roman script, the glyphs at the normal point size
seem (in comparison with the Roman script glyphs) small. For example,
we're using a Dhivehi (Thaana script) font which at any given point size
looks quite a bit smaller than the Roman script. In part, this
difference is probably compensating for the fact that vowel get stacked
above (or occasionally below) consonant characters, so the Thaana
consonant and vowel glyphs are smaller to make the line height similar
to what you'd get with a Roman font at the same point size. Regardless,
the Thaana is hard to read unless we make it somewhat larger; at the
same time, I don't want to go to a larger Roman point size. (Frankly,
at my age *any* font is hard to read at a normal point size. But I
won't go there...)
The same thing happens with Arabic, particularly in the Nastaliq style.
In order to enlarge these Thaana glyphs into something readable at a
given point size, I've used fontspec's scaling attribute, e.g.
\newfontfamily\thaanafont[Scale=1.4,Script=thaa]{Mv Elaaf Normal}
Mv Elaaf Normal is an OpenType font.
One effect of this is that for any line where a Thaana word appears, the
separation between that line and the following line increases.
Apart from this, is there any negative? I'm not familiar with font
technology, but I have heard that it's not the best method to simply
magnify a font to be a larger size; rather, some things in glyphs may
change in proportion as the glyphs get bigger. (Or maybe I'm just
making that up, I can't find a reference to it now.)
How does Fontspec do scaling? Do I get the same typographic results by
using Scale as I would if I simply specified a larger point size?
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] avoiding line break after dash
I have a document that has word-initial dashes (they indicate that the word is
a suffix). When the paragraph they're in is just right, xelatex insists on
inserting an unwanted line break immediately after the dash. I've tried lots of
things to prevent this: setting the lccode for dash to zero, replacing the ASCII
dash with an en-dash (U+2013), using or not using a {} immediately after the
dash, putting an \mbox around the dash and word (works, but difficult to use in
the particular context I'm working in), and several other things that I can't
remember right now.
Another thing I've tried is to set the \exhyphenpenalty to 1. This works if
I do it in the preamble, but I don't really want it to have scope over the
entire document. But if I put that command inside a {...} together with the
dash+word, it has no effect.
Using a Unicode non-breaking hyphen (U+2011) appears to prevent the line break
when I try this with a different font. Unfortunately, the font I need to use
doesn't have a glyph for this code point, so I get a box in the PDF. (Is there
a way to use the ASCII dash glyph for this code point, while preserving the
non-breaking status of the U+2011 code point? Short of hacking the font.)
My MWE is after my sig line; the unwanted line break appears between the dash
and the abcd. This behavior seems to be exquisitely sensitive to things
around it, including the remainder of the paragraph, and the presence of other
dashes within the paragraph; hence the text may seem longer than it needs to be,
but I couldn't get the same bad result if I shortened it much.
Suggestions?
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
---MWE---
\documentclass[11pt,letterpaper]{report}
\usepackage{fontspec}
\setmainfont{Charis SIL}
\usepackage{hyphenat}
%\lccode`\-=0
%\exhyphenpenalty=1
\begin{document}
sentence-{}final particle
filler filler filler filler filler filler filler filler fil
-abcd
\textbf{-{}eve}. It may also be written as foo-{}fa in
informal writing, as that is how it is pronounced.
blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa
blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa
blaa blaa blaa blaa blaa blaa blaa blaa blaa blaa.
\end{document}
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi, math, and amstext
On 9/27/2014 12:24 AM, Vafa Khalighi wrote:
Well, I suppose you do not use low-level commands like \RL to typeset say
Arabic. Do you?
We have been; perhaps relevant is the fact that we're typesetting small amounts
of text in various right-to-left scripts in the middle of a bunch of
left-to-right text (a grammar).
One usually defines an environment like:
\newfontfamily\arabicfont[ExternalLocation,Script=Arabic]{amiri-regular}
\newenvironment{arabtext}{\begin{RTL}\@Latinfalse\arabicfont}{\end{RTL}
or if you are defining commands:
\newcommand*{\textarab}[1]{\RL{\@Latinfalse\arabicfont #1}}
Ok, tried that; it (and also my original attempt at redefining \RL) fails for
some reason in captions. The minimal example is
---
\documentclass{report}
\usepackage{fontspec}
\newfontfamily\ArabicFont[Script=Arabic]{Scheherazade}
\usepackage{bidi}
\makeatletter
\@Latintrue
\newcommand*{\ArabicScript}[1]{\RL{\@Latinfalse\ArabicFont #1}}
\makeatother
\begin{document}
\begin{table}
\caption{{\ArabicScript{دن}}}
\end{table}
\end{document}
---
The error msg is
! Incomplete \iffalse; all text was ignored after line 15.
inserted text
\fi
* RLBug.xetex
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi, math, and amstext
On 9/27/2014 4:20 PM, Zdenek Wagner wrote: Your definition is fragile but a robust macro is needed inside \caption. Use \DeclareRobustCommand instead of \newcommand, the syntax is the same. Ah, thanks, I'll try that! -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] bidi, math, and amstext
Not sure if this is the appropriate place to say this, but: I seem to
have found a problematic interaction (aka bug?) between the bidi package
and the amstext package.
Here's a minimal example:
\documentclass{report}
\usepackage{fontspec}
\usepackage{biblatex}
\usepackage{amstext}
\usepackage{bidi}
\begin{document}
V $_{\text{[high, low]}}$
\end{document}
--
I would of course expect the words high and low to come out in that
order in the PDF. Instead, they come out in reverse order, something
like
low] [high,
If I leave out the fontspec package in the above code, the resulting
output is even stranger:
]wol ,hgih[
I'm not sure why it's necessary to load the biblatex package in the
above, but if I don't then xelatex complains:
! Undefined control sequence.
l.3 \abx@aux@sortscheme
{nty}
Mike Maxwell
University of Maryland
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bidi, math, and amstext
On 2014-09-26 16:01, Vafa Khalighi wrote:
Not a bug. bidi package has a boolean \if@Latin. The boolean should be
set
in higher level packages (like polyglossia) to true for non-RTL scripts
and
false for RTL scripts. Its initial value is false so that explains the
behaviour.
Since we're not using polyglossia, should we be setting this variable
ourselves? I just now tried doing that:
\makeatletter
\@Latintrue
\makeatother
and it seems to work. However, I'm not sure how, without using
Polyglossia, we should do this whenever we switch languages. We never
had to do that for other purposes--we just use
{\RL{some right-to-left stuff}}
I guess we need to redefine \RL to be s.t. like this:
\makeatletter
\let\origRL\RL
\renewcommand{\RL}[1]{\makeatletter\@Latinfalse\makeatother{\origRL{#1}}\makeatletter\@Latintrue\makeatother}
\makeatother
Right? I tested this on a small example and it seems to work... (email
is wrapping the \renewcommand here)
Note: I did not need to load biblatex package unlike you.
Figured that out--it was due to some old .aux file or s.t. that I had
laying around as I was minimizing the example.
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [arXiv #128410] Re: XeLaTeX generated pdf metadata
On 2014-09-22 22:04, Axel E. Retif wrote: On 09/22/2014 08:42 PM, Mike Maxwell wrote: I guess these jokers haven't heard of Unicode. Are they stuck back in the 1990s? Are you and Philip Taylor even aware that you're replying directly to an arXiv administrator? I think arXiv and Cornell University are doing a great service to the scientific community and public in general and deserve more respect. For the record, I was on the other side of this issue in the early 2000s, and was told I should move into the 21st century. The person who told me that was right, and I was wrong. Having been converted, I feel the need to proselytize; apologies, though, for coming across as brash. I'm a linguist, so I constantly deal with other scripts. Unicode is essential for our work, and its use has been routine in linguistics and computational linguistics publications and data archiving for over a decade. All the language archiving sites I know about will accept *only* Unicode (or at the very least discourage non-Unicode submissions). So no, I don't understand why an archiving service would not allow Unicode-encoded papers, even if it does require xelatex. (For the record, I think the font is a red herring, since afaik the font license issue comes up regardless of whether you're using latex or xelatex.) Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [arXiv #128410] Re: XeLaTeX generated pdf metadata
On 9/22/2014 9:41 AM, arXiv Help wrote: Dear Chandra, arXiv does not support XeTeX/XeLaTeX. Please export the source to the appropriate *.tex file format and submit that file. arXiv does not currently have any plans to support XeTeX/XeLaTeX. Please make the necessary changes and attempt to reprocess your submission at your convenience. -- arXiv admin I guess these jokers haven't heard of Unicode. Are they stuck back in the 1990s? Mike Maxwell University of Maryland -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] font license
On 2014-09-03 17:44, Jonathan Kew wrote: Sounds like it'd be worth filing a bug report on this, as it certainly looks like incorrect behavior. Perhaps Jiang or Khaled would have time to track down exactly what's happening here. Thanks, I've done this (Khaled of course already knows about the problem), including a test file, and mentioning your suggestion: Maybe it's getting confused because Nikosh has the (relatively rare, I think) No subsetting flag set there? BTW, this issue happens when an explicit xdvipdfmx command is used--either on the command line (after xelatex was run with the -no-pdf parameter), or as an -output-driver option on xelatex. For some reason, the issue does not happen when xelatex is called on the input file and produces an output PDF--the font is embedded. Does that mean that xelatex by default ignores font licensing restrictions? (The resulting PDF does subset the font, which is probably not the correct result if the no subsetting restriction in the font is taken at face value.) Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] rangecheck in --run--
On 2014-08-27 18:49, maxwell wrote: On 2014-08-27 18:16, Jonathan Kew wrote: I'm curious why Ghostscript is being run at all. Is it trying to convert a PostScript or EPS graphic, when you intended to use a PDF directly? Maybe one of the users has a different version of the graphics package, or even just a configuration file, in a personal location? Does one of the users have a pre-converted .pdf version of the graphic, but the other only has access to an .eps original? I think I've figured this out. We embed a few PDF images in our documents. We had had a similar crash problem earlier when embedding newer versions of PDFs (v1.6)--apparently xdvipdfmx prefers older versions of PDFs. (PDF v1.6 corresponds to Adobe v7, and I think the xdvipdfmx.cfg file specifies v5 = v1.4. But I haven't studied that .cfg file.) With advice from people here (see this thread: http://tug.org/pipermail/xetex/2010-August/017806.html), we had overcome the problem by specifying to xdvipdfmx that it use a newer version of ghostscript (9.06 instead of 8.71) on the final pass (where it builds a PDF), and specifying the '-no-pdf' parameter on the earlier passes. However, I had put this latter parameter on the wrong side of the input file name, i.e. xelatex foo.tex -no-pdf instead of xelatex -no-pdf foo.tex so it was still trying to build a PDF in the earlier passes using the default version of ghostscript. And apparently the default ghostscript was different on the other user's machine from mine, causing the crash. Moral of the story: command line parameters go *before* the input file. Duh. Thanks for the help in tracking this down! Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] font license
On to the next problem. We're typesetting a Bangla grammar, and the chosen font for the Bengali script is the Nikosh font. This ttf font was reportedly developed by the government of Bangladesh, and is freely downloadable from their website, e.g. http://www.bpdb.gov.bd/bpdb/index.php?option=com_contentview=articleid=239 http://www.ecs.gov.bd/English/QLTemplate1.php?Parameter_QLSCat_ID=68ByDate=0Year= Now that I have the xetex -output-driver parameter on the correct side of the input file name on the command line (see my previous thread...), xdvipdfmx is refusing to embed this Nikosh font in the PDF unless I use the -E (embed regardless of license) parameter. I'm not happy about doing that. I have been googling around for the Nikosh font license (no luck--some sites claim it's freely available, but that probably doesn't mean anything), and also for some app that would let me read the license restrictions which I assume are embedded somehow in the .ttf file (otherwise how could xdvipdfmx find it?). Tried fc-scan, FontForge, 'strings Nikosh.ttf | grep -i fstype', etc. I understand that some font creation tools default to non-embeddable font licenses, and that some developers may not realize that (or not realize the implications). How do I find the exact license restrictions on a truetype font? Mike Maxwell University of Maryland -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] font license
On 2014-09-03 15:42, Lorna Evans wrote: The font properties say Installable embedding allowed so I'm not sure why it won't embed. The license field has a bunch of CJK that I can't read and then this: Nikosh font developed by The Election Commission of Bangladesh. Latin glyphs ... That's certainly the sort of thing I was looking for. How did you extract that? (and from what file?) Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] font license
On 2014-09-03 17:04, Zdenek Wagner wrote: 2014-09-03 22:46 GMT+02:00 Lorna Evans lorna_ev...@sil.org: ...I don't know how you would find this info on other Operating Systems. Maybe fontforge? I have it open in FontForge now. I would think the appropriate place to look would be the Element | Font info command, which brings up a Font Information dialog. Under TTF Names, there are a number of fields, including one labeled License, which is the Creative License v3 (as Lorna saw). But I don't see a field labeled Embeddability (or similar), but then I don't see that field in the Scheherazade font either, and xdvipdfmx treats that as embeddable. So I'm not sure in FontForge how to get at the embeddability information that xdvipdfmx (and Microsoft's font info plugin) is using. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] font license
On 2014-09-03 17:25, Stefan Solbrig wrote: 2014-09-03 22:46 GMT+02:00 Lorna Evans lorna_ev...@sil.org: It came from the Nikosh.ttf file. I have Microsoft Font Properties Extension installed and with that installed I can right click on a .ttf and select Properties and it gives me a whole range of tabs full of info that were not available without the extension. I don't know how you would find this info on other Operating Systems. Maybe fontforge? Yes, fontforge can do this. Open the font file with fontforge, then select Elements-Font info. thanks, I see that now, but how do you find the embeddability info that xdvipdfmx is seeing? I guess it's coded as a single bit, but is there a way to read it in FontForge? (As a quick hack, if you don't want to install fontforge, the License is usually also contained as an utf-8 string. So just doing a dump e.g. with: hexdump -C path/to/font/file | less or using a hex capable edtior: vim -b path/to/font/file will make it easy to find the license (usually at the beginning if the font file. It might also be stored as an utf-16 string, which makes it a bit harder to read. The license is encoded both as UTF-8 and as UTF-16; at a guess, the latter is what Lorna reported in the Windows app (and what I also see in FontForge) as looking like a Chinese license! Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] rangecheck in --run--
One of our people is getting a crash in xetex, which I can't reproduce.
It's very odd, since afaik we're both using the same input files, the
same instance of xetex, the same TeXLive 2014 files, and so forth, and
running on the same machine. Clearly s.t. is different, but I'm not
sure what, and this email is a query about what I should be looking for.
The error msg is:
--
Error: /rangecheck in --run--
Operand stack:
--dict:11/20(L)-- TT0 1 FontObject --dict:8/8(L)--
--dict:8/8(L)-- TimesNewRomanPSMT --dict:13/13(L)-- Times-Roman
Times-Roman
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostringval-- false 1 %stopped_push 1862 1 3
%oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop
--nostringval-- --nostringval-- 2 1 1 --nostringval--
%for_pos_int_continue --nostringval-- --nostringval-- false 1
%stopped_push --nostringval-- --nostringval--
Dictionary stack:
--dict:1155/1684(ro)(G)-- --dict:1/20(G)-- --dict:76/200(L)--
--dict:76/200(L)-- --dict:106/127(ro)(G)-- --dict:286/300(ro)(G)--
--dict:22/25(L)-- --dict:4/6(L)-- --dict:26/40(L)--
Current allocation mode is local
Command /groups/tools/texlive/2014/bin/x86_64-linux/xelatex
-halt-on-error -output-directory=./LinguistInABox/output/latex
./LinguistInABox/output/latex/linguistInABoxGrammar.xetex -no-pdf died
with signal 13, without coredump
Signal 13 is Write on a pipe with no reader, Broken pipe.
I believe the crash is happening at the point xelatex is trying to embed
an existing PDF. If I'm right (we're going to verify it tomorrow), the
command that crashes is
--
\imgexists{list_intonation.pdf}{{\imgevalsize{list_intonation.pdf}{\includegraphics[width=\imgwidth,height=\imgheight,keepaspectratio=true]{list_intonation.pdf{}
-
Googling this:
xetex OR xelatex rangecheck in --run--
brings up about six msgs from 2011, which seem to be the same thread,
and afaict are irrelevant.
We're running the version of xetex that came with TeXLive 2014
(3.14159265-2.6-0.1) on Linux.
Any suggestions as to what I should be looking for?
Mike Maxwell
University of Maryland
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] rangecheck in --run--
On 2014-08-27 17:51, Ross Moore wrote:
The problem looks to be with Ghostscript.
You may be using different versions, so check that first.
Thanks! (and to Zdenek for the similar suggestion)
That certainly makes sense. We do have two versions of ghostscript on
our linux machine, 8.70 and 9.06. I don't know if this--
http://bugs.ghostscript.com/show_bug.cgi?id=692177
is the particular error we're getting, but it seems plausible. It was
fixed in v9.04. I'm not sure why the other user's account calls the old
version and mine the newer ('which gs' on my machine returns a v8.71,
and 'which ghostscript' returns v8.70); but at least we have s.t. to
look at.
But--how did you figure this out? I see no mention of
Ghostscript/Postscript in the error msg.
Mike Maxwell
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] rangecheck in --run--
On 2014-08-27 18:16, Jonathan Kew wrote: I'm curious why Ghostscript is being run at all. Is it trying to convert a PostScript or EPS graphic, when you intended to use a PDF directly? Maybe one of the users has a different version of the graphics package, or even just a configuration file, in a personal location? Does one of the users have a pre-converted .pdf version of the graphic, but the other only has access to an .eps original? We do have a -D flag on the xdvipdfmx command line, which points to v9.06 of ghostscript. But that's the same for both this other user and me (it's run from a script). And I presume it's irrelevant to this error, since the crash happens when xelatex is running, not (unless I'm misunderstanding how this works) when xdvipdfmx runs. So under what circumstances would xelatex (not xdvipdfmx) be calling ghostscript? Maybe one of the users has a different version of the graphics package, or even just a configuration file, in a personal location? That seems the most likely explanation, although how that results in ghostscript getting called, I don't know. In the past we have used pdf2ps and ps2pdf (script which call gs) to convert some problematic versions of pdfs into acceptable versions. But that's s.t. we do once, off-line, and we simply retain the acceptable pdfs. So I don't think that's what's going on here. Does one of the users have a pre-converted .pdf version of the graphic, but the other only has access to an .eps original? I don't think so, but I'll certainly check when this other user gets back (Wednesday). Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On 2014-08-04 13:50, Stefan Solbrig wrote: The following two commands will set all resolution metadata known to exiftool to 300. exiftool -'*Resolution'=300 image.jpg I haven't done a thorough testing of this tool, but for OP's image, it worked. (The command might need some refinement, depending on your needs.) This worked, actual command line was exiftool -XResolution=72 -YResolution=72 fname.jpg Thanks! (One file gave an error when we tried to do this, Error reading StripOffsets data in IFD0. That appears to be an(other) error in the file, a jpg apparently should not have a StripOffsets tag.) Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
Turns out we've also been bit by this problem... please see my questions below. On 2014-08-04 01:55, Heiko Oberdiek wrote: On 04.08.2014 01:27, Gildas Hamel wrote: I append the jpg file (tombe.jpg). The resolution data in tombe.jpg are inconsistent: * JFIF header: 72 DPI * EXIF header: 300 DPI What program did you use to determine this? I'm looking at one of our jpgs in a text editor, and while I see the string Exif near the top, I don't see any jfif-like string. GIMP reports 72x72 ppi, but I don't know whether that's exif or jfif. Apparently XeTeX uses the EXIF header, whereas xdvipdfmx the JFIF header (or vice versa). Is there a work-around? Like using some image editor to produce a jpg file with jfif and exif headers that agree on the resolution (and I suppose have the correct one :-)), or maybe converting from jpg to some other format? I suppose I could create a PDF using pdflatex, and import that into my xetex file instead of the original jpg. But before I try all these things, it would be nice to know if someone else has found a work-around... Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
Mike Maxwell (me) wrote: I'm looking at one of our jpgs in a text editor, and while I see the string Exif near the top, I don't see any jfif-like string. Stefan Solbrig wrote: You can find 'JFIF' of tombe.jpg at position 6, meaning, there are six other bytes before the string. OK, I can see that 'JFIF' in the tombe.jpg file. But it turns out it's not in my file at all, only the 'Exif' header is there. Our sysadmin guys haven't installed the suggested exiftool tool yet; presumably exiftool will be capable of *adding* the JFIF header (which I gather should come before the Exif header, although apparently both headers want to be first). Turns out GIMP will also save it with both the JFIF and Exif headers, and that works with XeTeX, and has a batch method. So I guess I could use that. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] bidi question
I have encountered what appears to be a very minor bug in the 2013
version of the bidi package. The sourceforge page for bidi
(http://bidi.sourceforge.net/) appears to have been recently set up, and
as a result the links to source code are not there yet--in particular,
the method for reporting bugs is not there. But I installed the 2014
version from http://www.ctan.org/tex-archive/macros/latex/contrib/bidi,
and I get the same output (and verified that xelatex is using the newer
file).
I'm attaching the minimal file below. The PDF output has a blank line
between the first and second footnotes, which IMO shouldn't be there. I
don't get this result if bidi isn't loaded, and with bidi loaded I only
get this result if the last line of the first footnote ends right at the
right-hand margin (and TeX doesn't think it can improve the result by
wrapping onto the next line--hence the rather long final word in the
minimal example's footnote).
I also only get this result if the close brace of the first footnote is
on the line following the last word of the footnote, that is, if I have
word word word.
}
rather than
word word word.}
So it's a very minor problem, and easy enough to work around. My
problem with the work-around is that the LaTeX code is generated from
XML, and avoiding that line break before the brace is difficult.
Anywhere, here is the minimal example:
--
\documentclass{report}
\usepackage{bidi}
\begin{document}
Refer to first footnote\footnote{
Fill fill fill fill fill fill fill fill fill fill
fill fill fill fill fill fill fill fill fill fill
fill fill fill fill fill fill fill fill fill fill
fill fill fill fill fill fill fill fill fill fill
fill fill fill fill fill fill fill fill fill fill
fill fill fill fillfillfillfi.
} refer to second footnote.\footnote{Another footnote.}
\end{document}
--
Mike Maxwell
University of Maryland
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] morewrites and bibtex
Coming back to this (see below) after over a year, to report that it is no longer an issue for us. I never did get around to uploading the latest version of morewrites (suggested by Bruno below), but I did install the next texlive when it came out, which has the newer version (0.2e) of morewrites than the one I had been using. That may have fixed the problem, but we also switched from bibtex to biblatex (the problem I originally reported was some kind of an issue between bibtex and (the older version of) morewrites). So we're not using the same configuration that we were when we had the problem. Thanks to Bruno for this package, and for responding to my original msg. Mike Maxwell On 2013-02-09 14:34, Mike Maxwell wrote: On 2/9/2013 6:29 AM, Bruno Le Floch wrote: I'm the author of morewrites, which has to perform various hacks to go around the hard limitation of the number of TeX output streams (see the thread that you linked: TeX has not changed in this regard). My guess is that it is probably a bug in morewrites. Please try to make a reasonably short example, and send it, for instance to me. Thanks, will do, after I try this: Do you have the latest version of morewrites (v0.2e)? No, it appears I'm using v0.1, dated 2011/09/09, which came with TexLive 2012. I see where I can download the newer version on ctan.org, so I'll give that a shot before I try making the minimal example. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] embedding PDF, 1.4 vs. 1.5
Late last year, I ran into a problem in which I could embed a PDF v1.4, but not v1.5 (I have not tried this with newer versions of PDFs, which are now up to 1.7). The problem and its work-around are described here: http://tug.org/mailman/htdig/xetex/2012-October/023677.html also http://tug.org/pipermail/xetex/2012-December/023869.html and in the preceding and following messages in those threads. The problem bit us again today. Fortunately, we now know the work-around. But my question is whether this is likely to get fixed in some future version of xetex? (We're using the TeXLive 2013 version = 3.1415926-2.5-0..3-2013060708.) Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] embedding PDF, 1.4 vs. 1.5
On 2014-06-17 11:31, maxwell wrote: Late last year, I ran into a problem in which I could embed a PDF v1.4, but not v1.5 (I have not tried this with newer versions of PDFs, which are now up to 1.7). The problem and its work-around are described here: http://tug.org/mailman/htdig/xetex/2012-October/023677.html also http://tug.org/pipermail/xetex/2012-December/023869.html The above work around involved a double conversion using pdf2ps, from PDF to PS and back again to PDF. If you happen to own a copy of Adobe Acrobat, Chris Green ran into another way to do it, documented here: http://grok.lsu.edu/Article.aspx?articleId=9869 I don't know whether there are quality differences using these two routes. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] stacking diacritics without mark-to-mark
On 2014-03-12 14:47, Joshua and Amy wrote: I'm typesetting with XeLaTeX, using fontspec, and calling a font provided to me by the publisher of a manuscript I'm working on. (Same as my previous post!) The language I work with has a letter O with circumflex and breve (U+00F4,U+0306): ô̆. However, the publisher-provided font does not use mark-to-mark positioning, so when I typeset in XeLaTeX, the combining breve overlays the circumflex. Back in January of 2013, there was discussion of this very issue, which included talk of a potentially forthcoming solution where XeTeX would handle this problem for us. Does anyone know whether there is now a straightforward way of doing this? I'm the one who started the thread a year ago, and I'm very definitely interested in this problem. The post saying that this problem would soon be fixed is this one: http://tug.org/pipermail/xetex/2013-January/024031.html namely ...next XeTeX (thanks the new HarfBuzz layout engine), will try to position the accents using their bounding boxes if the font does not have a GPOS table, so it should produce better results in this case (unless the font in question does have a GPOS table). Regards, Khaled Afaict, this does not work under the TeXLive 2013 version, at least not with this publisher's font. Am I missing s.t.? Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] stacking diacritics without mark-to-mark
On 3/12/2014 10:19 PM, Andrew Cunningham wrote: Although personaly I'd consider such a solution a poor hack compared to a well designed font that is fit for purpose. I won't disagree. We've been told by the publisher, who original built the font (or more likely subcontracted it) that the problem is a shortcoming of their OpenType font files, that could only be eliminated by revising the font as a whole. I'm inclined to tell them to go for it, or else we'll use a font that does work (Charis SIL comes to mind). That would have the unfortunate consequence that the first book in our series would use the publisher's font (we didn't have the stacked diacritic problem in that book), but the rest of the books in the series would use some other font. But in order to convince them to make such a change, I need to understand better what is involved in revising a font to make mark-to-mark positioning work. I gather that only the diacritics need the two mark-to-mark points (top and bottom) to be defined, not every character--correct? Is it done at the character level, or at the glyph level? Does it need to be done separately for each point size/ weight/ style that the font supports? And do those attachment points need to be defined manually, or is there a way to automate that process? Can this be done in a tool like FontForge, or does one need specialized tools that only the font manufacturer would have? I'm assuming that base characters already have top and bottom marks, but that may not be a safe assumption. The problems we've seen so far have been with stacked diacritics. And of course there may be a better forum than this to ask this question. -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] FreeSerif fonts and devanagari ligatures
On 3/10/2014 8:04 PM, Khaled Hosny wrote: That being said, there are some bugs in the HarfBuzz version used in TeX Live 2013 release, but this should be fixed when with 2014 upgrades to the latest HarfBuzz (people using exiting XeTeX release with the latest HarfBuzz, e.g. distro packages, should be fine as well). We'll be typesetting some Bangla (Bengali script) text in June, which afaik is before the TeXLive 2014 comes out. 1) Do you happen to know whether the 2013 version's bugs break Bangla? I suppose that's an unanswerable question, since it probably depends on the exact font we'll be using, and maybe the 2013 version hasn't been tested with Bangla anyway. So: 2) I assume this: http://www.freedesktop.org/wiki/Software/HarfBuzz/ is where I should go for the latest HarfBuzz (at the moment, the 30 Jan 2014 release), correct? And that I don't need to install any revised version of anything else from TeXLive 2013. -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] BibLaTeX/ biber question
On 2/10/2014 12:28 AM, I wrote:
I'm switching over from BibTeX to BibLaTeX/ biber. I have most things working,
but I have one
question. We occasionally use the command \btPrintAll from the bibtopic
package; this command
added all citations from a given .bib file to the bibliography, even if a work
was not cited in
the main document. But bibtopic is not compatible with BibLaTeX, and I don't
see any obvious
mechanism in BibLaTeX (or biber) for doing what \btPrintAll did. I checked
both the biber
documentation and the biblatex documentation.
Am I overlooking something?
After looking for this for several hours, I gave up and started working on s.t. else. And found
what I wasn't looking for.
For the record, I think:
\nocite{*}
does what I want.
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
On 2013-12-09 11:15, Zdenek Wagner wrote: A bit off topic, dou you know a good Linux text editor woth properly implemented bidi algorithm so that I could type multilingual texts? Yudit (http://www.yudit.org/) claims to be that. I have not used it. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] openType and xetex
On 2013-12-03 16:43, Khaled Hosny wrote: http://tug.org/pipermail/xetex/2013-March/024118.html Is there an explanation of xetex's version numbering somewhere? The copy I'm running gives the ff. version #: XeTeX 3.1415926-2.5-0..3-2013060708 (TeX Live 2013) You'll perhaps pardon me if I don't understand that... I mean this http://tug.org/pipermail/xetex/2007-March/006057.html is one thing, but what is the relative meaning of 3.1415926 (I recognize this number, but?) 2.5(?) 0..3 (third, er fourth release of 0.) 2013060708 (date) Anyway, if the 0..3 part is any indication, xetex is now using Harfbuzz, correct? Mike Maxwell The gentle giants of Harfang salute you. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] openType and xetex
On 2013-12-03 17:27, maxwell wrote: Anyway, if the 0..3 part is any indication, xetex is now using Harfbuzz, correct? Aargh, just noticed that the version information already says this. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problems in Devanagari typing.
I'm having trouble understanding this: Am 24.11.2013 um 17:27 schrieb Khaled Hosny: ...The problem I had with Malayalam (Rachana Font) has been fixed after I updated it. The it that got fixed = the font or XeTeX? However TexShop does have problem with certain ligatures when it comes to Malayalam. However, the pdf renders the ligature correctly. I'm not understanding: are you saying that the screen view of TexShop is at fault, or the PDF produced by XeTeX when you use TeXShop? Mr Venkataraman is facing a similar problem. Font. As we have seen the problem is with ligatures. Perhaps you could be more specific? -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-hyphen] Hyphenation of polytonic Greek (expressed in Unicode)
On 9/12/2013 6:17 PM, Khaled Hosny wrote: Some writing systems do not use spaces to separate words, so TeX’s normal line breaking algorithm will fail. \XeTeXlinebreaklocale instructs XeTeX to break the lines based on the rule of those writing systems. ‹Locale ID› should be the ISO code of the language in question, Hmm, wouldn't this be insufficient information? Some languages are written in multiple scripts, and I would not be surprised if word breaks are signaled differently in those different scripts. Japanese, for example? documentation is a bit vague, but it seems to calculate the line breaking position based on the Unicode character properties and the locale value is simply ignored). That also seems insufficient, since multiple languages may use the same script and have different word (and therefore line) breaking characteristics. Although perhaps closer, given that scripts that don't use spaces are *perhaps* more unique to a particular language, or to a small set of similar languages--e.g. Chinese script, to the extent that Cantonese and Mandarin are similar in their word break characteristics. But here I'm *really* ignorant. In general, word breaking in scripts that don't indicate word boundaries is a partly unsolved research problem in computational linguistics--and from what I've heard, native speakers often disagree. (If you think that's odd, you might consider 'doghouse' vs. 'dog house' in English...) So I suppose it's not surprising if this doesn't work as well in XeTeX as one might hope. -- Mike Maxwell The biggest danger is not ignorance, but the illusion of knowledge. --Stephen Hawking -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bold small caps, but no regular small caps
On 2013-08-02 06:40, Georg Duffner wrote: I tried to reproduce the above behaviour by deleting and adding different versions – without success. In my case (I'm the OP), the problem indeed turned out to be with my font files--I had two versions of the CharisSIL font files, with slightly different names. Apparently it (Cygwin, and therefore XeLaTeX) was picking up the older ones, which were known to have issues with small caps. I imagine this problem could occur in other OSs, since the font file naming issue would affect those systems too. Now, if I extend Mike’s original example by italics (see below), things get weirder: I haven't tried this on my Windows/Cygwin machine yet (I'm on another machine now). Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bold small caps, but no regular small caps
On 7/29/2013 7:47 AM, Herbert Schulz wrote:
This has been explained before on this list. Use the [Renderer=ICU] option:
\setmainfont[Renderer=ICU]{Charis SIL}
and you'll get Small Caps.
This doesn't work. Still only small caps on the bold, not regular. I also tried Renderer=OT, but
xelatex reports
! LaTeX error: kernel/key-choice-unknown
!
! Key 'fontspec-renderer/Renderer' accepts only a fixed set of choices.
---
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] bold small caps, but no regular small caps
On 7/29/2013 10:06 AM, Elliott Roper wrote:
Try this
\setmainfont[Mapping=tex-text,Renderer=ICU]{Charis SIL}
No, afraid that doesn't work either.
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] morewrites and bibtex
On 2/9/2013 6:29 AM, Bruno Le Floch wrote: I'm the author of morewrites, which has to perform various hacks to go around the hard limitation of the number of TeX output streams (see the thread that you linked: TeX has not changed in this regard). My guess is that it is probably a bug in morewrites. Please try to make a reasonably short example, and send it, for instance to me. Thanks, will do, after I try this: Do you have the latest version of morewrites (v0.2e)? No, it appears I'm using v0.1, dated 2011/09/09, which came with TexLive 2012. I see where I can download the newer version on ctan.org, so I'll give that a shot before I try making the minimal example. Thanks! -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] morewrites and bibtex
Has anyone noticed a conflict between the 'morewrites' package and bibtex? It appears that there is some sort of problem whereby the fname1.aux file that bibtex creates gets overwritten (as a zero-length file) when I load the morewrites package and run xelatex after bibtex. The result is of course an empty bibliography. I have a small file that shows this effect, but it would take quite a bit more work to make it minimal. I also don't know if this has anything to do with xe(la)tex, or if it's just between morewrites and bibtex; I tried running it with LaTeX, but ran into some obscure problems. So my question is whether this is a known problem, or if I should pursue creating a minimal example so that someone can fix it (assuming it's a bug). (Googling didn't reveal anything obvious.) I'm using TeXLive 2012, so I don't think this thread: http://www.tug.org/pipermail/xetex/2011-December/022463.html is relevant. Mike Maxwell -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] redefining Unicode characters
On 1/15/2013 12:58 AM, Khaled Hosny wrote: BTW, next XeTeX (thanks the new HarfBuzz layout engine), will try to position the accents using their bounding boxes if the font does not have a GPOS table, so it should produce better results in this case (unless the font in question does have a GPOS table). Wow, I'm impressed! When will this new XeTeX be coming out? Do I need to wait for TeXLive 2013? -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] redefining Unicode characters
We are typesetting a grammar that has instances of 'a' + combining macron + combining acute. The
publisher requires us to use a font that does not produce stacked diacritics well (the acute accent
overwrites the macron, rather than appearing above it).
The publisher's solution in this font (which won't work in every case, but will for this particular
sequence) is to replace the sequence 'a' + combining macron + combining acute with a single
pre-composed character in the Private Use Area of Unicode.
There are several ways we could do this. One would be to convert all the sequences in our document
once and for all; but that has the disadvantage that the characters will show up as boxes in the
source code (we aren't using and don't particularly want to use the publisher's font in our editor,
for reasons I won't go into). It has the further disadvantage that if anyone later on adds another
instance of this sequence, we may forget to convert it (and XeLaTeX will not produce an error, just
a bad looking output).
Another way would be to insert a pre-processing step that uses a stream editor (like sed) to convert
the sequence to the PUA character. Clumsy, but perhaps preferable to the first method.
My preference would be if it were possible for XeLaTeX itself to do the conversion. Note that I do
not want to create a command (prefixed by a \ and using {}, I suppose) to do this; that would be
almost as bad as the first method. Is there any way to tell XeLaTeX to map a particular sequence of
Unicode code points to a different code point? I didn't see anything obvious in the fontspec manual.
I'm assuming there's no straightforward way to tell XeTeX to place an acute slightly higher when it
immediately follows a macron. Such a solution would solve problems that will arise later when we
have other sequences of stacked diacritics, which are not given pre-composed forms in the
publisher's font.
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex and tikzpicture
On 12/31/2012 3:02 PM, msk...@ansuz.sooke.bc.ca wrote:
On Mon, 31 Dec 2012, Mike Maxwell wrote:
Dia will also output a .tex file, which uses the tikz package. I tried this,
using \input{filename.tex} in my xelatex file (along with the
\usepackage{tikz} and \usepackage{morewrites}). I get approximately half a
bazillion warnings from xelatex, and while it outputs a PDF, the diagram does
not appear (there's a mostly blank page).
I use TikZ with XeLaTeX all the time and I've never had problems such as
you describe. It would be interesting to see one of the .tex files that
doesn't work.
Turned out that the problem was that I needed the ff. commands before the
\usepackage{tikz} command:
\def\pgfsysdriver{pgfsys-xetex.def}
\usepackage{pgf}
This was not very obvious to me...
I still need to do some scaling, but I think that will be straightforward.
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex and tikzpicture
To finish up this thread: On 12/31/2012 3:44 PM, msk...@ansuz.sooke.bc.ca wrote: On Mon, 31 Dec 2012, Mike Maxwell wrote: Why are you using morewrites? Because it was running out of places to write to (there's a limit of 16 files, I understand) without morewrites. This seems surprising. Are you generating a lot of different lists, table-of-contents kinds of things, indices, and so on? Yes: table of contents, table of figures, table of tables, index, and a bunch of other stuff. -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] xelatex and tikzpicture
I've created some diagrams using the free tool 'dia' (an open source diagramming tool). In the
past, I've exported its diagrams as jpegs, and imported them into my Xelatex file as such. That's
probably not the optimal way to do it.
Dia will also output a .tex file, which uses the tikz package. I tried this, using
\input{filename.tex} in my xelatex file (along with the \usepackage{tikz} and
\usepackage{morewrites}). I get approximately half a bazillion warnings from xelatex, and while it
outputs a PDF, the diagram does not appear (there's a mostly blank page).
Here's a subset of the warnings from xelatex:
--
** WARNING ** Unknown token pgfs
** WARNING ** Interpreting PS code failed!!! Output might be broken!!!
** WARNING ** Interpreting special command ps: (ps:) failed.
** WARNING ** at page=67 position=(-4876.72, -16639.2) (in PDF)
** WARNING ** xxx ps:: pgfs
** WARNING ** Stack not empty after execution of inline PostScript code.
** WARNING ** Your macro package makes some assumption on internal behaviour
of DVI drivers.
** WARNING ** It may not compatible with dvipdfmx.
** WARNING ** Unknown token pgfr
** WARNING ** Interpreting PS code failed!!! Output might be broken!!!
** WARNING ** Interpreting special command ps: (ps:) failed.
** WARNING ** at page=67 position=(-4876.72, -16639.2) (in PDF)
** WARNING ** xxx ps:: pgfr
** WARNING ** Unknown token restore
---
I'm guessing the problem is summarized by the warning:
Your macro package makes some assumption on internal behaviour of DVI
drivers.
Is there something I should be doing to make this work with xelatex/ dvipdfmx? Or is it not
possible? (If .tex is not possible, and I'm understanding correctly, I suppose the .png format
would be better than .jpg.)
I'm using the latest TexLive 2012 version (XeTeX 3.1415926-2.4-0.9998).
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xelatex and tikzpicture
On Mon, 31 Dec 2012, Mike Maxwell wrote:
Dia will also output a .tex file, which uses the tikz package. I tried this,
using \input{filename.tex} in my xelatex file (along with the
\usepackage{tikz} and \usepackage{morewrites}). I get approximately half a
bazillion warnings from xelatex, and while it outputs a PDF, the diagram does
not appear (there's a mostly blank page).
I use TikZ with XeLaTeX all the time and I've never had problems such as
you describe. It would be interesting to see one of the .tex files that
doesn't work.
Ok, let me make a minimal example. (May not get to it today...)
Why are you using morewrites?
Because it was running out of places to write to (there's a limit of 16 files, I understand) without
morewrites.
--
Mike Maxwell
maxw...@umiacs.umd.edu
My definition of an interesting universe is
one that has the capacity to study itself.
--Stephen Eastmond
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with includegraphics of pdf file version 1.5 which was fixed when converting to version 1.4
On 10/1/2012 4:57 AM, Jørgen Skancke wrote: This minimal working example ... results in the following errror ** WARNING ** Streams with DecodeParams not supported. ** WARNING ** Cannot parse cross-reference stream. ** WARNING ** Error while parsing PDF file. ** WARNING ** pdf: image inclusion failed for ../nature_format.pdf ... My workaround solution was to use gs to convert the pdf file from version 1.5 to version 1.4 I'm also getting this error, but I can't figure out how to use gs to make the conversion. I see ghostscript's manual here http://www.ghostscript.com/doc/current/Use.htm but don't see any parameter to change the pdf version. What was your command line for the conversion? -- Mike Maxwell maxw...@umiacs.umd.edu My definition of an interesting universe is one that has the capacity to study itself. --Stephen Eastmond -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
