From mmoeinenia at yahoo.com Fri Jan 13 14:13:30 2017 From: mmoeinenia at yahoo.com (mmoeinenia) Date: Fri, 13 Jan 2017 16:43:30 +0330 Subject: [XeTeX] Issue with Arabic Typography Message-ID: ????. ???? ?? ?? ???? ???? ? ???? ?????? ?? ?? ?????? ??????? ???? ????? ?? ?????? ?? ?? ???? ???? ???? ???? ???. ???? ????? ????? ???????? ?? ???? ???? ???? ???? ??? ??? ???.????? ????? ???????? ????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sat Jan 14 15:41:14 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sat, 14 Jan 2017 14:41:14 +0000 Subject: [XeTeX] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory Message-ID: If XeTeX is invoked on file foo.tex specifying --output-directory=../dynamic-content, and if there is also a file ../dynamic-content/foo.tex, then XeTeX will process that file rather than the file which it was instructed to process : > \message {This is the intended foo.tex} > \end > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/./foo.tex This is the unintended foo.tex ) > No pages of output. > Transcript written on ../dynamic-content/foo.log. -- Philip Taylor From zdenek.wagner at gmail.com Sat Jan 14 17:17:50 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Sat, 14 Jan 2017 17:17:50 +0100 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: Message-ID: I have just tried on Linux and found that it depends on the way how the file name is specified, namely whether foo.tex is given including the extension or only foo: $ xetex --output-directory=./dynamic-content foo This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016) (preloaded format=xetex) entering extended mode (./foo.tex [1] ) Output written on ./dynamic-content/foo.pdf (1 page). $ xetex --output-directory=./dynamic-content foo.tex This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016) (preloaded format=xetex) entering extended mode (./dynamic-content/foo.tex [1] ) Output written on ./dynamic-content/foo.pdf (1 page). I have also tried luatex, tex, and pdfcsplain and all of them behave identically. Zden?k Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz 2017-01-14 15:41 GMT+01:00 Philip Taylor : > If XeTeX is invoked on file foo.tex specifying > --output-directory=../dynamic-content, > and if there is also a file ../dynamic-content/foo.tex, then XeTeX will > process that file > rather than the file which it was instructed to process : > > > \message {This is the intended foo.tex} > > \end > > > > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) > (preloaded format=xetex) > > restricted \write18 enabled. > > entering extended mode > > (../dynamic-content/./foo.tex This is the unintended foo.tex ) > > No pages of output. > > Transcript written on ../dynamic-content/foo.log. > > -- > > Philip Taylor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sat Jan 14 18:19:59 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sat, 14 Jan 2017 17:19:59 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: Message-ID: Zden?k Wagner napsal : > I have just tried on Linux and found that it depends on the way how > the file name is specified, namely whether foo.tex is given including > the extension or only foo: Under Windows (7, Ultimate, 64-bit) what appears to matter is the order of parameter v. qualifier; the presence or absence of the file extension appears to matter not : > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content foo > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/./foo.tex This is the unintended foo.tex ) > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content foo.tex > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/./foo.tex This is the unintended foo.tex ) > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome>xetex foo.tex --output-directory=../dynamic-content > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (./foo.tex This is the intended foo.tex ) > No pages of output. > Transcript written on foo.log. > > E:\TeX\Projects\WBH\Welcome>xetex foo --output-directory=../dynamic-content > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (./foo.tex This is the intended foo.tex ) > No pages of output. > Transcript written on foo.log. -- Philip Taylor From d.p.carlisle at gmail.com Sat Jan 14 18:27:24 2017 From: d.p.carlisle at gmail.com (David Carlisle) Date: Sat, 14 Jan 2017 17:27:24 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: Message-ID: Phil, > E:\TeX\Projects\WBH\Welcome>xetex foo --output-directory=../dynamic- content > (./foo.tex This is the intended foo.tex ) isn't that just because the flags after the filename are ignored? Personally I'd just add it to the end of the list of reasons never to use --output-directory, although that list is so long, it's hard to find the end:-) David -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sat Jan 14 18:39:42 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sat, 14 Jan 2017 17:39:42 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: Message-ID: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> David Carlisle wrote: >> E:\TeX\Projects\WBH\Welcome>xetex foo --output-directory=../dynamic-content >> (./foo.tex This is the intended foo.tex ) > > isn't that just because the flags after the filename are ignored? Silently ?! :-( > Personally I'd just add it to the end of the list of reasons never to > use --output-directory, although that list is so long, it's hard to > find the end:-) If (as I do) one uses Dropbox to mirror one's work for security, the last thing one needs is for Dropbox to continually synch one's ephemeral files (.aux, .log, .ind/idx, .pdf, etc), whence my unvarying use of --output-directory via TeXworks configuration options. ** Phil. From d.p.carlisle at gmail.com Sat Jan 14 19:14:09 2017 From: d.p.carlisle at gmail.com (David Carlisle) Date: Sat, 14 Jan 2017 18:14:09 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: On 14 January 2017 at 17:39, Philip Taylor wrote: > > > David Carlisle wrote: > > >> E:\TeX\Projects\WBH\Welcome>xetex foo --output-directory=../dynamic- > content > >> (./foo.tex This is the intended foo.tex ) > > > > isn't that just because the flags after the filename are ignored? > > Silently ?! :-( > try a file without \end[document} (\end for you:-) and type \end to the * prompt you will see that the text such as --output-directory=... after the filename is just typeset so any text on the commandline after the filename is just like text at the end of the file which is silently ignored if the file has \end before that point. > > > Personally I'd just add it to the end of the list of reasons never to > > use --output-directory, although that list is so long, it's hard to > > find the end:-) > > If (as I do) one uses Dropbox to mirror one's work for security, the last > thing one needs is for Dropbox to continually synch one's ephemeral files > (.aux, .log, .ind/idx, .pdf, etc), whence my unvarying use of > --output-directory via TeXworks configuration options. > > ** Phil. > The problem is that if you configure tex to write somewhere strange you have to configure _everything_ (makeindex, bibtex, tex, ... to find the files that have been written: it causes endless confusion and questions on support lists) compared to just (for example) configuring your editor to save a copy to your dropbox backup folder on each save. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sat Jan 14 19:58:16 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sat, 14 Jan 2017 18:58:16 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: David Carlisle wrote: > try a file without \end[document} (\end for you:-) and type \end to the * prompt > you will see that the text such as > --output-directory=... > after the filename is just typeset True -- I had not considered that possibility. > The problem is that if you configure tex to write somewhere strange you have to configure _everything_ > (makeindex, bibtex, tex, ... to find the files that have been written: it causes endless confusion and questions > on support lists) Well, as soon as I started using --output-directory, I adjusted my methodology to automatically search for such files in the appropriate place; it didn't seem to require a great deal of brain- power ... > compared to just (for example) configuring your editor to save a copy to your dropbox > backup folder on each save. I have no idea whether TeXworks can do that, but for me --output-directory is a very useful feature. ** Phil. From wujastyk at gmail.com Sun Jan 15 09:09:13 2017 From: wujastyk at gmail.com (Dominik Wujastyk) Date: Sun, 15 Jan 2017 01:09:13 -0700 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: On 14 January 2017 at 10:39, Philip Taylor wrote: > ?...? > > If (as I do) one uses Dropbox to mirror one's work for security, the last > thing one needs is for Dropbox to continually synch one's ephemeral files > (.aux, .log, .ind/idx, .pdf, etc), whence my unvarying use of > --output-directory via TeXworks configuration options. > > ** Phil. > > ?I routinely work on tex projects in my Dropbox file area. I mean every day, all the time. I've never noticed a problem with Dropbox mirroring my ephemeral files, even the synctex one. I have moderately fast wifi at home and fast ethernet at work; it might be different if the bandwidth was low and slow. The little dropbox icon shows that my files are updated more or less instantly. I honestly have never noticed any overhead. Best, Dominik -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sun Jan 15 10:20:13 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 09:20:13 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: Dominik Wujastyk wrote: > ?I routinely work on tex projects in my Dropbox file area. I mean > every day, all the time. I've never noticed a problem with Dropbox > mirroring my ephemeral files, even the synctex one. I have > moderately fast wifi at home and fast ethernet at work; it might be > different if the bandwidth was low and slow. The little dropbox icon > shows that my files are updated more or less instantly. I honestly > have never noticed any overhead. On a 3Mbps link, Dominik, synching (e.g.,) the Descriptive Catalogue of Greek MSS in the Lambeth Palace Library ties up my link for hours at a time following each compilation. I therefore need to exclude the generated PDF from synchronisation, and as there is no way of which I am aware to send the PDF to anywhere other than the same location as the (relatively trivial) auxiliary files, I send them all to a location for which Dropbox synchronisation is inhibited. But all of this is besides the point : surely o XeTeX --output-directory=../dynamic-content foo (or foo.tex) should compile foo.tex, not ../dynamic-content/foo.tex ** Phil. From P.Taylor at Rhul.Ac.Uk Sun Jan 15 10:26:43 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 09:26:43 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: <0ece07eb-ddae-0815-5556-61087549b302@Rhul.Ac.Uk> Philip Taylor wrote: > But all of this is besides the point : surely > > o XeTeX --output-directory=../dynamic-content foo (or foo.tex) > > should compile foo.tex, not ../dynamic-content/foo.tex Note that this occurs even if a specific path to "foo.tex" is given : > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content ./foo > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/./foo.tex This is the unintended foo.tex) > *\end > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content ./foo.tex > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/./foo.tex This is the unintended foo.tex) > *\end > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome> From zdenek.wagner at gmail.com Sun Jan 15 10:40:49 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Sun, 15 Jan 2017 10:40:49 +0100 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <0ece07eb-ddae-0815-5556-61087549b302@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <0ece07eb-ddae-0815-5556-61087549b302@Rhul.Ac.Uk> Message-ID: The same on Linux but with the full (absolute) path it works as expected: [zw at ..... tmp]$ xetex --output-directory=./dynamic-content /tmp/foo.tex This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016) (preloaded format=xetex) entering extended mode (/tmp/foo.tex [1] ) Output written on ./dynamic-content/foo.pdf (1 page). Transcript written on ./dynamic-content/foo.log. My ADSL speed is 8 Mbps for download but only 512 kbps for upload, so syncing large files is a problem (uploading 1 hour video takes almost a week). I use a different strategy for my work, I take advantage of versioning and use either subversion or git. Only the source files that cannot be generated are versioned. My hard disk certainly will not die within a few hours (in fact not within a few months) and I commit frequently and at least daily push the git cloned repository. If you do not share the work with others but want to have it available from several computers, Dropbox can be used as a siple subresion and/or git server. The only rule to surviv is: do not do "svn commit" or "git push" if you are offline. And if you do, do not work on other computer before connecting the computer with the latest repository version and syncing it. Zden?k Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz 2017-01-15 10:26 GMT+01:00 Philip Taylor : > > > Philip Taylor wrote: > > > But all of this is besides the point : surely > > > > o XeTeX --output-directory=../dynamic-content foo (or foo.tex) > > > > should compile foo.tex, not ../dynamic-content/foo.tex > > Note that this occurs even if a specific path to "foo.tex" is given : > > > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content > ./foo > > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) > (preloaded format=xetex) > > restricted \write18 enabled. > > entering extended mode > > (../dynamic-content/./foo.tex This is the unintended foo.tex) > > *\end > > No pages of output. > > Transcript written on ../dynamic-content/foo.log. > > > > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content > ./foo.tex > > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) > (preloaded format=xetex) > > restricted \write18 enabled. > > entering extended mode > > (../dynamic-content/./foo.tex This is the unintended foo.tex) > > *\end > > No pages of output. > > Transcript written on ../dynamic-content/foo.log. > > > > E:\TeX\Projects\WBH\Welcome> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sun Jan 15 16:00:33 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 15:00:33 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <0ece07eb-ddae-0815-5556-61087549b302@Rhul.Ac.Uk> Message-ID: Zden?k Wagner wrote: > The same on Linux but with the full (absolute) path it works as > expected: > > [zw at ..... tmp]$ xetex --output-directory=./dynamic-content /tmp/foo.tex But from "/tmp", does "./dynamic-content" exist, and if so, does it contain an instance of "foo.tex" ? ** Phil. From zdenek.wagner at gmail.com Sun Jan 15 16:11:13 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Sun, 15 Jan 2017 16:11:13 +0100 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <0ece07eb-ddae-0815-5556-61087549b302@Rhul.Ac.Uk> Message-ID: 2017-01-15 16:00 GMT+01:00 Philip Taylor : > > > Zden?k Wagner wrote: > > > The same on Linux but with the full (absolute) path it works as > > expected: > > > > [zw at ..... tmp]$ xetex --output-directory=./dynamic-content /tmp/foo.tex > > But from "/tmp", does "./dynamic-content" exist, and if so, does it > contain an instance of "foo.tex" ? > Yes, it does, I have both /tmp/foo.tex and /tmp/dynamic-content/foo.tex and both are different. > > ** Phil. > Zden?k Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: From news3 at nililand.de Sun Jan 15 19:15:54 2017 From: news3 at nililand.de (Ulrike Fischer) Date: Sun, 15 Jan 2017 19:15:54 +0100 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: <993fkisku4wz$.dlg@nililand.de> Am Sun, 15 Jan 2017 09:20:13 +0000 schrieb Philip Taylor: > But all of this is besides the point : surely > > o XeTeX --output-directory=../dynamic-content foo (or foo.tex) > > should compile foo.tex, not ../dynamic-content/foo.tex The output-directory is not only for output-files. XeTeX must also be able to read from this folder, e.g. a toc-file or an aux-file. And if there is (in a latex compilation) an (older) foo.aux in the current folder and a new foo.aux in /dynamic-content you would want it to find the newer one. Which means that the output-directory must be added at the begin of the texinputs path. (In miktex it is the other way round and this can be quite confusing when I test something with output-directory) On the whole I would say, that if you want to use --output-directory you should avoid files with the same name in both folder. Like the other adjustments one should do it doesn't take to much brain-power to follow such a rule. -- Ulrike Fischer http://www.troubleshooting-tex.de/ From d.p.carlisle at gmail.com Sun Jan 15 19:56:20 2017 From: d.p.carlisle at gmail.com (David Carlisle) Date: Sun, 15 Jan 2017 18:56:20 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: On 15 January 2017 at 09:20, Philip Taylor wrote: > > > But all of this is besides the point : surely > > o XeTeX --output-directory=../dynamic-content foo (or foo.tex) > > should compile foo.tex, not ../dynamic-content/foo.tex > > ** Phil. > No I think not, if you do not give a full path to a file tex (usually) looks in . first then looks along the path. --output-directory --output-directory is documented as using the specified directory before the path texdoc web2c page 8 says `-output-directory=dirname' Specify the directory dirname to which output files are written. Also look for input files in dirname first, before looking along the normal search path. See Section 3.4 [Output file location], page 9. but as I said this thread just joins the many previous ones, it seems like anyone who uses --output-directory eventually asks about some confusing aspect of its behaviour. I don't think it would be better here if tex looked in the current directory, then the output directory then the path, as that would mean that if you add -output-directory a document would keep inputting stale tables of contents and aux files from the current directory not new ones being written elsewhere. You can always use a full path to the input file to specify a specific file. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sun Jan 15 20:02:06 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 19:02:06 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <993fkisku4wz$.dlg@nililand.de> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> Message-ID: <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> Ulrike Fischer wrote: > The output-directory is not only for output-files. XeTeX must also be > able to read from this folder, e.g. a toc-file or an aux-file. And if > there is (in a latex compilation) an (older) foo.aux in the current > folder and a new foo.aux in /dynamic-content you would want it to > find the newer one. Whether or not the file "foo.aux" in ../dynamic-content is newer, it should be read in preference to the one in the current directory because that is the defined behaviour when --output-directory=../dynamic-content But the defined behaviour for : o xetex --output-directory=../dynamic-content E:/TeX/Projects/WBH/Welcome/foo.tex must /surely/ be to process E:/TeX/Projects/WBH/Welcome/foo.tex, not E:/TeX/Projects/WBH/Dynamic-content/foo.tex, which is what it does; the "texinputs" path does not come into this, since an explicit directory has been given. Furthermore, if both E:/TeX/Projects/WBH/Welcome/foo.tex and E:/TeX/Projects/WBH/Dynamic-content/foo.tex contain "\input E:/TeX/Projects/WBH/Welcome/foo.aux", then E:/TeX/Projects/WBH/Welcome/foo.aux is indeed \input as specified (i.e., the value of "texinputs" is ignored (as it should be) because an explicit path to the file has been given). Philip Taylor From mskala at ansuz.sooke.bc.ca Sun Jan 15 20:16:16 2017 From: mskala at ansuz.sooke.bc.ca (mskala at ansuz.sooke.bc.ca) Date: Sun, 15 Jan 2017 13:16:16 -0600 (CST) Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> Message-ID: On Sun, 15 Jan 2017, David Carlisle wrote: > ?????????????? Specify the directory dirname to which output files are > written. Also look for > ?????????????? input files in dirname first, before looking along the normal > search path. See > ?????????????? Section 3.4 [Output file location], page 9. The general principle here is that TeX expects to modify files in place. Stuff like the multi-stage compilation of LaTeX implicitly assumes that it works this way, but it is TeX, not LaTeX, that originally instituted the concept. It's not in keeping with the Unix philosophy of programs working as pipes, and it causes trouble for people with other expectations. For instance, I nearly always run TeX engines through Makefiles, and the rewriting of files that are used as both input and output screws up how Make works and requires complicated side handling. But the "modify in place" philosophy is built into TeX at a very deep level; it's not going to change soon; and it's probably pointless to expect that it could be turned off in a real way by a simple command line option. -- Matthew Skala mskala at ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ From P.Taylor at Rhul.Ac.Uk Sun Jan 15 20:26:12 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 19:26:12 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> Message-ID: <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> Philip Taylor wrote: > But the defined behaviour for : > > o xetex --output-directory=../dynamic-content E:/TeX/Projects/WBH/Welcome/foo.tex > > must /surely/ be to process E:/TeX/Projects/WBH/Welcome/foo.tex, not E:/TeX/Projects/WBH/Dynamic-content/foo.tex, which is what it does; This statement was in error : > o xetex --output-directory=../dynamic-content E:/TeX/Projects/WBH/Welcome/foo.tex does indeed process E:/TeX/Projects/WBH/Welcome/foo.tex as requested. Yet with the current working directory : > E:/TeX/Projects/WBH/Welcome/foo.tex > o xetex --output-directory=../dynamic-content ./foo.tex the file that is actually processed is > E:/TeX/Projects/WBH/Dynamic-content/foo.tex In both cases, the path to the source directory has been specified, yet "E:/TeX/Projects/WBH/Welcome/" is correctly honoured while "./" (for . = E:/TeX/Projects/WBH/Welcome) is not. I remain completely confused by this seemingly aberrant and inconsistency behaviour. Philip Taylor -------- E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content E:/TeX/Projects/WBH/Welcome/foo.tex This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) restricted \write18 enabled. entering extended mode (e:/TeX/Projects/WBH/Welcome/foo.tex This is the intended foo.tex (e:/TeX/Projects/WBH/Welcome/foo.aux This is the intended foo.aux) ) No pages of output. Transcript written on ../dynamic-content/foo.log. E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content ./foo.tex This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) restricted \write18 enabled. entering extended mode (../dynamic-content/./foo.tex This is the unintended foo.tex (e:/TeX/Projects/WBH/Welcome/foo.aux This is the intended foo.aux) ) No pages of output. Transcript written on ../dynamic-content/foo.log. E:\TeX\Projects\WBH\Welcome> From zdenek.wagner at gmail.com Sun Jan 15 20:30:27 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Sun, 15 Jan 2017 20:30:27 +0100 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> Message-ID: No, ./ is not a path specification, the normalization rules will remove it, ./foo.tex is the same as foo.tex. If you want to specify the path, ../Welcome/foo.tex will help because such a file is not below dynamic-content. Zden?k Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz 2017-01-15 20:26 GMT+01:00 Philip Taylor : > > > Philip Taylor wrote: > > > But the defined behaviour for : > > > > o xetex --output-directory=../dynamic-content > E:/TeX/Projects/WBH/Welcome/foo.tex > > > > must /surely/ be to process E:/TeX/Projects/WBH/Welcome/foo.tex, not > E:/TeX/Projects/WBH/Dynamic-content/foo.tex, which is what it does; > > This statement was in error : > > > o xetex --output-directory=../dynamic-content > E:/TeX/Projects/WBH/Welcome/foo.tex > > does indeed process E:/TeX/Projects/WBH/Welcome/foo.tex as requested. > Yet with > the current working directory : > > > E:/TeX/Projects/WBH/Welcome/foo.tex > > > o xetex --output-directory=../dynamic-content ./foo.tex > > the file that is actually processed is > > > E:/TeX/Projects/WBH/Dynamic-content/foo.tex > > In both cases, the path to the source directory has been specified, yet > "E:/TeX/Projects/WBH/Welcome/" is correctly honoured while "./" (for . = > E:/TeX/Projects/WBH/Welcome) is not. I remain completely confused by this > seemingly aberrant and inconsistency behaviour. > > Philip Taylor > -------- > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content > E:/TeX/Projects/WBH/Welcome/foo.tex > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) > (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (e:/TeX/Projects/WBH/Welcome/foo.tex This is the intended foo.tex > (e:/TeX/Projects/WBH/Welcome/foo.aux This is the intended foo.aux) ) > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content > ./foo.tex > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) > (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/./foo.tex This is the unintended foo.tex > (e:/TeX/Projects/WBH/Welcome/foo.aux This is the intended foo.aux) ) > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mskala at ansuz.sooke.bc.ca Sun Jan 15 20:43:03 2017 From: mskala at ansuz.sooke.bc.ca (mskala at ansuz.sooke.bc.ca) Date: Sun, 15 Jan 2017 13:43:03 -0600 (CST) Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> Message-ID: On Sun, 15 Jan 2017, Philip Taylor wrote: > the current working directory : > > > E:/TeX/Projects/WBH/Welcome/foo.tex > > > o xetex --output-directory=../dynamic-content ./foo.tex > > the file that is actually processed is > > > E:/TeX/Projects/WBH/Dynamic-content/foo.tex I agree that that shouldn't happen. A relative path on the command line should normally be relative to the current working directory when the program is invoked. My guess is that the option's main effect may really be to cause XeTeX to change to the output directory before doing anything else (like Make's -C option), after which relative paths refer to the specified output directory. But there's more going on here, because what about relative paths specified inside the .tex file? There will be cases where the right thing is to read them from the output directory (like .aux files), and cases where the right thing is for them to be relative to the directory that actually contains the .tex file (like fonts). I'm not sure any simple priority rule for searching both directories will correctly handle all these cases. The bottom line is that attempting to defeat TeX's efforts to keep input and output in the same directory is asking for trouble. Maybe this option shouldn't exist at all. -- Matthew Skala mskala at ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ From P.Taylor at Rhul.Ac.Uk Sun Jan 15 21:05:34 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 20:05:34 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> Message-ID: <161045c8-588f-7d1a-bfda-6a3ed88f53dc@Rhul.Ac.Uk> Zdenek Wagner wrote: > No, ./ is not a path specification, the normalization rules will > remove it, ./foo.tex is the same as foo.tex. If you want to specify > the path, ../Welcome/foo.tex will help because such a file is not > below dynamic-content. What are "the normalisation rules", Zden?k ? ** Phil. From P.Taylor at Rhul.Ac.Uk Sun Jan 15 21:25:02 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 20:25:02 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> Message-ID: <25c6769b-2ffd-72a4-434e-9f2c99f4826c@Rhul.Ac.Uk> Zdenek Wagner wrote: If you want to specify the path, ../Welcome/foo.tex will help because such a file is not below dynamic-content. That would indeed appear to be the case, Zden?k : > E:\TeX\Projects\WBH\Welcome>xetex --output-directory=../dynamic-content ../welcome/foo.tex > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded format=xetex) > restricted \write18 enabled. > entering extended mode > (../dynamic-content/../Welcome/foo.tex This is the intended foo.tex > (e:/TeX/Projects/WBH/Welcome/foo.aux This is the intended foo.aux) ) > No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome> but is not the path through which it finally located the intended "foo.tex" more than a little arcane ? > (../dynamic-content/../Welcome/foo.tex This is the intended foo.tex ...) ** Phil. From zdenek.wagner at gmail.com Sun Jan 15 21:26:33 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Sun, 15 Jan 2017 21:26:33 +0100 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: <161045c8-588f-7d1a-bfda-6a3ed88f53dc@Rhul.Ac.Uk> References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> <161045c8-588f-7d1a-bfda-6a3ed88f53dc@Rhul.Ac.Uk> Message-ID: 2017-01-15 21:05 GMT+01:00 Philip Taylor : > > > Zdenek Wagner wrote: > > > No, ./ is not a path specification, the normalization rules will > > remove it, ./foo.tex is the same as foo.tex. If you want to specify > > the path, ../Welcome/foo.tex will help because such a file is not > > below dynamic-content. > > What are "the normalisation rules", Zden?k ? > ** Phil. > A path can be specified by many equivalent ways, for instance a/./b is the same as a/b, a/c/../b is again a/b (it need not be true in unix systems). Doble slashes are ignored too, a//b is again a/b. The canonical path does not contain double slashes, ./, ../, the engine may remove them before searching the file. Zden?k Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Sun Jan 15 21:34:39 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Sun, 15 Jan 2017 20:34:39 +0000 Subject: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory In-Reply-To: References: <483a4d13-75b2-6602-9993-233fd29e1e77@Rhul.Ac.Uk> <993fkisku4wz$.dlg@nililand.de> <395e2574-0d79-8887-6c0a-e362c4560bff@Rhul.Ac.Uk> <062d9976-4b98-da7b-69e8-f5b3bedca542@Rhul.Ac.Uk> <161045c8-588f-7d1a-bfda-6a3ed88f53dc@Rhul.Ac.Uk> Message-ID: Zden?k Wagner wrote: >> [PT] What are "the normalisation rules", Zden?k ? ** Phil. > A path can be specified by many equivalent ways, for instance a/./b > is the same as a/b, a/c/../b is again a/b (it need not be true in > unix systems). Doble slashes are ignored too, a//b is again a/b. The > canonical path does not contain double slashes, ./, ../, the engine > may remove them before searching the file. Hmmm, thank you : however, it would appear to be the case (here, at least) that "//" <> "/" : > E:\TeX\Projects\WBH\Welcome>xetex > --output-directory=../dynamic-content /foo.tex This is XeTeX, Version > 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded > format=xetex) restricted \write18 enabled. entering extended mode > (/foo.tex This is the intended foo.tex) *\end No pages of output. > Transcript written on ../dynamic-content/foo.log. > > E:\TeX\Projects\WBH\Welcome>xetex > --output-directory=../dynamic-content //foo.tex This is XeTeX, > Version 3.14159265-2.6-0.99996 (TeX Live 2016/W32TeX) (preloaded > format=xetex) restricted \write18 enabled. entering extended mode ! I > can't find file `//foo.tex'. ** Phil. From maxwell at umiacs.umd.edu Wed Jan 18 00:29:28 2017 From: maxwell at umiacs.umd.edu (maxwell) Date: Tue, 17 Jan 2017 18:29:28 -0500 Subject: [XeTeX] version issue? font issue Message-ID: <18d6d4b4f19fb504b117cfbfa2a74663@umiacs.umd.edu> 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.99996 (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.99996 (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 From gweltaz at ucsc.edu Tue Jan 24 06:55:14 2017 From: gweltaz at ucsc.edu (Gildas Hamel) Date: Mon, 23 Jan 2017 21:55:14 -0800 Subject: [XeTeX] Italic and font spec 2.5c vs 2.4a Message-ID: I just updated fontspec from 2.5a to 2.5c via TeX Live Utility. I cannot get italic face to work. I had to revert to 2.5a. Do others see the same thing? ?Gildas Minimum example: %!TEX TS-program = xelatex %!TEX encoding = UTF-8 Unicode \documentclass[12pt]{article} \usepackage{fontspec} \begin{document} \emph{Lorem ipsum dolor sit amet}, consectetaur adipisicing elit... \end{document} -------------- next part -------------- A non-text attachment was scrubbed... Name: italic_fontspec.pdf Type: application/pdf Size: 4999 bytes Desc: not available URL: From gweltaz at ucsc.edu Tue Jan 24 07:32:00 2017 From: gweltaz at ucsc.edu (Gildas Hamel) Date: Mon, 23 Jan 2017 22:32:00 -0800 Subject: [XeTeX] Italic and font spec 2.5c vs 2.4a In-Reply-To: References: Message-ID: <20170124063200.GA8824@iMac.local> * Skriv a reas Gildas Hamel (gweltaz at ucsc.edu): |> I just updated fontspec from 2.5a to 2.5c via TeX Live Utility. I cannot get italic face to work. I had to revert to 2.5a. Do others see the same thing? |> ?Gildas |> |> Minimum example: |> |> %!TEX TS-program = xelatex |> %!TEX encoding = UTF-8 Unicode |> |> \documentclass[12pt]{article} |> \usepackage{fontspec} |> \begin{document} |> \emph{Lorem ipsum dolor sit amet}, consectetaur adipisicing elit... |> \end{document} |> Comment on my own post: I just realized I'm using \emph instead of \textit. The latter works. Do I have to change all my \emph code in my files? A related problem is that I often use Markdown + Pandoc to generate short pdfs. But emphasis in Markdown (signalled by asterisks or underscores) seems to translate as \emph and not \textit and doesn't show as italic face in resulting pdfs when using fontspec 2.5c. Any help and info appreciated, --Gildas From martin at oneiros.de Tue Jan 24 07:38:48 2017 From: martin at oneiros.de (=?UTF-8?Q?Martin_Schr=C3=B6der?=) Date: Tue, 24 Jan 2017 07:38:48 +0100 Subject: [XeTeX] Italic and font spec 2.5c vs 2.4a In-Reply-To: References: Message-ID: 2017-01-24 6:55 GMT+01:00 Gildas Hamel : > I just updated fontspec from 2.5a to 2.5c via TeX Live Utility. I cannot get italic face to work. I had to revert to 2.5a. Do others see the same thing? > ?Gildas Known problem: https://github.com/wspr/fontspec/issues/254 http://tex.stackexchange.com/q/350008/5763 Best Martin From gweltaz at ucsc.edu Tue Jan 24 07:50:15 2017 From: gweltaz at ucsc.edu (Gildas Hamel) Date: Mon, 23 Jan 2017 22:50:15 -0800 Subject: [XeTeX] Italic and font spec 2.5c vs 2.4a In-Reply-To: References: Message-ID: <20170124065015.GA9796@iMac.local> * Skriv a reas Martin Schr?der (martin at oneiros.de): |> Known problem: |> https://github.com/wspr/fontspec/issues/254 |> http://tex.stackexchange.com/q/350008/5763 Ah, I had searched in the wrong places. Thanks. --gildas From jfbu at free.fr Tue Jan 24 19:20:21 2017 From: jfbu at free.fr (jfbu) Date: Tue, 24 Jan 2017 19:20:21 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? Message-ID: <89249ACD-05B0-429D-8561-87E874377515@free.fr> Hi, test file % Tested with TeXLive 2016, up-to-date. % xetex \XeTeXtracingfonts=1 \font\test="[lmmono10-regular.otf]"\test % result otherwise with luatex: % (I don't know how to load font with luatex without luaotfload.sty) %\input luaotfload.sty %\font\test=[lmmono10-regular]:\test \the\fontdimen2\font \quad \the\fontdimen3\font \quad \the\fontdimen4\font \nopagenumbers \bye xetex: 5.25pt 2.625pt 1.75pt Requested font "[lmmono10-regular.otf]" scaled 1000 -> /usr/local/texlive/2016/texmf-dist/fonts/opentype/public/lm/lmmono10-regula r.otf [1] ) luatex:5.25pt 0.0pt 0.0pt % Local variables: % TeX-engine: xetex % End: The stretch and shrink causes issues in code listings. This impacts LaTeX now that Unicode engines use the Latin Modern fonts in opentype format by default with it. LaTeX test file: \documentclass{article} \begin{document} \ttfamily \the\fontdimen2\font \the\fontdimen3\font \the\fontdimen4\font \fontname\font \showoutput \thispagestyle{empty} \end{document} % Local variables: % TeX-engine: xetex % End: xelatex: 5.25pt2.625pt1.75pt "[lmmono10-regular]:" lualatex:5.25pt0.0pt0.0pt [lmmono10-regular]: Best, PS: as I don't currently subscribe to the list, could you please CC my address if replying thanks. Jean-Fran?ois From will at wspr.io Wed Jan 25 03:36:14 2017 From: will at wspr.io (Will Robertson) Date: Wed, 25 Jan 2017 13:06:14 +1030 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <89249ACD-05B0-429D-8561-87E874377515@free.fr> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> Message-ID: <7FA08901-F94C-44CD-96E3-C50941E45C47@wspr.io> Hi all, I'm not able to check this minute, but I wonder if lmmono is being "special-cases" by luaotfload -- would explain the results you're seeing. In fontspec if you load it with \setmonofont the stretch and shrink should be forced to zero, but I can agree it would be good to get to the bottom of this. Cheers Will (Sent from phone; please excuse brevity.) > On 25 Jan. 2017, at 04:50, jfbu wrote: > > Hi, > > test file > > % Tested with TeXLive 2016, up-to-date. > > % xetex > \XeTeXtracingfonts=1 > \font\test="[lmmono10-regular.otf]"\test > > % result otherwise with luatex: > % (I don't know how to load font with luatex without luaotfload.sty) > %\input luaotfload.sty > %\font\test=[lmmono10-regular]:\test > > \the\fontdimen2\font > \quad > \the\fontdimen3\font > \quad > \the\fontdimen4\font > > \nopagenumbers > \bye > > xetex: 5.25pt 2.625pt 1.75pt > > Requested font "[lmmono10-regular.otf]" scaled 1000 > -> /usr/local/texlive/2016/texmf-dist/fonts/opentype/public/lm/lmmono10-regula > r.otf > [1] ) > > luatex:5.25pt 0.0pt 0.0pt > > ve/2016/texmf-dist/fonts/opentype/public/lm/lmmono10-regular.otf> > > % Local variables: > % TeX-engine: xetex > % End: > > The stretch and shrink causes issues in code listings. > > This impacts LaTeX now that Unicode engines > use the Latin Modern fonts in opentype format by > default with it. > > LaTeX test file: > > \documentclass{article} > > \begin{document} > \ttfamily > > \the\fontdimen2\font > \the\fontdimen3\font > \the\fontdimen4\font > > \fontname\font > > \showoutput > \thispagestyle{empty} > \end{document} > % Local variables: > % TeX-engine: xetex > % End: > > xelatex: 5.25pt2.625pt1.75pt "[lmmono10-regular]:" > lualatex:5.25pt0.0pt0.0pt [lmmono10-regular]: > > Best, > > PS: as I don't currently subscribe to the list, could you please > CC my address if replying thanks. > > Jean-Fran?ois > > > _______________________________________________ > Latex-team mailing list > Latex-team at latex-project.org > https://lists.dante.de/mailman/listinfo/latex-team From news3 at nililand.de Wed Jan 25 10:50:31 2017 From: news3 at nililand.de (Ulrike Fischer) Date: Wed, 25 Jan 2017 10:50:31 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> Message-ID: <1sl7xd8jnxn4f.dlg@nililand.de> Am Tue, 24 Jan 2017 19:20:21 +0100 schrieb jfbu: > xetex: 5.25pt 2.625pt 1.75pt There was once a long discussion about this xetex problem around here http://tug.org/pipermail/xetex/2011-February/020072.html It is unclear if it is engine bug and imho no one ever added something to the issue tracker. But it is the reason why fontspec contains code that resets the fontdimens if you use \setmonofont. It would be probably a good idea if this code would be used for the new default mono font too. -- Ulrike Fischer http://www.troubleshooting-tex.de/ From P.Taylor at Rhul.Ac.Uk Wed Jan 25 11:07:34 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Wed, 25 Jan 2017 10:07:34 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <1sl7xd8jnxn4f.dlg@nililand.de> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> Ulrike Fischer wrote: > There was once a long discussion about this xetex problem around > here http://tug.org/pipermail/xetex/2011-February/020072.html > It is unclear if it is engine bug and imho no one ever added > something to the issue tracker. Matthew concluded by writing : It seems clear to me that this is a bug, though I'm not sure yet whether it's better considered as a bug in the XeTeX engine or in the fontspec package, because it's not clear where the stretchability is being set. It seems equally clear to me that the fault cannot lie in the fontspec package, since it can be demonstrated with a pure XeTeX example as Jean-Fran?ois has shewn ... Whether the fault lies in the XeTeX engine or in the font is moot, I believe. Philip Taylor From zdenek.wagner at gmail.com Wed Jan 25 11:13:42 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Wed, 25 Jan 2017 11:13:42 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> Message-ID: 2017-01-25 11:07 GMT+01:00 Philip Taylor : > Ulrike Fischer wrote: > > There was once a long discussion about this xetex problem around > > here http://tug.org/pipermail/xetex/2011-February/020072.html > > It is unclear if it is engine bug and imho no one ever added > > something to the issue tracker. > Matthew concluded by writing : > > It seems clear to me that this is a bug, though I'm not sure yet whether > it's better considered as a bug in the XeTeX engine or in the fontspec > package, because it's not clear where the stretchability is being set. > > It seems equally clear to me that the fault cannot lie in the fontspec > package, > since it can be demonstrated with a pure XeTeX example as Jean-Fran?ois > has shewn ... Whether the fault lies in the XeTeX engine or in the font > is moot, > I believe. > It might be set in the font and XeTeX just reads it. I do not know how to look inside the font but I heard somewhere, that such mono fonts do exist. > > Philip Taylor > > > > Zden?k Wagner > http://ttsm.icpf.cas.cz/team/wagner.shtml > http://icebearsoft.euweb.cz > > > -------------------------------------------------- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From news3 at nililand.de Wed Jan 25 11:37:10 2017 From: news3 at nililand.de (Ulrike Fischer) Date: Wed, 25 Jan 2017 11:37:10 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> Message-ID: <1okdt6fmsqb0d.dlg@nililand.de> Am Wed, 25 Jan 2017 10:07:34 +0000 schrieb Philip Taylor: > Whether the fault lies in the XeTeX engine or in the font is moot, Well imho it is a difference if a font set this values and xetex simply reads them in or if the font doesn't set this values and xetex guesses (faulty) defaults. Actually I found an old discussion which seems to imply that xetex calculates the fontdimens starting from the width a space -- and doesn't care about monospace or not: https://tug.org/pipermail/xetex/2006-June/004236.html -- Ulrike Fischer http://www.troubleshooting-tex.de/ From d.p.carlisle at gmail.com Wed Jan 25 11:43:49 2017 From: d.p.carlisle at gmail.com (David Carlisle) Date: Wed, 25 Jan 2017 10:43:49 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <1okdt6fmsqb0d.dlg@nililand.de> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> <1okdt6fmsqb0d.dlg@nililand.de> Message-ID: For latex at least I think the thing to do is amend tulmtt.fd in base so that it has \DeclareFontFamily{TU}{lmtt}{% \hyphenchar \font\m at ne \fontdimen3\font\z@%<< \fontdimen4\font\z@%<< } with the two extra lines ensuring that these two font dimens are set to 0. (If you try this with a latex 2017/01/01 release you need to remake the format as it is input during format creation) David From P.Taylor at Rhul.Ac.Uk Wed Jan 25 11:46:54 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Wed, 25 Jan 2017 10:46:54 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <1okdt6fmsqb0d.dlg@nililand.de> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> <1okdt6fmsqb0d.dlg@nililand.de> Message-ID: <5050c743-fc9f-19dd-d161-d06262636a65@Rhul.Ac.Uk> Ulrike Fischer wrote: > > Actually I found an old discussion which seems to imply that xetex > calculates the fontdimens starting from the width a space -- and > doesn't care about monospace or not: > > https://tug.org/pipermail/xetex/2006-June/004236.html But do we know whether the font in question sets "isFixedPitch" true ? Philip Taylor From P.Taylor at Rhul.Ac.Uk Wed Jan 25 12:15:13 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Wed, 25 Jan 2017 11:15:13 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <5050c743-fc9f-19dd-d161-d06262636a65@Rhul.Ac.Uk> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> <1okdt6fmsqb0d.dlg@nililand.de> <5050c743-fc9f-19dd-d161-d06262636a65@Rhul.Ac.Uk> Message-ID: Philip Taylor wrote: > > But do we know whether the font in question sets "isFixedPitch" true ? > To answer my own question : "yes" (assuming that "1" = "true") : -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Taylor at Rhul.Ac.Uk Wed Jan 25 12:34:12 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Wed, 25 Jan 2017 11:34:12 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> <1okdt6fmsqb0d.dlg@nililand.de> <5050c743-fc9f-19dd-d161-d06262636a65@Rhul.Ac.Uk> Message-ID: <8d2afaf1-a5ca-5804-daa3-4fbe98a6687e@Rhul.Ac.Uk> Philip Taylor wrote: > To answer my own question : "yes" (assuming that "1" = "true") : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In which case I feel that it might safely be argued that there is a deficiency in the XeTeX handling of Opentype monospaced fonts, unless (of course) the Opentype specification allows "isFixedPitch" (and perhaps analogous flags) to be ignored by a fully-compliant implementation. ** Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mskala at ansuz.sooke.bc.ca Wed Jan 25 14:03:19 2017 From: mskala at ansuz.sooke.bc.ca (mskala at ansuz.sooke.bc.ca) Date: Wed, 25 Jan 2017 07:03:19 -0600 (CST) Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <1sl7xd8jnxn4f.dlg@nililand.de> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: On Wed, 25 Jan 2017, Ulrike Fischer wrote: > There was once a long discussion about this xetex problem around > here http://tug.org/pipermail/xetex/2011-February/020072.html > It is unclear if it is engine bug and imho no one ever added > something to the issue tracker. That was a long, complicated discussion touching on multiple issues: between-sentence space, what actually is a monospace font, etc. I probably don't remember all the details clearly, and probably neither does anyone else. But I did skim through the archive just now and it does have some useful information in it. Worth reading the rest of the thread - that particular posting isn't the last word on the issues it describes. There is also an earlier thread in September 2010 about stretchability of spaces in monospace setting, which may be relevant. There were three items in the fontspec issue tracker and I think they've all been long since dealt with. But the goal in 2011 was for fontspec in particular to correctly handle monospace spacing through size changes when it had been told by the document that the font was monospace. There wasn't solid agreement on whether it's really a XeTeX bug that XeTeX without fontspec initially sets those fontdimens nonzero. Since fontspec overrides them anyway, and that case wasn't important to the most vocal complainers at the time (mostly myself), that particular point was never explored further. Using XeTeX without fontspec is a relatively unusual case and it's unsurprising there hasn't been a lot of time spent on testing that. The engine and package go together. The "monospace" flag in OpenType is unreliable. It's probably not a good idea to depend on its having a useful value. Testing the comparative widths of "i" and "m" is probably a better way to detect monospace fonts, and as I understand it, that's what fontspec now does. XeTeX itself could do the same. Even if the "monospace" flag in OpenType were reliably set according to the OpenType specification (which we can't assume), it might not be correct to use it. There is debate over correct interpretation of the specification, but the consensus appears to be that the flag is supposed to be set if and only if absolutely every glyph in the font with nonzero width has the same width. There are many fonts where more than one distinct nonzero width exists, and so the flag ought to be turned off, even though the fonts really are monospace in some important sense and should be treated as such for purposes like sentence spacing. For instance, this is the usual case for CJK fonts, which are traditionally set on a grid with CJK characters consuming a full square each and Western characters consuming half a square each. CJK fonts are especially relevant to XeTeX. Thus, we cannot trust the "monospace" flag in OpenType to correctly tell XeTeX whether monospace-related adaptations like unstretchable space, should be applied. We cannot redefine the "monospace" flag to have a more useful value. Some other software and maybe even hardware assumes that the OpenType "monospace" flag is set if and only if absolutely every glyph in the font with nonzero width has the same width. These other systems will break if their assumption is incorrect. Thus even if we can edit font files to have this flag set in a way that correctly tells XeTeX whether to apply monospace-related adaptations, it would be a bad idea to use the flag that way. -- Matthew Skala mskala at ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ From d.p.carlisle at gmail.com Wed Jan 25 14:21:50 2017 From: d.p.carlisle at gmail.com (David Carlisle) Date: Wed, 25 Jan 2017 13:21:50 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: > Using XeTeX without fontspec is a relatively unusual case and it's > unsurprising there hasn't been a lot of time spent on testing that. The > engine and package go together. It may become slightly less unusual after this week's latex release as now latex defaults to TU (Unicode) encoding with xetex and luatex so the initial state for \ttfamiliy is OpenType latin modern monospace However we will put out a patch level 1 release in the next day or so that sets the font parameters 3 and 4 to zero in the fd file as in my previous message so the default setting of typewriter text will not stretch word spaces in xelatex just as in pdf and lua latex. David From P.Taylor at Rhul.Ac.Uk Wed Jan 25 15:07:50 2017 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor) Date: Wed, 25 Jan 2017 14:07:50 +0000 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: mskala at ansuz.sooke.bc.ca wrote: > Using XeTeX without fontspec is a relatively unusual case I respectfully disagree. I use exclusively XeTeX and never fontspec. I am certain that I am not alone in this. Philip Taylor From mskala at ansuz.sooke.bc.ca Wed Jan 25 15:17:11 2017 From: mskala at ansuz.sooke.bc.ca (mskala at ansuz.sooke.bc.ca) Date: Wed, 25 Jan 2017 08:17:11 -0600 (CST) Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: On Wed, 25 Jan 2017, Philip Taylor wrote: > mskala at ansuz.sooke.bc.ca wrote: > > Using XeTeX without fontspec is a relatively unusual case > I respectfully disagree. I use exclusively XeTeX and never fontspec. I am certain that I am not alone in this. That's why I said "relatively unusual" and not "absolutely unheard of." Some people certainly do it. Most people don't. -- Matthew Skala mskala at ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ From zdenek.wagner at gmail.com Wed Jan 25 15:18:58 2017 From: zdenek.wagner at gmail.com (Zdenek Wagner) Date: Wed, 25 Jan 2017 15:18:58 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: 2017-01-25 15:17 GMT+01:00 : > On Wed, 25 Jan 2017, Philip Taylor wrote: > > mskala at ansuz.sooke.bc.ca wrote: > > > Using XeTeX without fontspec is a relatively unusual case > > I respectfully disagree. I use exclusively XeTeX and never fontspec. I > am certain that I am not alone in this. > > That's why I said "relatively unusual" and not "absolutely unheard of." > Some people certainly do it. Most people don't. > XeLaTeX + fontspec is usual, plain XeTeX users rarely use fonspec. > > -- > Matthew Skala > mskala at ansuz.sooke.bc.ca People before principles. > http://ansuz.sooke.bc.ca/ > > Zden?k Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz > > -------------------------------------------------- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfbu at free.fr Wed Jan 25 11:47:05 2017 From: jfbu at free.fr (jfbu) Date: Wed, 25 Jan 2017 11:47:05 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <58f91568-2968-2534-ec89-592f469c626e@Rhul.Ac.Uk> Message-ID: <5C206EA9-43E3-48C0-A873-DD537F3B6469@free.fr> Hi Le 25 janv. 2017 ? 11:13, Zdenek Wagner a ?crit : > It seems equally clear to me that the fault cannot lie in the fontspec package, > since it can be demonstrated with a pure XeTeX example as Jean-Fran?ois > has shewn ... Whether the fault lies in the XeTeX engine or in the font is moot, > I believe. > > It might be set in the font and XeTeX just reads it. I do not know how to look inside the font but I heard somewhere, that such mono fonts do exist. > I know about lmvtt, for T1 encoding which is a "variable" variant of lmodern mono font for traditional TeX engine, but this has to be requested by specific option, also Michael Sharpe's newtxtt has such an option (and I use such a "variable space" mono font extensively in a package doc) Perhaps Latin Modern Mono has it in the font, and luaotfload intercepts this so that one does not see the phenomenon in the plain LuaTeX example, Anyway, this will now break all XeLaTeX documents with verbatim parts, and default fonts, since the LaTeX 2017/01/01 recently uploaded to CTAN. Arguably most XeLaTeX users will have set-up their own choice of fonts in the document, thus the impact may not be that big "in the wild". Best, Jean-Fran?ois -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfbu at free.fr Wed Jan 25 12:12:02 2017 From: jfbu at free.fr (jfbu) Date: Wed, 25 Jan 2017 12:12:02 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <1sl7xd8jnxn4f.dlg@nililand.de> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> Message-ID: <7C8633C2-BC6B-4DDD-ADAA-83064867E622@free.fr> Le 25 janv. 2017 ? 10:50, Ulrike Fischer a ?crit : >> > > There was once a long discussion about this xetex problem around > here http://tug.org/pipermail/xetex/2011-February/020072.html Hi, [somewhat peripheral question] in http://tug.org/pipermail/xetex/2011-February/020099.html (and also in one earlier post) in the thread pointed out by Ulrike, Matthew Skala commented on a WordSpace issue with fontspec. Has this issue been fixed since in fontspec ? Jean-Fran?ois From mskala at ansuz.sooke.bc.ca Wed Jan 25 15:37:13 2017 From: mskala at ansuz.sooke.bc.ca (mskala at ansuz.sooke.bc.ca) Date: Wed, 25 Jan 2017 08:37:13 -0600 (CST) Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: <7C8633C2-BC6B-4DDD-ADAA-83064867E622@free.fr> References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <7C8633C2-BC6B-4DDD-ADAA-83064867E622@free.fr> Message-ID: On Wed, 25 Jan 2017, jfbu wrote: > in http://tug.org/pipermail/xetex/2011-February/020099.html > (and also in one earlier post) in the thread pointed out by Ulrike, > Matthew Skala commented on a WordSpace issue with fontspec. > > Has this issue been fixed since in fontspec ? Three related issues were filed in the fontspec bug tracker, one of which has been closed: https://github.com/wspr/fontspec/issues/97 https://github.com/wspr/fontspec/issues/98 https://github.com/wspr/fontspec/issues/99 -- Matthew Skala mskala at ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ From jfbu at free.fr Sat Jan 28 21:58:59 2017 From: jfbu at free.fr (jfbu) Date: Sat, 28 Jan 2017 21:58:59 +0100 Subject: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ? In-Reply-To: References: <89249ACD-05B0-429D-8561-87E874377515@free.fr> <1sl7xd8jnxn4f.dlg@nililand.de> <7C8633C2-BC6B-4DDD-ADAA-83064867E622@free.fr> Message-ID: <9E06CAB4-A947-427E-AE4A-4529D8B6EFEE@free.fr> > > Three related issues were filed in the fontspec bug tracker, one of which > has been closed: > > https://github.com/wspr/fontspec/issues/97 > https://github.com/wspr/fontspec/issues/98 > https://github.com/wspr/fontspec/issues/99 > Thanks, Jean-Fran?ois From h.y.acetaminophen at gmail.com Tue Jan 31 05:59:31 2017 From: h.y.acetaminophen at gmail.com (Hironobu Yamashita) Date: Tue, 31 Jan 2017 13:59:31 +0900 Subject: [XeTeX] error: can't allocate region with xelatex Message-ID: Hello, I encountered the following situation with xelatex. $ echo x | xelatex \\showthe\\everyjob This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016) (preloaded format=xelatex) restricted \write18 enabled. entering extended mode LaTeX2e <2017/01/01> patch level 1 Babel <3.9r> and hyphenation patterns for 83 language(s) loaded. > \typeout {\fmtname \space <\fmtversion > patch level \patch at level }\typeout { Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.}. <*> \showthe\everyjob ? xelatex(45131) malloc: *** mmap(size=18446744073636376576) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug fatal: memory exhausted (xmalloc of 18446744073636373502 bytes). No pages of output. I also tested with the latest TeX Live svn (2017/dev), and it gave the same result. On Windows, the message "xelatex.exe has stopped working" appeared. I'm not sure if this is really a problem, but just in case... Regards, Hironobu Yamashita From kakuto at fuk.kindai.ac.jp Tue Jan 31 17:28:16 2017 From: kakuto at fuk.kindai.ac.jp (Akira Kakuto) Date: Wed, 1 Feb 2017 01:28:16 +0900 Subject: [XeTeX] error: can't allocate region with xelatex In-Reply-To: References: Message-ID: <7AF9F0E9781541FB90DA030BCC3FEBED@CJ3001517A> > I encountered the following situation with xelatex. > > $ echo x | xelatex \\showthe\\everyjob > > This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016) It seems that in the given example, s = 0 and len < 0 in the following: /* texmfmp.c */ 2815: string 2816: gettexstring (strnumber s) 2817: { 2818: unsigned bytesToWrite = 0; 2819: poolpointer len, i, j; 2820: string name; 2821: len = strstart[s + 1 - 65536L] - strstart[s - 65536L]; 2822: name = xmalloc(len * 3 + 1); /* max UTF16->UTF8 expansion 2823: (code units, not bytes) */ Best, Akira