Re: [XeTeX] Adobe PDF, Adobe Acrobat/Reader, Microsoft Word, XeTeX, and (x)dvipdfm(x).
On Thu, 27 May 2021, Philip Taylor wrote: > msk...@ansuz.sooke.bc.ca wrote: > > Is this a function of the PDF writer "instructing" the reader to reload, > > or is it something the PDF reader does independently? > > Empirical observation suggests the former. If it were the latter, then > would it (Adobe Acrobat, that is) not do the same when XeTeX + (x)dvipdfm(x) > attempts to write to the file ? At the moment, the latter simply aborts and > the file remains unchanged. Well, if the writer is aborting, then there must be some kind of communication between it and the reader already. Under Linux it would normally be impossible for the reader to prevent the writer from rewriting the file; but that's a different issue from what I thought was the question, about the reader knowing to reload the file *after* the writer has written it. Seems like it will need some kind of Windows-specific handling to resolve, then. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/
Re: [XeTeX] Adobe PDF, Adobe Acrobat/Reader, Microsoft Word, XeTeX, and (x)dvipdfm(x).
On Thu, 27 May 2021, Philip Taylor wrote: > the course of so doing, I have realised that MS Word can instruct Adobe > Acrobat (and probably Adobe Reader) to close the PDF and then re-open it > once the changes have been made. Is there any reason why the (x)dvipdfm(x) > back-end to XeTeX cannot [be enhanced to] do the same ? Is this a function of the PDF writer "instructing" the reader to reload, or is it something the PDF reader does independently? On my Linux system, the "okular" PDF reader automatically reloads when a file is changed, regardless of what software wrote the file. It works with xdvipdfmx and everything else, because the notification comes from a general operating system feature invoked by the reader without the writer being involved. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/
Re: no more subject prefix for xetex mailing list
On Tue, 5 Mar 2019, Zdenek Wagner wrote: > problem. Gmail accepts majority of such mails. Only if I display the > original message, I can see DKIM FAIL and DMARC FAIL. However, I had > problems with forwarded messages and important invoices were not It would certainly be better that the mailing list rewrite From: *and* also implement all of SPF/DKIM/DMARC properly, too. But just rewriting the From: header with no other changes would be an improvement on the current situation where list messages are hostage to DMARC policies set by original-authors' domains. And I'd advocate it as a first step because it's something that can probably be done by the list administrator acting alone, without needing to also coordinate with whoever runs the mail server, whoever has administration control over the domain, and so on. I don't see a downside to implementing From: rewriting. Do that, even all by itself, and some significant amount of mail which currently fails will get through, while little or no mail which currently gets through will start to fail. It seems like a good first step toward the more complicated "Right Thing" solution, and it is a necessary part of the more complicated solution anyway. As I mentioned earlier, From: rewriting might be bad for a list that wants to send replies to the original authors instead of to the list by default, but since the XeTeX list is already setting Reply-To: to the list, that's evidently not an issue in this case. Google can't be trusted to let through every important message. I run a monthly newsletter for my small business that still gets routinely filed under "spam" by Google even though it is opt-in subscription only and Google's own status display says that the messages pass all of SPF, DKIM, and DMARC. We can't expect all mailing list messages to pass Google. But they are more likely to do if they have the From: headers rewritten to a domain that will, at the very least, pass SPF. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/
Re: no more subject prefix for xetex mailing list
On Tue, 5 Mar 2019, Zdenek Wagner wrote: > DMARC can be set as one of the following ways: > * The mail is valid if at least one of SPF and DKIM passes > * If the mail is signed, it is valid if both SPF and DKIM pass > > Let's assume that we have the latter case and we try to "solve" it by > changing the From header to someth...@tug.org. Now the mail is sent > from @tug.org but is signed by a key from @example.com, hence DKIM > fails. As described in RFC 7489 section 6.6.3, the RFC5322.From domain is queried for the DMARC policy to apply. If that returns nothing, there is a fallback to the "Organizational Domain" of the RFC5322.From but it still has to come from the RFC5322.From domain. That means that if there's a policy on "tug.org" but not on "foo.bar.tug.org," then a message From: an @foo.bar.tug.org address is required by DMARC to be handled under the policy of tug.org. But that's the only way in which a policy other than that of the exact domain in the From: header can ever be applied by a compliant implementation. [From RFC 7489:] 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the one found in the RFC5322.From domain in the message. A possibly empty set of records is returned. 2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned. 4. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 5. If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message. [end] If a user from example.com, which domain signs with DKIM and sets a restrictive policy, sends mail to the list and the list rewrites the From: header to an @tug.org address, then the RFC5322.From domain will be "tug.org" and only the DMARC policy published by tug.org will be used to determine handling by an RFC 7489 compliant recipient. DKIM does not pass if tug.org didn't sign, passes if tug.org did sign, but either way it is tug.org's policy (or lack thereof) that determines handling. The policy of example.com is out of the picture entirely, and DKIM signatures from example.com still attached to the message cannot be used to determine handling by a compliant recipient. Of course there can be non-compliant recipients out there, and there could be other behaviour with recipients that implement SPF or DKIM without DMARC, and for the benefit of such recipients it might be a good idea to strip off incoming DKIM signatures. But I don't think that's terribly important. Random extra DKIM signatures from unaligned domains are not rare in the wild and they don't seem to be causing huge problems; at the very least, just rewriting From: without stripping incoming signatures would be a big improvement over the current situation of the XeTeX list. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/
Re: no more subject prefix for xetex mailing list
On Mon, 4 Mar 2019, Zdenek Wagner wrote: > I am afraid that the subject prefix is just one of several reasons. I > have just examined the recent reply by Norbert Preining. Gmail > reports: > SPF: PASS, DKIM: FAIL, DMARC: FAIL. If SPF passes, then DMARC ought to pass. DMARC is only supposed to require one of these, not necessarily both. The reason the message hasn't passed DMARC is that it has not really passed SPF here. The list is allowed by SPF to send things from tug.org, which is in the "envelope sender" of the message, but DMARC looks at the From: header, which under the current config is the original author. Although there are complexities involved, basically these checks will fail for many recipients if the list rewrites the Subject: header, or rewrites any other signed material (such as adding a footer to the message body), and doesn't rewrite the From: header to something for which it's authorized. Many lists don't want to rewrite the From: header because they want replies to go to the original author instead of the list... but that doesn't seem to be the case here because the list is setting Reply-To: to the list anyway. So that's not a reason to avoid rewriting From:. If it's desired to keep the original author's name prominent in the headers, it could either go into a custom field, or the text "real name" part of the rewritten From: header. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/
Re: [XeTeX] "typeset by bidi" message
On Sun, 28 Jan 2018, Philip Taylor (RHUoL) wrote: > As \usepackage is under the control of the LaTeX team, could its behaviour > not be amended to check if #1 = "bidi", and if so, interpolate "[logo=off] > unless "[logo=on]" is already present ? It could, but adding code to every invocation of \usepackage everywhere just for this one case seems like it could lead to an escalating chain of more and more complicated cases to deal with. What happens if other packages also create logo "features" - will we include overrides for them all, in the global \usepackage command that everybody uses in every document? The precedent of doing it for one might make it seem necessary to do it for every similar package. What if bidi's feature changes its name in a new version, or becomes harder to disable - will \usepackage have to track versions of bidi and do what it takes to disable the logo in each version? The amount of code needed could quickly become significant. I think there is a human issue here that will not be solved by a purely technical fix. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] "typeset by bidi" message
On Fri, 26 Jan 2018, David Carlisle wrote: > the bidi author gives some justification for this here > > https://github.com/tex-xet/bidi/issues/60 tlmgr remove bidi --force -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] Conflict among XeLaTeX, LaTeX.mk, and pdfpages
I've run into a problem when using all three of XeLaTeX, LaTeX.mk, and
pdfpages, in their current versions from the latest TeXLive. It appears
that in order to determine file dependencies, LaTeX.mk runs the TeX engine
with the texdepends package (which is part of LaTeX.mk) wedged into the
input file; then texdepends intercepts a bunch of internal macros used by
various graphics packages including indirectly by pdfpages, and the result
is a failure with "arithmetic overflow" when trying to include PDF files.
All three elements seem to be necessary: it doesn't happen with other TeX
engines I've tried; when invoking XeLaTeX manually instead of through
LaTeX.mk; nor without using pdfpages. However, I can also reproduce the
problem by loading texdepends in my .tex file (with \RequirePackage - it
must be loaded before \documentclass and \usepackage cannot be used then)
and running xelatex from the command line instead of through make.
The relevant messages in the log file when it fails look like:
Package texdepends Warning: No 'testa.xbb' file
(texdepends)using 1 for graphic dimensions on input line 31.
File: testa.pdf Graphic file (type pdf)
! Arithmetic overflow.
\calc@Acount
l.31 \includepdf[pages=-]{testa.pdf}
Any thoughts on how this might be fixable?
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/define lu-define-flavor-XELATEX
$$(eval $$(call lu-create-flavor,XELATEX,tex,XELATEX,.pdf,pdf,\
.pdftex_t .$$(_LU_XELATEX_EXT)))
endef
LU_FLAVORS=XELATEX
XELATEX=xelatex
include LaTeX.mk
\documentclass{article}
\title{Test document A}
\author{Matthew Skala}
\date{\today}
\begin{document}
\maketitle
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec egestas
pharetra dui, nec sagittis ex gravida at. Nulla facilisi. Vivamus non est
diam. Nunc eget ullamcorper tellus. Cras ut ligula volutpat, fermentum est
nec, dictum magna. Proin consectetur posuere consectetur. Vestibulum
gravida, ipsum et varius rutrum, arcu massa sodales sapien, ac scelerisque
odio quam sed odio. Sed sit amet arcu pellentesque, rutrum tortor vitae,
ullamcorper purus. Integer rhoncus arcu at augue efficitur, quis auctor mi
blandit. Duis vitae metus turpis. Integer ultricies arcu eget ante
convallis, id gravida ante feugiat. Praesent non nisi vitae metus lobortis
pharetra. Quisque a lacus ipsum. Nullam sed convallis erat, vitae aliquet
tellus. Nam ullamcorper nulla vitae elit porta gravida. Suspendisse
vestibulum nulla non sapien consectetur, sed vehicula ipsum pharetra.
Nam in ullamcorper metus, et mattis nibh. Fusce non arcu mauris. Aliquam
ornare nisi mauris, a lacinia dolor aliquam eget. Phasellus efficitur
venenatis rhoncus. Etiam eu elit eu felis suscipit hendrerit et id urna.
Vivamus porttitor, velit sed volutpat condimentum, dui arcu dictum erat, id
dignissim ex turpis a neque. Nunc lacinia neque id leo egestas molestie eu
vel ligula. Integer ac ex commodo, tincidunt tortor eu, convallis nulla.
Aliquam a odio vitae velit viverra blandit.
Ut nec consectetur est. Nulla quis magna efficitur, luctus nisl eget,
blandit metus. Sed ante lorem, finibus eget malesuada eu, fringilla nec
nulla. Praesent vitae mattis elit, vitae suscipit dolor. Nunc in velit
arcu. Aenean nibh augue, pellentesque nec accumsan non, tristique ac lacus.
Quisque bibendum tortor at nunc fermentum interdum. Nullam et neque quis
ligula mollis bibendum. Integer molestie, diam ut consectetur suscipit,
neque sapien sollicitudin odio, non condimentum enim quam quis odio. Aenean
commodo mauris quis scelerisque eleifend. Vivamus nec libero elit. Integer
sed purus euismod, elementum nulla vitae, fermentum velit. Etiam aliquet at
metus ut dignissim.
Maecenas vehicula sem sed ex vehicula malesuada. Vestibulum ante ipsum
primis in faucibus orci luctus et ultrices posuere cubilia Curae; Nunc diam
nisi, ullamcorper vitae leo vel, consectetur dapibus massa. Quisque ac
velit enim. Fusce bibendum est nec pulvinar congue. Aenean ex enim,
viverra vitae sem a, volutpat imperdiet justo. In tempor quis tellus
posuere blandit. Morbi ornare ultricies tellus, pharetra ornare odio
efficitur id. Vivamus neque dui, commodo ut turpis in, mattis tempor
lectus. Duis vitae dui ut elit porttitor faucibus sit amet nec metus.
\end{document}
% uncomment this to test without needing to invoke make
% \RequirePackage{texdepends}
\documentclass{article}
\usepackage{pdfpages}
\title{Test document B}
\author{Matthew Skala}
\date{\today}
\begin{document}
\maketitle
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec egestas
pharetra dui, nec sagittis ex gravida at. Nulla facilisi. Vivamus non est
diam. Nunc eget ullamcorper tellus. Cras ut ligula volutpat, fermentum est
nec, dictum magna. Proin consectetur posuere consectetur. Vestibulum
gravida, ipsum et varius rutrum, arcu massa sodales sapien, ac scelerisque
odio quam sed odio.
Re: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?
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 msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?
On Wed, 25 Jan 2017, Philip Taylor wrote: > msk...@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 msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?
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 msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Problem with XeTeX's (and perhaps other binaries -- not investigated) handling of --output-directory
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 msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX
On Fri, 18 Mar 2016, Reinhard Kotucha wrote: > > hboxes, as directly as possible. A script that replaces TeX can > Matthew, honestly, I don't think that people didn't understand your > suggestion. There are just a few problems and there is no real > benefit, IMO. > > You suggested to put the wrappers into PATH and call the real programs Maybe someone else suggested that; several people here have advocated wrapper scripts and I wasn't the first to do so. I don't think I mentioned the PATH variable myself before now at all. I was actually thinking of leaving XeTeX where it is, under its original name, giving the wrapper script some completely different name, and then telling TeXworks to use the new name - which I expect should be possible because TeXworks already is capable of running multiple backends. If TeXworks hard-codes the list of possible names of the TeX engine, then yes, it might be necessary to name the script something TeXworks can call... but possibilities for leaving it in place could include giving the script the name of some other TeX engine TeXworks can invoke (ugly, but it'd work) or putting the script in a PATH directory searched before the one that contains real XeTeX, so that it can replace real XeTeX without touching any other executables. There's an issue here of which I've been trying to politely not make a big deal, but: We have only one user demanding this. If we even care at all, then we don't need a solution for everybody. Just him. That means questions of portability to all operating systems, or of compatibility with software and features he doesn't use, are not really significant. It also means the question "Who should write new code?" is not the false dilemma Philip Taylor has repeatedly claimed, with the answer necessarily being either "all TeX engine maintainers!" or "all front end maintainers!" It isn't *all* of any open-ended group. It's *one* person who wants his system to operate differently, who could have that by writing a script himself, and who has succeeded in winding us up to treat his very personal use case as if it needed to be universal. TeXworks; XeTeX (and specifically not XeLaTeX); whatever operating system Philip Taylor uses. Not all front ends; not all TeX engines; not any LaTeX-specific feature; not all operating systems; only one user. This is not a general issue and it does not need a universally portable solution. > another program which is supposed to be in PATH. Nowadays EPS files > are converted to PDF on-the-fly, if necessary. But it can only work > if the directory containing the TeX Live binaries is in PATH so that > epstopdf can be found. Is that a TeX feature or a LaTeX feature? Mr. Taylor famously doesn't use LaTeX, so if it's a LaTeX feature, breaking it doesn't matter - but it'd only be broken if epstopdf were taken out of PATH anyway, which I did not recommend. (Does whatever searches for epstopdf even use PATH anyway? I'd've expected it to use kpsewhich, independently of PATH. But this isn't relevant!) Even if it were necessary to take the real XeTeX out of PATH - which is not the case - why would that have anything to do with changing the name or location of epstopdf? > Your suggestion implies that there are two programs with the same > name name in different directories. This is nasty and certainly No, I intended that the script should not be named "xetex" and that real XeTeX should remain where it is. If TeXworks hardcoded the name so that the script were forced to be named "xetex", then yes, things would become more complicated, but I don't think that is actually the case, and even if it were, it would not be a dealbreaker. > causes more problems than it solves. And please consider that there > are zillions of TeX engines/formats nowadays and you need wrappers for > all of them. Only the engine that one user uses, and it only has to work on his system. > order to save time. But if your wrapper scans the log file in order > to determine the proper exit status, you don't save any time at all. I think most of us agree that saving computation time is not a real consideration here. You say so yourself, below. > The best solution is to run a script which inspects the log file after > each TeX run. Yes, that's what I said. Apparently TeXworks's built-in feature for running postprocessing scripts isn't suitable for this purpose because the scripts run by that feature aren't able to tell TeXworks that TeX has "failed" in the way that causes it to open a log window, which was was what the user wanted. But a wrapper script could do it by returning a nonzero exit code, so I think a wrapper script is the best solution. > Emacs/AUCTeX is doing this for more than two decades. > Programming languages like Perl or Lua are probably even faster than > Emacs Lisp. Not to mention that computers are much faster than 20 > years ago. Indeed. > Phil assumed that scanning the log file is time consuming and thus >
Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX
On Wed, 16 Mar 2016, Stefan Löffler wrote: > More importantly, though, several scripts could be run (say, one that > looks only for errors and only that only looks for warnings) which could > give contradicting results (e.g., no errors => close, warnings => don't I think you're describing some kind of TeXworks-specific feature for running scripts after the TeX engine, separately from running the TeX engine. That's different from what I had in mind, which was to *replace* the TeX engine by a script that internally runs TeX and then returns 0 or 1 conditional on whatever checks are desired. TeXworks would only see this as "TeX returned 1" without knowing there was a script involved. It only needs to be able to run the script instead of TeX, which can be achieved by making the script executable and telling TeXworks "use this executable file as the TeX engine." I was trying to address the request for TeX to return 1 on overfull hboxes, as directly as possible. A script that replaces TeX can give that effect without needing any modifications to TeX nor TeXworks. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Overfull boxes return status of 0 in XeTeX
On Sun, 13 Mar 2016, Philip Taylor wrote: > > Nowadays all TeX distros have lua. > > The fact that a distribution may have (and include) a particular > scripting language does not mean that a front-end such as TeXworks can > necessarily make use of scripts expressed in that language, surely ? It does. If a script begins with the characters "#!" and the name of a script interpreter, and has the execute bit set, then it can be executed like any other program, and the front end can run it the same way the front end would run any TeX engine. This is a facility of the operating system, often called the "shebang" mechanism, and it is transparent to applications. There is no need for the front end to know what language the script is written in, nor how to interpret that language. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Overfull boxes return status of 0 in XeTeX
On Sun, 13 Mar 2016, Philip Taylor wrote: > that no error has occurred. All I am asking is that XeTeX be given the > option to inform TeXworks that an error has occurred when an overfull > box has been generated. Why is this a XeTeX issue and not a TeXworks issue? -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Overfull boxes return status of 0 in XeTeX
On Sun, 13 Mar 2016, Philip Taylor wrote: > "Make" (etc) are not really my concern, but the behaviour of TeXworks > is. If TeXworks can decide whether or not to conceal the log file based > solely on the status code returned by TeX (XeTeX, etc), then that status TeXworks is free to read the log file, just like everybody else has to to detect things like undefined references. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \(pdf)mdfivesum
On Thu, 2 Jul 2015, Joseph Wright wrote: Depends what you are using it for. Collisions are possible in MD5 so it's no longer suitable for cryptographic applications. Here, however, we are talking about avoiding the more prosaic issues of people having not-quite matching sources. (We are *not* talking about signing documents.) For the use case I have in mind MD5 will happily do the job. The message from Ross Moore to which I was replying specifically mentioned protection from modification by malware as a case where MD5 would be helpful, and that's what prompted my comment. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \(pdf)mdfivesum
On Thu, 2 Jul 2015, Ross Moore wrote: MD5 sums are also required pieces of data with some of the modern PDF standards, such as PDF/A, PDF/UA, and especially whenever attachments are included. They are part of the bookkeeping data that can be used to ensure that embedded files are indeed what was intended, and have not been intercepted and changed by Malware. If MD5 is necessary for compatibility with some existing standard, so be it; but it's not secure anymore and it shouldn't be used in any new design where there's a concern about possible deliberate tampering, as opposed to accidental errors. SHA1 is deprecated, too. I think SHA256 is the current best practice. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Σχετ: fontforge created characters in private use area
On Sun, 5 Oct 2014, Erich Hoffmann wrote: 14:57 GMT 31-Jul-2012 (this was taken from the fontforge homepage as fontforge_full-20120731-b.tar.bz2). Autotrace version is 0.31.1. , You may have better results going to the current FontForge home page at http://fontforge.github.io/en-US/ The one at fontforge.org is far out of date. I don't know why it's still online at all, but I think that has to do with the original developer retiring and walking away from it. More or less official FontForge support is now located at https://github.com/fontforge/fontforge If you were looking for the FontForge developers somewhere else, you probably weren't getting any responses. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [arXiv #128410] Re: XeLaTeX generated pdf metadata
On Tue, 23 Sep 2014, Ross Moore wrote: It is the insistence on being able to reproduce the PDF *automatically from source* that is where the problem lies. From reading Norbert's Web blog, it appears that that's also an issue for Debian packaging of TeX-related software. Debian has a formal requirement for everything that can possibly be built from source, to be built from source, and it's not practical to do that automatically with many TeX-related documentation files. My own horoscop LaTeX package, whose documentation requires many megabytes of astrological software (free, but not typically packaged by Linux distributions) to compile properly, is only one example. I think there are other packages that exist specifically to support expensive commercial products and require those products in order to compile, notwithstanding that the results of compilation are free to distribute. This kind of thing is definitely a problem; I'm not sure it is TeX's problem. As for arXiv, what bothers me is that in the case of XeLaTeX, they will accept neither the source code *nor* the compiled PDF. All an author can do is circumvent the rules by lying in the document metadata, or else go through contortions to compile a special arXiv-only version with some other software. I found this page helpful in my efforts to do that: http://member.ipmu.jp/yuji.tachikawa/cjk-on-arxiv/ -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeLaTeX generated pdf metadata
On Sat, 20 Sep 2014, Daniel Greenhoe wrote: I think my original email was not so clear. ArXiv.org of course accepts papers generated using LaTeX, but they want to be given the source files (.tex files, etc) rather than a pdf file. However, they apparently sometimes make exceptions to this rule if the pdf file was generated using XeTeX/XeLaTeX rather than LaTeX. That is, they *may* in at least some cases accept a pdf generated by XeLaTeX, but will *not* accept a pdf generated by LaTeX. This is a big issue for anyone who wants to submit papers containing CJK text. It's impractical to compile the papers with LaTeX (though that is what I've been forced to do, with a lot of font tomfoolery along the way); arXiv won't accept XeTeX output because they want the source instead; but arXiv also won't accept and compile the XeTeX source. It seems to me that the best thing would be for arXiv to install XeTeX and accept XeTeX source. But I wish I also had control over the metadata in my XeTeX-generated files - not to clearly indicate it's from XeTeX but to remove any trace of TeX at all. It's really none of arXiv's business what software I use, especially when they insist upon, but then reject, perfectly good XeTeX source code. Note that LaTeX is a macro package that runs on top of an engine like XeTeX. Properly speaking, most documents made with XeTeX are made with LaTeX. If you want to remove all traces of LaTeX from such documents and call them XeTeX, not LaTeX, it's also reasonable to remove all traces of any flavour of TeX and call them PDF files, deal with it. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX (/not/ XeLaTeX) : Marginal kerning, font protrusion, hyperlinks
On Fri, 25 Apr 2014, Philip Taylor wrote: (X)DVIPDFM(X). Since (X)DVIPDFM(X) is indeed an integral part of the XeTeX tool chain, I think that documenting how to access its functionality (with XeLaTeX is the integrated toolchain. If you're going to insist that XeTeX without LaTeX must be fully documented as a separate entity, then it only makes sense to do the same for XDVIPDFMX. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX (/not/ XeLaTeX) : Marginal kerning, font protrusion, hyperlinks
On Fri, 25 Apr 2014, Philip Taylor wrote: I'm sorry, what has LaTeX to do with any of this ? You don't want to hear about XeLaTeX, but you write: (X)DVIPDFM(X). Since (X)DVIPDFM(X) is indeed an integral part of the XeTeX tool chain, I think that documenting how to access its functionality (with The tool chain is XeLaTeX. LaTeX is just as much an integral part of that as XDVIPDFMX is. Users of this tool chain use all three together by typing a single command and don't care much which level executes which macro. It still makes sense to ask for documentation of each component alone, because people including yourself do also use the tools separately. But having made that request, integrated tool chain is not a sound basis to ask for documentation of a XeTeX and XDVIPDFMX but not LaTeX combination, which is neither the components alone nor the complete tool chain. It should be no surprise that documentation of pure XeTeX is documentation of pure XeTeX and does not include XDVIPDFMX features. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX (/not/ XeLaTeX) : Marginal kerning, font protrusion, hyperlinks
On Fri, 25 Apr 2014, Philip Taylor wrote: I'm sorry, Matthew, I can only think you are confusing XeTeX with some other system. Just because you can invent a silly-looking command line to make invoking XeLaTeX look more difficult than it is, doesn't make XeLaTeX stop being an integrated tool chain. However, it seems unlikely that either of us will be able to change the other's mind on this point. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] texlive and xetex
On Mon, 13 Jan 2014, C. Scott Ananian wrote: The latest debian and ubuntu contain texlive 2013. You can't get newer than than unless you have a time machine. Does running tlmgr work to keep it updated? -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] texlive and xetex
On Tue, 14 Jan 2014, C. Scott Ananian wrote: On Tue, Jan 14, 2014 at 9:53 AM, msk...@ansuz.sooke.bc.ca wrote: Does running tlmgr work to keep it updated? Running apt-get keeps it updated, and in some newer distros this is automated. Okay. What I was really wondering was whether that tracks the latest versions that would be available through tlmgr, or if there's a separate layer of packaging such that current Debain might not be as current as current TeXLive. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] texlive and xetex
On Tue, 14 Jan 2014, Stefan Solbrig wrote: Okay. What I was really wondering was whether that tracks the latest versions that would be available through tlmgr, or if there's a separate with Debian (even current) you will typicall not as up-to-date as with tlmgr. Debian (and also other distros that use regular releases) typically freeze all That's what I thought. In that case, the claim from C. Scott that The latest debian and ubuntu contain texlive 2013. You can't get newer than than unless you have a time machine. is unfortunately not true. TeXLive 2013 is a moving target, updated on an ongoing basis. You can, and many people need to, get newer than what's on the DVD or what's in a frozen package made on a specific date. do so-called rolling releases, like Gentoo or Arch. Running apt-get will *not* get you the lastest stuff from CTAN. It will only update the packages if there was a real bug. Unfortunately, I don't think Linux distribution packagers necessarily agree with the rest of the world about what constitutes a real bug; there's a fair bit of history of people using packaged versions from distros like Debian, finding them buggy, being told use the latest version! and replying But I ran apt-get! -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Combining pair of vowels to single base char in Hebrew
On Tue, 10 Dec 2013, Gildas Hamel wrote: When I transfer the text to my TeX editor (TextMate), the order and direction of consonants is correct but the order of the pair of vowels mentioned above (pataḥ and ḥiriq) is switched: לִירוּשָׁלִַם This is also true of my browser's rendition of the text (Safari 7.0)inhttp://www.stepbible.org/#!__/0/passage/2/OHB/Isa%2044/VNU/__/1/passage/0 /ESV/Isa%2044/NHV What version of XeTeX are you using? Are the fonts involved freely available? I suspect that the contextual substitutions in the font that doesn't work may involve ignore sub rules. The ICU library used by XeTeX until recently was buggy and couldn't handle those rules. Recent versions of XeTeX have switched to Harfbuzz, which handles ignore sub rules correctly, and the very latest version of ICU (no longer used by XeTeX) also has fixed its bug. ICU was used by a lot of other software besides XeTeX, including, I think, some browsers, so that could explain the same problem appearing in TextMate and the browser. Since the bug only affects certain kinds of contextual substitution rules that not all fonts use, that could also explain why some fonts work but not others. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
On Mon, 9 Dec 2013, Khaled Hosny wrote: U+E0001 U+E0065 U+E006E U+0073 U+0061 U+006E U+0067 And it is a kind of tagging, so beyond the scope of identifying the language of *untagged* text (which is the claim that spurred all this discussion). The claim was A properly encoded utf-8 string should contain everything you need!. If you forbid using Unicode tag characters, then you're saying It is impossible to encode language in Unicode when you're not allowed to use the features designed for that purpose, which is not an interesting statement. Yes, of course some kind of tagging is needed. Keith seems to think that the tagging will magically come from proper UTF-8, and of course he's wrong. I think language tagging would be possible in pure Unicode, as the string above demonstrates, but that's not a good way to do it. The really original question had to do with RTL versus LTR detection, not language detection, and that's a different issue. Unicode specifies a way to detect RTL versus LTR, such that in many cases it doesn't require tagging. Unicode's way of doing it may or may not be a good one, but we cannot reasonably pretend that it doesn't exist. The Unicode bidi algorithm does exist. XeTeX does not implement the Unicode bidi algorithm. The interesting remaining question is whether XeTeX should implement it. I tend to think not - because if we implement it, people will blame us for its failings. It'd also be a lot of work, break compatibility with the rest of the TeX world, STILL require tagging in many cases, and so on. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
On Mon, 9 Dec 2013, 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? No, I don't really do any work with RTL languages myself. Wikipedia's comparison list at http://en.wikipedia.org/wiki/Comparison_of_text_editors mentions several that claim bidirectional text support, but I can't speak to whether the ones listed there are any good at it. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
On Mon, 9 Dec 2013, C. Scott Ananian wrote: feeding the output to xelatex. That work won't help others who find themselves in a similar situation (or document authors who would prefer not to have to explicitly annotate every LTR embedding), but it The software also doesn't automatically determine which words should be set in italics, even though this policy is inconvenient for authors who prefer not to have to explicitly annotate it every time. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xetex and the unicode bidirectional algorithm.
On Tue, 10 Dec 2013, Khaled Hosny wrote: Now you beat Keith in Who Wrote The Most Nonessential Text In This Thread contest. Well, it's always nice to be a winner. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX -- arXiv.org
On Fri, 15 Nov 2013, Zdenek Wagner wrote: None of them says anything about Xe(La)TeX. If you try to submit a PDF generated by TeX, Arxiv will reject it with a moderately nasty message telling you to upload source instead. They process the source through (la)tex/dvips or pdf(la)tex. I'm not sure where that leaves submitters whose source really needs to be processed through some other TeX-family software, like Xe(La)TeX; and I'd like to know myself, because I'm currently working on a paper that is likely to end up falling into that category. (Written in English, on the subject of Japanese character databases; requires a custom OpenType font.) If the question is still unresolved as I get closer to being ready to submit my paper, I guess I'll approach the Arxiv administrators through their contact email. It would probably be possible to mess with the PDF metadata in such a way as to get a TeX-generated PDF past Arxiv's filter, but I imagine Arxiv would consider that abusive. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Large brace in multiline table cell
On Sat, 12 Oct 2013, BPJ wrote:
Can somebody help me on how to do the following with XeLaTeX,
or, if this is not the right place to ask this, where I should
ask this question?
A LaTeX-related mailing list might be better, since this question's answer
is unlikely to be specifically related to XeLaTeX. However, I don't know
off the top of my head which would be better.
I need to set a text (not math) table with two
columns where the left column contains linebreaks
and a 'stretchy' right brace along the right edge of the cell,
i.e. like so:
line 1 \
line 2 | General description of what
line 3 kind of things the lines
line 4 | in the left cell represent
line 5 /
More such rows with different numbers of lines
in the left cell.
Even though you say you want it to be text and not math, I think the
easiest way to do something like what you describe might be to start in
math mode. At the very least: you just can't have a stretchy brace as a
text mode glyph, they don't exist, so you have to set that one glyph as
math, manually scale a text-mode glyph, or use a graphics package like
TikZ to draw it, even if everything else is true text.
Try making the left column a table in itself, wrapped in \left. and
\right\} , something like this:
\[
\left.
\begin{tabular}{l}
line 1 \\
line 2 \\
line 3 \\
line 4 \\
line 5
\end{tabular}
\right\}
\parbox{2in}{General description of what kind of things the
lines in the left cell represent}
\]
Note that both tabular and parbox switch their contents into text
mode, which is what you want, even if the commands are used in
display-math mode. Having the outer level be display-math gives you the
centre-to-centre vertical alignment for free.
If it's important that the left column should be the same width for
several of these structures so that they line up, you could use an
appropriate p{} column specifier in the tabular instead of l. You could
also wrap this whole thing (possibly requiring some care in how you switch
to math mode, and the widths of the columns) inside a single multi-column
cell of a larger table, if you want to mix it with other more
straightforward constructions in a single larger table.
cells is set in the same fonts as the rest of the text. I doubt
that the braces are really needed for clarity, but it's in my
source so I have to reproduce it.
There is a package called schemata at
http://www.tex.ac.uk/ctan/macros/generic/schemata/
which is specifically designed for typesetting diagrams sort of like what
you describe, but potentially much more complicated, in historical
documents on Scholastic theology. I wonder if that's what you're doing?
Even if not, you may want to look at it. The schemata package doesn't
seem easy to use, and it's mostly but not entirely designed to put the
braces on the left instead of the right, but at the very least, the
examples in the documentation look cool.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Large brace in multiline table cell
On Sat, 12 Oct 2013, BPJ wrote: Yes that's the rub. I'm experimenting with the various suggestions right now, and one problem is that there is a lot of whitespace to the left of a table-in-a-table... It seems like it shouldn't be hard to insert negative spaces where required. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec and languages
On Wed, 11 Sep 2013, Javier Bezos wrote: Something like that but not the internal default language, but a default value in \defaulfontfeatures if the key is not given (ie, if there is no key 'Language', add 'Language=current-language' to the list). It sounds like you want a second level of really default font features, which won't be changed by \defaultfontfeatures. I don't see a reason for that to be specific to Language - to the extent this kind of feature is useful, I think it could be equally useful for any font feature. For instance, I might want to set the directory that contains my font files separately from other default features, and have it not change when other defaults are changed, so that it'll be easier to relocate a document to a different machine where the fonts are in a different directory. Even if such a thing is implemented in fontspec, though, there'll still be the possibility of users touching it when babel doesn't expect them to. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Letterly fonts
On Wed, 31 Jul 2013, Kai Hendry wrote: For example the above links has Hangul in the body which surprisingly isn't rendered by DejaVu font which should have a very wide range of Unicode glyphs. I do have ttf-dejavu, ttf-dejavu-core ttf-dejavu-extra installed. Be aware that supporting a language with a complex script involves more than just having a font that covers the right code points. In particular, the Unified Han character range is shared by Simplified Chinese, Traditional Chinese, Japanese, Korean, and historically Vietnamese. The same character codes should look different depending on which one of those you're writing. (See, for instance, slide 11 of this presentation: http://ansuz.sooke.bc.ca/temporary/2012-kanji-slides.pdf ) Usually a font will correctly support at most one Han-script language, and an out-of-band mechanism (in XeLaTeX, it'd be a fontspec option) is needed to choose between them even for the minority of fonts that support more than one. And Han isn't even a complex script in the specific technical sense of that term used by systems like OpenType. You're going to face some interesting challenges if you want this to work with Thai, Tamil, or Arabic, just to name a few. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] First message: Xelatex, pstricks and Mountain Lion
On Tue, 26 Mar 2013, a5mmdc9...@snkmail.com wrote: The user pr...@pjnetworks.com does not accept mail from your address. Hey, whoever's in charge, can something be done about this, please? -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] PDF V1.6 too recent
On Thu, 10 Jan 2013, Philip TAYLOR wrote: My Adobe Acrobat Professional is dated 2006; My XeTeX is dated 2011. Why does my 2011 XeTeX tell me that the PDF version generated by my 2006 Adobe Acrobat Professional is too recent ? Because it is? I'm not sure what kind of answer you hope to receive. Your Acrobat package is producing a version of the file format that XeTeX doesn't support. Support doesn't magically appear just because a certain number of years have passed, and being disappointed about that fact will not cause it to stop being true. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] PDF V1.6 too recent
On Thu, 10 Jan 2013, Philip TAYLOR wrote: Produce is the opposite of consume. As was clear from my original post, I would like XeTeX to /consume/ PDF 1.6 and not (necessarily) produce PDF 1.6. If the former can be Converting PDF 1.6 to a lower version is a very complicated operation and not one XeTeX is well suited to do. I don't think attempting to implement that conversion is a good use of XeTeX maintainers' time. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] PDF V1.6 too recent
On Thu, 10 Jan 2013, Philip TAYLOR wrote: but rather than PDF 1.6 as input is inconsistent with the default output PDF version, then I do think that a clearer diagnostic could be issued. E.g., ** WARNING ** Version of PDF input file (1.6) is newer than requested output version (1.x). I agree. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- 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. Why are you using morewrites?
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
--
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: 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? Usually the limit of 16 files is plenty. Combined with the strange errors regarding interpreting Postscript code, I wonder if those .tex files coming from Dia are actually using TikZ only incidentally, while doing a lot of complicated stuff of their own on the side. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Unicode 01F01B
On Wed, 19 Dec 2012, Steve White wrote: Mahjong Tiles = The glyphs in question, in the Mahjong Tiles range U+1f000 - U+1f02b are indeed very complicated. I personally spent a lot of time cleaning the glyphs up, and arranging for simpler representation. Still some of them contain the largest number of nodes of any glyph in the whole font. I wouldn't be at all surprised that they would cause some software to trip up. It appears, however, we still don't know what in the font causes the trip. The too many hstemh hints problem (that is a description of what's going on, not an exact error message - the exact error message is Stack got too big, with some additional consequences related to incorrect widths) is caused by whatever software saved the file saving more hints than the specification allows. It's not really caused by the glyphs being complicated and the reader tripping up, but by the *writer* writing incorrect values when the glyphs are complicated and certain other conditions are met. The data is actually bad, not just big; if some readers don't report an error it is because they are less watchful than they should be. FontForge was patched for it almost exactly a year ago, discussion here: http://sourceforge.net/mailarchive/message.php?msg_id=28442724 If the font file in question was created with a version of FontForge older than the patch, it should be re-saved with a newer version. If it was created with some other software, at least that discussion may provide some clues on what needs to be fixed in the other software. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Unicode 01F01B
On Tue, 18 Dec 2012, Khaled Hosny wrote: For a couple of releases now, XeTeX will always put the absolute path of the font in the XDV to avoid the recurrent problem with XeTeX and Does this make XDV files non-portable? It may be that getting the correct font, in the usual case of the XDV being generated and used immediately through a pipe on the same machine, is important enough that this is the Right Thing to do. But I am currently generating and using XDV files in separate steps on a single machine, and it's not hard to imagine someone wanting to do those in separate steps on separate machines. Device-independent files are no longer device-independent if they're tied to one host's filesystem. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Access of vertical CJK fonts preceeding with @
On Fri, 7 Dec 2012, Gerrit wrote: vertical Japanese texts (not just a paragraph or a text box, but the entire document): Everything like columns, page break, sections etc. would work flawlessly . Incorporating Western text in the text would also work without any problems. I think it's unlikely that the rotation hack's results would be flawless on any but the simplest texts. Among other things, vertical Japanese requires special line-breaking rules - such as period and comma protruding into the bottom margin if they would otherwise appear at the start of the next line. Vertical Japanese is usually set on a grid, both horizontally and vertically, and grids have always been a problem for TeX - it likes to make spaces stretchable and expand lines to accomodate math, all of which features have to be carefully tweaked to preserve a grid layout. Western text mixed in raises its own problems; depending on context it might need to be rotated or not, and the spacing rules for it are unlikely to match those of generic (La)TeX applied to rotated glyphs. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] how to do (better) searchable PDFs in xelatex?
On Sun, 14 Oct 2012, Peter Baker wrote: It's all in the font, really. If an OT substitution results in a character from the font's PUA being inserted in the character stream (except for a few standard ligatures), then the result will be broken searches. Because of Adobe encourages font designers to give glyphs names that reflect the Unicode code points (or sequences thereof) that the glyphs should represent in searches. If font designers did that, and if PDF readers looked at the glyph names according to Adobe's directions, then searches would work regardless of PUA use. However, not all fonts and not all readers do this. Some PDF readers will use the code points in the cmap table or equivalent in preference to the glyph names when cmap code points exist, so your recommendation of unencoded glyphs remains a good idea even when glyph names ought to resolve the issue. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, Options for all fonts, and the decimal comma
On Tue, 25 Sep 2012, Philip TAYLOR wrote: Thank you, Jonathan. I should have realised that allowing comma as a separator would prevent its use as a decimal separator. Ah well, there goes my resolve to be a Good European [tm]. I think TeX in general always uses . as the decimal separator, so for XeTeX to accept , would be a drastic innovation and would break scripts written for other engines. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, Options for all fonts, and the decimal comma
On Tue, 25 Sep 2012, Philip TAYLOR wrote: I think TeX in general always uses . as the decimal separator, so I'm sorry, Mathew, but on this one occasion you are wrong. TeX accepts both the decimal comma and the decimal point interchangeably in all constructs in which a decimal fraction Interesting. In that case, I imagine XeTeX's font syntax may have been modelled on TeX macro packages that use commas as separators. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] FreeSerif not working for me in Devanagari
On Fri, 7 Sep 2012, Zdenek Wagner wrote: requires newer version of fontspec. I am not able to compile the latest fontspec and replace it in my Linux version. Thus the only solution was to use the system Deja Vu fonts that produce different line breaks and different page breaks. Of course, for some fonts it would work. The same kind of problem can occur any time a document requires a new version of a package and you try to compile it on a system with an older version. I don't think that has much to do with font pathname specification, which I thought was the question. My claim was only that relative pathnames are useful and allow documents to be portable when they include their necessary fonts. Including the font with the document is the only real way to be sure that it can compile identically on a foreign system. If the document also depends on something else the recipient doesn't have, or if the recipient's system cannot process the font that the document requires, then I think it should be clear that using a relative pathname isn't going to magically solve the unrelated issues. This kind of thing - the idea that all documents should be compilable everywhere - is exactly why the TeX/LaTeX world have their Byzantine path-searching system, licenses that forbid modification unless you also change the filenames, and default we dare not EVER fix any bugs because we don't want to break documents that depend on them attitude. XeTeX seems not to be following that tradition, and the fact of using system-installed fonts which might not be consistent from one system to the next is just part of it. We can debate how important the absolute portability requirement is, but I doubt that XeTeX's approach is going to change soon. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] FreeSerif not working for me in Devanagari
On Fri, 7 Sep 2012, Zdenek Wagner wrote: If you use XeTeX this way, it is sufficient if it compiles and one person responsible for producing the final version will fine-tune the line and page breaks and lock it. I generally agree. This kind of thing can be carried too far, though. I recently needed to convert a document from LaTeX to Microsoft Word format. When I loaded the same resultant Word document on four different computers, no two of them thought it had the same number of pages (with a length difference of 15 pages between longest and shortest, on a roughly 400-page document), and on one, the whole thing came up in bold italics for no clear reason. I hope that XeTeX will always enforce better stability than that. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] FreeSerif not working for me in Devanagari
On Fri, 7 Sep 2012, Zdenek Wagner wrote: page breaks but will compile. If the font is loaded from a specific path and another user does not have the font in the very same path, the document will not compile. Of course, the best way would be if the If I need a document to be portable, I'll include the font file with it, and use a relative path such as ./. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Wed, 1 Aug 2012, Philip TAYLOR wrote: Is that not good ? Would Chinese calligraphy look anywhere near as beautiful if its glyph forms had been forcibly coerced into meeting the constraints imposed by movable type printing ? The question is whether the machine or the human being should be master. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Wed, 1 Aug 2012, Ulrike Fischer wrote: Perhaps (the discussion is rather long). But you obviously don't accept my conclusion that one possible solution is to reduce the complexity of the script. You are only looking for the people who should write all this complex code. Language is inherently political, and telling people to change their language to suit the computer is really asking for trouble. However, something that might fly better and addresses similar issues would be to say: requiring the typesetting system to build in per-script support is a losing game because it requires the builders of the typesetting system (who will be experts on computing, not on ALL the scripts of the world) to learn ALL the scripts of the world. It's also a political problem because some scripts, or some forms of some scripts, inevitably won't make the list of all scripts and will be disenfranchised as a result. So: this per-script knowledge should be moved from the typesetting system to the font, and then it becomes the responsibility of the font designers who more reasonably can be expected to be experts on their own scripts, and then nobody needs to be an expert on ALL scripts, and unforeseen scripts can be easily added just by creating new fonts. That is the line of thinking that would favour Graphite (a general system for defining complex scripts inside fonts) over OpenType (which requires each script to be defined in the typesetting system, outside of the font), and it should be acceptable both to people who want the technology to be easy to build and to people who want the output to look right. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Wed, 1 Aug 2012, Zdenek Wagner wrote: That is the line of thinking that would favour Graphite (a general system for defining complex scripts inside fonts) over OpenType (which requires That's right but we still have a lot of non-Graphite fonts. We also don't have much enthusiasm, as far as I can see, for emphasizing Graphite to the *exclusion* of other systems, in particular OpenType, as the preferred way for TeX engines to solve this issue. And that's what it would take. I think we're back to the question raised earlier: are we trying to build a really new thing, accepting the cost of throwing out and reinventing technology that already exists and works; or are we trying to build a thing that works with existing technology, accepting the cost that some of that existing technology isn't ideal? -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Wed, 1 Aug 2012, David Perry wrote: Yes, there are flaws in XeTeX, e.g., in connection with Hangul support. But I I think XeTeX actually works quite well with hangul if the appropriate features are turned on, and it sounds like their not being so was a bug that's easy to fix. It was already easy to work around. The glyph-pointer bug in ICU is rather more serious, but that is a general bug in all contextual substitutions that happens to affect hangul; it's not anything to do with hangul in particular and affects all other uses of contextual substitutions too (an example involving Greek was discussed on this list). -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Tue, 31 Jul 2012, Joachim Trinkwitz wrote: exceptional cases or for certain special needs like font variants, color etc. (OK, speaking from the perspective of a user who don't need languages with non-latin scripts …) There's the rub. Non-Latin scripts are a big part of the constituency of XeTeX. I routinely have to manually activate Korean-specific OpenType features that are specified to be default but that XeTeX/fontspec doesn't activate by default, just to get acceptable output in Korean at all. I'm just lucky there's an interface for doing that - more GUI-ish software without a raw feature interface would make it impossible. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Tue, 31 Jul 2012, Jonathan Kew wrote: On 31/7/12 13:26, msk...@ansuz.sooke.bc.ca wrote: There's the rub. Non-Latin scripts are a big part of the constituency of XeTeX. I routinely have to manually activate Korean-specific OpenType features that are specified to be default but that XeTeX/fontspec doesn't activate by default, just to get acceptable output in Korean at all. Which specific features are you referring to here? Maybe we can get this improved... ccmp - glyph (de)composition; and ljmo, vjmo, and tjmo - lead, vowel, and tail jamo shaping. It's possible that ccmp may already be default, and my own application doesn't actually need tjmo, but both should be turned on for Korean when available. Ligatures (liga) are also needed but presumably already default. There's some Microsoft documentation of these linked from http://www.microsoft.com/typography/otspec/featurelist.htm ; technical description of how my own Jieubsida fonts use them is included in the Tsukurimashou package user manual, available from http://sourceforge.jp/projects/tsukurimashou/releases/56223 Notwithstanding the slightly confusing description in the Microsoft documents (which describes more than one feature as overriding all others), these should be applied in the order ccmp, ljmo, vjmo, tjmo, liga. XeTeX does do the ordering correctly already; it only needs to have the features manually turned on. Honestly, the glyph-pointer bug we've already discussed on this list, http://tug.org/pipermail/xetex/2011-November/022298.html http://bugs.icu-project.org/trac/ticket/7753 is a bigger problem for Korean and I think a higher priority for fixing. But it will probably be harder to fix because it's internal to ICU. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Minimalist TeX?
On Tue, 15 May 2012, C Y wrote: environment wise...) If not, is there documentation anywhere of what constitutes the minimal set of files that will allow an average LaTeX document to be typeset? That is a lot like asking for the minimal set of files that will allow an average Linux software package to be executed. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and transparency
On Fri, 16 Mar 2012, Philip TAYLOR wrote: plain format, and thus any solution that is predicated on the use of (e.g.,) fontspec, LaTeX, XeLaTeX, ConTeXt, and so on, cannot be of use to me in my quest. Even if you don't actually load the packages, it may be worthwhile to examine the source code of the packages to see how they accomplish these tasks, and then imitate their techniques in your own environment. The packages could be useful in that sense. I think some of the low-level features of the XeTeX engine are only really documented in the source code of the engine and packages, and if you're comfortable working in a Plain TeX environment, the package source code may be easier to understand than the engine source code. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] List of ligatures in a font
On Thu, 15 Mar 2012, Philip TAYLOR wrote: ! Undefined control sequence. l.4 \defaultfontfeatures It is provided by the LaTeX fontspec package. Here we go again... -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] List of ligatures in a font
On Wed, 14 Mar 2012, d fulano wrote: how do I determine what are the standard ligatures in a font?It is not obvious (especially for non-English languages), and they can also vary in each font. Basically what I want to do is this:I can very quicky It will be tricky with OpenType fonts that have context-sensitive ligatures, because there may be many different sequences of input glyphs that activate a given output glyph, and the input sequences can be described in the font file in terms of matching patterns rather than a (potentially prohibitively long) explicit list of input sequences. If you think you can guess the input sequence by looking at the output glyph (as will be possible in many cases for Latin script), then you could simply list the output glyphs and not worry about reverse-engineering the tables to find the inputs; but that won't be a good assumption in the case of, for instance, jamo layout changes in Korean. Stuff like arbitrary-length fractions implemented by ligature-like substitution will give you a hard time as well. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] Windows views XeTeX PDF with bad font size
I'm sorry I don't have many details because it wasn't my own system on which the problem appeared, but: I have a PDF file generated with XeTeX (xdvipdfm), and a Japanese font embedded in the PDF. It looks fine on my screen (under Linux, with a couple of different viewers) and it prints correctly when I send it to my laser printer. But when my friend tries to view it on a Windows machine, he complains that there's not enough space between the characters and from the screen shot it's apparent that the viewer has scaled the font to a too-large size while still positioning each glyph at its correct reference point. As a result the glyphs touch and overlap. Most likely this is some problem with the Windows PDF viewer. I've seen similar things before though not as extreme as the current case - it may have some standard sizes, and round things to the nearest standard size even if that's a bad idea, as a result of trying to make pixel hinting look nice. But if there's anything I can change in the way I generate the PDF file (or by editing the font) to make this issue less likely to occur on Windows systems, it'd be valuable to know about. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Windows views XeTeX PDF with bad font size
On Sat, 18 Feb 2012, Jonathan Kew wrote: If you're in a position to edit the font such that it has a 1000-unit em square, this may resolve the incompatibility. It *is* a font with a non-1000-unit em, so that's probably the issue and editing the font is probably the right solution. It bothers me, because non-1000 values ought to be supported, but even if I and this one user can change our software, I need the font (which I'm designing) to work for other users both generating and viewing documents, and I can't expect the whole world to change software versions when there's a large installed base of viewers and XeTeX versions that don't work with non-1000 values. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Reducing ligatures in arabxetex
On Wed, 15 Feb 2012, maxwell wrote: The SIL Scheherazade font covers all the characters in the Unicode Arabic script block (not the presentation forms). Afaik, that includes all Persian (Pashto, Urdu, Punjabi...) characters, in the Naskh style. There are a few Arabic script chars used in African languages that it does not There's more to covering a language correctly than having glyphs for all the code points. Not all languages can use the SAME glyph for any given code point, and in scripts with complex layout there might also be differences in the layout features. This issue shows up especially often between CJK languages, but I imagine it would also be applicable between Arabic and Persian. It even shows up between English and German - the ligature rules are different even if the character set and glyphs are (almost) the same. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Using different fonts for devanagari and latin characters
On Sun, 12 Feb 2012, Zdenek Wagner wrote: The author has right to decide how his package can be used. If people are discouraged to distribute it, TL maintainers feel discouraged and do not distribute it. I am also discouraged, thus I only point to CTAN. I have tried this package with a few scripts and have not found any problem so far. We don't need to go through the discourage discussion again, but it does seem clear to me that it's only *modified* versions that you're discouraged from distributing, and distribution of *unmodified* versions is not discouraged. Much like a Creative Commons no derivatives license. Whether that's non-free depends on how important you think modification is to freedom; but I'm sure that if the TL maintainers distributed it at all then they would be distributing it unmodified, so it'd be silly of them to feel discouraged from doing that just because the author doesn't want them to do something completely different. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Warning about no Hindi language in Devanagari script
On Sat, 21 Jan 2012, Steve White wrote: There is one table concerning Sanskrit. As Hindi is transformation-wise simpler than Sanskrit, it uses only the default tables. So there are no tables that specifically refer to Hindi. FWIW, I've noticed a similar problem with FontForge. It has trouble applying OpenType features to some code points if the language it thinks uses those code points is not mentioned specifically in the tables, never mind that there is a default entry saying the feature should apply. I noticed this with Korean, but it seems to be a general issue. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Typographic question : quotation marks and apostrophes
On Sat, 17 Dec 2011, Tobias Schoel wrote: So we're back to the days, where one had to use escape sequences for quotation marks (\glq,\grq,',`,…) as though unicode had not included u2019. Even worse, because with OpenType some font designers might include substitution rules which include white space at font level. So, as an author, I have to bear in mind, that for one font I need to define \englishrightquote as u202f+u2019, and for other for another font I need to define it simply as It has always been the case that if you want an effect different from what was designed into the font, you had to do extra work. Letterpress shops used to have special tools for cutting and filing bits off of the metal type sorts in order to do special positioning of glyphs. There are some nice photos here: http://blog.typoretum.co.uk/2009/04/01/cutting-in-letterpress-accents/ It shouldn't be surprising that if you want to use a font other than in the way its designer intended, that requires some extra work and that that extra work is different on a per-font basis. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Typographic question : quotation marks and apostrophes
On Thu, 15 Dec 2011, Philip TAYLOR wrote: found on the ground floor, but I am not the author), the apostrophe of weaver’s/weavers’ is the same Unicode character as the closing quotation mark of windows’. Should it be ? I think that's the practice recommended by the Unicode Consortium. U+2019 is named RIGHT SINGLE QUOTATION MARK and bears the note this is the preferred character to use for apostrophe. The standard for TeX input is to use U+0027 for both, which also keeps them on the same code point. If we were setting metal type it seems unlikely we would have different sorts for the two purposes. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Typographic question : quotation marks and apostrophes
On Thu, 15 Dec 2011, Peter Baker wrote: apostophe and the closing quotation mark are the same glyph. We'd have to kern each instance manually. That said, it's pretty clear that we're stuck with what the Unicode Consortium has decreed for us. Old style and lining numerals are generally the same character codes as each other too, and we manage. I don't think that the fact of apostrophe and closing single quotation mark using the same code point is really a big obstacle to typographic effects that we might want to apply to them. A lot could be done with OpenType contextual substitution, though it might be better to use manually-selected alternates to convey the author's intention rather than guessing automatically. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] no small caps in GNU FreeSerif font?
On Mon, 12 Dec 2011, Daniel Greenhoe wrote: should be at U+1D00. But in Pagella-regular, U+1D00 is empty. Where are the small caps being hidden? Or are they algorithmically generated from the Latin capital letters? I think the officially correct way for an OpenType font to support small caps is for them to be unencoded glyphs, with no Unicode code points specified; then the smcp or similar feature will substitute them in where appropriate. If you have a font where they're unencoded, you're not going to be able to access them just by mapping code points to code points as teckit does. Adobe formerly used private-use code points in the range F761 to F77A for small cap glyphs. If you happen to have a font that encodes the small cap glyphs that way, you could get to them by mapping to those code points. The current versions of my own Tsukurimashou fonts use the Adobe code points for small caps because some of the build tools don't yet support unencoded glyphs, but I'm probably going to change that in the future. I think looking for small caps to have different code points is really the wrong way to do it - and that's why Adobe no longer uses those code points. U+1D00 is *not* a with a small cap style applied; it is a letter of the International Phonetic Alphabet. If you mean the letter a that we use in ordinary English, you should be writing U+0061; and the question of whether it looks Roman, Italic, small cap, or Comic Sans, should be determined by the font. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX and ignore sub substitution rules
On Wed, 30 Nov 2011, Apostolos Syropoulos wrote: did produce the expected results with say XeTeX that comes with TeXLive 2009. I will give more details later on. The item I found in the ICU issue tracker suggests the bug was introduced in their code base on October 28, 2008, so (given the delay between development and release versions) it's quite possible that the TeXLive 2009 XeTeX was built with a version of ICU from before the bug. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color
On Thu, 1 Dec 2011, Khaled Hosny wrote:
Suppose someone types
f\textcolor{red}{f}
In this case FireFox colourises half of resulting ff ligatures (1/3 in
ffi etc), I'm not sure how this is done or if it is possible with PDF at
I don't think XeTeX should attempt to do that.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, 1 Dec 2011, Philip TAYLOR wrote: ! Unable to load picture or PDF file 'Resources/Images/TAR-2.tex'. and no ! Unable to load picture or TeX file 'Resources/Images/TAR-2.tex'. It seems obvious to me that the command to load a PDF file and the command to load a picture are sharing an error message in order to conserve space in the string table. Rather than writing and storing two completely separate strings for these two similar errors, one error message that could apply to either of them was written and used for both. I've been programming for just under 30 years and certainly remember the days when string space was a precious enough commodity to necessitate such techniques; some people on this list may have even earlier memories. Today, we may be able to afford another 50 bytes or so to give more specific error messages to each of two closely-related errors. But note that adding another error message also means that any set of translated error messages also needs one more entry. It costs more work than just the 50 bytes of storage. I don't think that the fact the picture command says it cannot load a PDF file when, in fact, it cannot, is cause for much comment. And the fact it says it cannot load a picture or PDF file this time should not be taken as implying that that exact command might ever be able to load a PDF file at all. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX and ignore sub substitution rules
On Thu, 1 Dec 2011, Khaled Hosny wrote: On Thu, Dec 01, 2011 at 07:59:14AM -0600, msk...@ansuz.sooke.bc.ca wrote: The item I found in the ICU issue tracker suggests the bug was introduced in their code base on October 28, 2008 Link? Bug ticket: http://bugs.icu-project.org/trac/ticket/7753 This was initially reported in relation to GPOS tables but it seems to be the same problem I experienced with GSUB. The original submitter suggests this revision from 2008 is where it started: http://bugs.icu-project.org/trac/changeset/24903 -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color
On Wed, 30 Nov 2011, Khaled Hosny wrote:
processed by the layout engine, which would require keeping account of
character to glyph mapping (which is doable, all text editing GUI's have
to do it).
It will, of course, have to do something sensible (even if that just means
complain) should the desired location of a reinserted special end up in
the middle of a ligature.
Suppose someone types
f\textcolor{red}{f}
and the font tries to replace the two fs with an ff ligature. In that
case there is no sensible way to colour just the second one red.
Changing the colour of a mark and not the base is different from changing
the colour of just part of a ligature, and the system can certainly
distinguish mark-to-base from ligatures; but especially if colour is
handled by a special that the TeX engine only understands as an opaque
blob of data, it'll be hard for the engine to know what is the right thing
to do with the above.
In the Korean fonts I'm currently working on, some syllables are converted
to single precomposed glyphs by ligature substitution, and others are
built up by overlaying zero-width glyphs, and the difference between the
two ways of drawing syllables should ideally not be visible to the user.
(This approach is driven by Unicode, which specifies roughly 11000 code
points for entire Korean syllables, but a more complicated way of
expressing the several hundred thousand imaginable syllables that do not
have code points of their own.) The zero-width glyphs also change their
shapes contextually. Suppose someone tries to change the colour of just
one of the sub-glyphs in what would otherwise be a precomposed syllable.
Well, if that breaks the glyph sequence for the purposes of the ligature
substitution, it's actually a good thing. It means my font will fall
back on the overlaid zero-width glyphs, and then just the one the user
picked will change colour, and the user will get what they wanted. The
layout of the overlaid combination won't be quite as good as if the font
had been allowed to use a precomposed glyph, but there isn't really any
better way it could work.
Trouble is, the overlaid zero-width glyph method also depends on
contextual substitutions (because there are actually six different layouts
for an overlaid syllable, used to approximate the more nuanced layout
decisions that go into the precomposed glyphs). If the colour special
interrupts the glyph sequence for the purpose of those contextual
substitutions, then the font will end up falling all the way back to its
default layout (or, even worse, different layout guesses for different
parts of the same syllable) and the result will be unacceptable. The
ideal for my fonts would be if colour specials interrupted the glyph
sequence in the liga feature - thus preventing ligature substitution from
occurring - but not in the ccmp, ljmo, or vjmo features. What would be
ideal in some other font might be different from that.
I don't know the right answer to how it should work, but I'm highlighting
this issue just because I hope anyone who tries to implement a solution
will think carefully about the consequences for multiple cases.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color
On Wed, 30 Nov 2011, msk...@ansuz.sooke.bc.ca wrote: In the Korean fonts I'm currently working on, some syllables are converted to single precomposed glyphs by ligature substitution, and others are built up by overlaying zero-width glyphs, and the difference between the I was interested to test just what the effects of trying to colour part of a Korean syllable with my fonts actually were, so I did some experiments. Demonstration attached. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ colordemo.pdf Description: Adobe PDF document -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX and ignore sub substitution rules
On Tue, 29 Nov 2011, Khaled Hosny wrote: The same here, but I get the expected result (aBa, abc) with LuaTeX as well as HarfBuzz. I tested with another application using ICU layout engine (fontmatrix) and got the same result as XeTeX, so I think it is an ICU bug. On further testing, I don't think Apostolos's font works with XeTeX either. It may appear to at first glance, just because the effect of the ignore sub rules in that font is very subtle, but if I modify the alternate glyphs to be more obviously different, it's clear that they are being put in in cases where the rules say they shouldn't. I think I've also figured out just what XeTeX (presumably ICU) is doing wrong: it is failing to move the glyph pointer ahead on a successful match. As a result, later rules in the lookup still have the chance to match again on the output of earlier rules, and ignore sub rules have no effect. I remember that you once commented that my Terrible Secret article was wrong because I'd documented this behaviour, and this explains the disagreement - I was documenting what I'd observed XeTeX to do, and at the time, I hadn't tested ignore sub rules and didn't realize that it was incorrect behaviour by XeTeX and would be a problem for ignore sub rules. Some of my own code both in that article and in my actual fonts depends on the later rules see output of earlier rules behaviour and will have to be fixed, but there's no help for that; it's more important to have ignore sub work. I will attempt to navigate ICU's bug tracking system and submit the bug to them. I don't know if XeTeX's practice is to track updates of ICU, though. Unfortunately, it appears that in the short term I have to not only do without ignore sub, but also do without later rules seeing the output of earlier rules, because I need my fonts to work both with widely-deployed XeTeX and with correct implementations. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX and ignore sub substitution rules
Here's a stripped-down example of the problem. The attached OTF font
contains rules in the clig feature saying that a b should be replaced
by a B (i.e. the b is changed to upper case) except when it is followed
by c. For greater clarity, the feature file is also attached. Testing
in FontForge's metrics window requires me to manually turn on clig
(which should be on by default) but with the feature turned on, the
substitution and non-subsitution happen as expected.
When I run the attached .tex file through XeLaTeX with the attached font,
aba becomes aBa as it should, but abc becomes aBc, whereas
FontForge leaves it as abc (which I think is correct). The ignore rule
doesn't seem to be processed by XeTeX.
Confirmed on a couple of different installations, but I'd be interested to
hear whether it happens for anyone else. Apostolos Syropoulos sent me a
font using ignore rules and reported to work correctly, but I haven't
finished testing myself whether that one works for me.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
testfont.otf
Description: Binary data
languagesystem DFLT dflt;
languagesystem latn dflt;
feature clig {
ignore sub a b' c;
sub a b' by B;
} clig;
\documentclass{article}
\usepackage{fontspec}
\begin{document}
\setmainfont[Path=./]{testfont.otf}
aba
abc
\end{document}
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XETEX cannot access OpenType features in PUA?
On Sun, 27 Nov 2011, Aleksandr Andreev wrote:
I figured out the issue. They work if the entire text is in black, like this:
{\moo \Huge }
I've been watching this discussion with interest, having had similar
problems. I thought the colour thing might be an issue - very likely
XeTeX is putting the contents of the color command in a separate box and
thus breaking up the stream of glyphs going to the OpenType substitution -
but when I tried (with your earlier font) eliminating the colour change,
the problem remained, so I didn't post to the list about it.
Something to be aware of is that FontForge's handling of OpenType
substitutions seems to be buggy, especially if Adobe-format feature
files are involved in the workflow. Your problem seemed to be one where
FontForge was rendering the substitution correctly and XeTeX wasn't; but
I've also seen cases where XeTeX does it right and FontForge doesn't, and
where a feature file, loaded into FontForge, seems to produce correct
results, but then when I save the feature file from FontForge, the result
is garbage. Anything that combines GSUB substitutions with GPOS
positioning seems to be hard to get right. All in all, I don't think
FontForge can be used as a good reference point for debugging other
software's handling of substitutions.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XETEX cannot access OpenType features in PUA?
On Sun, 27 Nov 2011, Aleksandr Andreev wrote: It appears that XeTeX colors are handled by inserting pdfliteral nodes around colored items, which breaks the access to GPOS. Unless there's been some work on this issue since 2007, it appears that I will need to look for a different way of typesetting my document. I bet you'll see similar effects on other systems, too. I'm actually surprised that Firefox seems to work the way you want it to; I've seen (for instance, in the page at http://www.uni-graz.at/~katzer/korean_hangul_unicode.html - right now I'm working on implementing conjoining behaviour of Korean letters via GSUB) HTML markup being used explicitly for the purpose of breaking up glyph sequences that would otherwise be subject to Unicode conjoining behaviour, and I would expect it to usually have that effect. If there's a style of any kind applied to one glyph and not to the previous glyph, there's good chance that software in general, not just XeTeX, will break the glyph sequence and not see substitution rules that would apply to the glyphs if they were really adjacent. If it's important to be able to style one glyph and not another, then I think you're asking for trouble to also depend on a substitution rule matching them both. Many people have had similar problems with the fact that software (in general, not just XeTeX) usually doesn't treat space as a glyph even if you define such a glyph in your font; as a result, substitution rules that try to match a space glyph (for instance, to recognize starts and ends of words, or to carry state-machine information across word boundaries for things like pseudorandom alternate-form substitution) rarely work. You can find some discussions of that by searching on the Typophile forums; some places where someone would want a space glyph for substitution can be implemented using ignore rules instead, but others seem not to be reliably doable in OpenType at all. Part of the OpenType base/mark concept seems to be that a mark becomes part of the glyph is it marking (it can be seen as a special way of implementing, internally to the font, what would otherwise be a single precomposed glyph), so if it is part of the semantics of your musical language that the marks are separate objects and can be individually selected for the purposes of things like coloring, having them be marks may not be ideal. Can what you're trying to do be implemented by zero-width negative-bearing glyphs instead? Folks on Typophile seem to turn up their noses at those, but I've had good results with them and they seem to be more reliable than mark-to-base. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] XeTeX and ignore sub substitution rules
It appears to me that XeTeX doesn't handle, at all, OpenType context substitutions that match without doing a substitution - i.e. the ones that appear in Adobe feature files as ignore sub rules. When one of these matches, the renderer is supposed to skip the remaining rules in the lookup. XeTeX doesn't seem to, resulting in incorrect substitutions. Although, as I recently mentioned, I don't trust FontForge 100%, FontForge does seem to work correctly on the particular case I'm looking at right now. I don't have a minimal example yet (where I'm actually observing the problem is in the middle of a complicated set of substitutions with a lot of other things going on, which is part of what's making debugging hard) but I may try to construct one. On the other side, I haven't seen an example where ignore sub rules *do* work in XeTeX. Has anyone on the list got an example of a font where XeTeX correctly processes context substitutions that include rules of this type? Since I'm the designer of the font that's failing for me, I think I can work around the absence of ignore sub by creating a set of alternate glyphs that terminate substitution - where I would use ignore sub, I instead substitute to the special alternates, and then I just never write any rules that can match those glyphs as input. The number of glyphs involved is small enough not to be a hardship. If it's really true that XeTeX cannot process ignore rules, though, that will seriously limit its ability to work with other fonts out in the wild that may depend on such rules. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] U+00AD
Since we're having so much fun with U+00A0, what about U+00AD, which may or may not mean the same thing as \- ? -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] nbsp; in XeTeX
On Mon, 14 Nov 2011, Petr Tomasek wrote: Not in every case. How would you visually differentiate between all the white space characters (space vs. non-break space, thin space (u2009) Using different color. About 8% of men have some form of colour blindness (the prevalance is much lower, but still nontrivial, in women), and it's a basic rule of interface design that although colour is valuable as an adjunct to other ways of presenting information, important information must never be conveyed *only* by colour. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] Whitespace in input
I think this discussion is bogging down because several different questions are getting mixed together. Here's what I see as the major issues: 1. Does Unicode specify a single correct way of representing white space? 2. If an input file to XeTeX contains currently less common Unicode whitespace code points, such as U+00A0, what should XeTeX do? 3. Should users be encouraged, or even required, to include those code points in input to XeTeX, in order to achieve typesetting goals that in older TeX engines were achieved by other means? 4. Since many editing environments make it inconvenient to process currently less common Unicode whitespace code points, what should users do if the answer to #3 is yes? Now, separate from identifying what the questions are, here's what I think are reasonable answers to the questions: 1. No. That is not what Unicode is for. Unicode's goal is to subsume all reasonable pre-existing encodings. Some reasonable pre-existing encodings include a non-breaking space character, so Unicode includes one. That does not mean Unicode says you should actually use it! There are many precedents of Unicode providing multiple ways of representing things, as a result of including characters from other systems, without it being reasonable to demand that all Unicode-compatible systems must support all of them. For instance, most of the U+FFxx range is devoted to different kinds of hacks for handling partial-width characters in Asian-language typesetting; the preferred way to do that nowadays is via OpenType features, but the code points remain in the standard. The U+ to U+001F range is basically control characters for Teletype machines; some of those, like U+000A and U+000D, are widely used in modern documents (but in varying ways by different systems!) and others, like U+001D, are virtually unheard-of. Unicode does NOT say everybody has to support them all let alone all in the same way. The U+00A0 code points is not explicitly deprecated in Unicode, but it was never a principle of Unicode that all implementations have to support all defined control characters regardless of appropriateness to the particular purpose. Non-breaking space is, from TeX's point of view, not really a character at all, but a formatting command; and TeX already has a way of dealing with formatting commands in general and this one in particular. It is appropriate to say that the preferred way of handling non-breaking spaces in TeX input is the existing TeX way; and saying that in NO WAY AT ALL contradicts anything in Unicode. Unicode is servant, not master. 2. Inevitably, people will include invalid characters in TeX input; and U+00A0 is an invalid character for TeX input. The best way to deal with it is to treat it like any other invalid character and generate an error message. A reasonable alternative would be to say it is whitespace; it will be treated like other whitespace. That would mean ignoring its breaking/non-breaking-ness, as we have for a long time similarly ignored the special properties of U+0009 (tab). Of course, if users want to define a special meaning for U+00A0 in their own input, they can do so with the existing mechanisms for redefining the meanings of input characters; but U+00A0 is equivalent to U+007E (~), for instance, should never be the default and (because of trouble displaying it) shouldn't be encouraged. 3. No. Better to keep everything visible and backward compatible. U+007E (~) should remain the preferred way of doing non-breaking space. 4. Not applicable because of the answer to #3. Users who do insist on putting U+00A0 in their input presumably have *already* got their own reasons to think that it's more convenient for them, including solutions satisfactory to themselves for how to type it on keyboards and see it on screens, so that's their business and not a problem we need to solve. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
On Mon, 14 Nov 2011, Philip TAYLOR wrote: 2. Inevitably, people will include invalid characters in TeX input; and U+00A0 is an invalid character for TeX input. Firstly (as is clear from the list on which we are discussing this), we are not discussing TeX but XeTeX. Secondly, even XeTeX is a TeX engine. Obviously, it is free to define its own input format, and that format already differs from other TeX engines by (for instance) allowing some Unicode code points outside the 7-bit range. But I still see XeTeX as a version of TeX, not something completely different, and it's appropriate for expectations we might have about TeX - for instance, the expectation that formatting commands are visible and the non-breaking space formatting command is ~ - to also apply to XeTeX where they are appropriate. if we were discussing TeX, on what basis do you claim that U+00A0 is invalid ? And if you assert that it is, /a priori/, It's invalid if XeTeX says it is invalid, and I think XeTeX should say it is invalid. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
On Mon, 14 Nov 2011, Philip TAYLOR wrote: I think (with respect) that some Unicode code points outside the 7-bit range is a gross understatement. As far as I am aware, XeTeX permits a very considerable subset of Unicode (perhaps even all of it; I do not know) as input. My point is that it shouldn't treat U+00A0 as equivalent to U+007E, or as valid at all, just because it supports Unicode. That is not what supporting Unicode means. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Whitespace in input
On Mon, 14 Nov 2011, Karljurgen Feuerherm wrote: I use U+12000 and above regularly, as a case in point... Do you think that basic formatting control functions should be bound to code points in that range, as the preferred way of accessing those functions? Let's not lose track of what this discussion is about. XeTeX can *with appropriate font support* accept nearly any Unicode point in its input. But very few Unicode points are treated specially by XeTeX as such, and I don't think U+00A0 should be one of them. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] nbsp; in XeTeX
On Sun, 13 Nov 2011, Petr Tomasek wrote: make ~ not active when writing my own macros because it contradicts the Unicode standard...) Isn't it just as much a contradiction of the standard for \ to do what \ does? I don't think that is a good way to decide what TeX's input format should be. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] XeTeX/TeX Live : Setting the default language
On Fri, 4 Nov 2011, Mojca Miklavec wrote: corrections submit PDF for printing ... and that friend has set French or Russian as his default/preferred language, so the printing house will print the document typeset with Russian hyphenation patterns. Wouldn't that be nice? This kind of problem already exists for anyone who exchanges documents between North America and the rest of the world, because of default A4 versus letter paper sizes. That's bad enough. You're right that adding hyphenation patterns as yet another thing we have to negotiate and carefully override on every document, wouldn't be a good idea. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] XeTeX/TeX Live : Setting the default language
On Fri, 4 Nov 2011, Reinhard Kotucha wrote: As far as paper size is concerned, as mentioned by Matthew Skala, this information belongs into each document too. However, there are some situations where default settings can be useful though, for instance if you exchange TeX source files with Americans. However, this requires a well designed page layout which yields good results on both, A4 and letter paper. Paper size is special because if you compile your document for the wrong paper size and send it to a printer, at many sites that will cause the printer to stall and demand operator attention while other documents pile up in the queue. Incorrect hyphenation doesn't have that effect. In a multiuser environment it's a given that people *will* leave things on the defaults, whatever those may be; and you can't have queue stalls many times every day just to preserve the purity of the metadata in every document model. Administrators will implement a site-local default for paper size whether they should or not. Getting the right set of hyphenation patterns can be more safely left to the users. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, 2 Nov 2011, Philip TAYLOR (Webmaster, Ret'd) wrote: Fortunately, FMi and others were able to convince him that he was wrong, whence TeX 3. Now we clearly need to start on Adobe (and Heiko !). If Ross Moore's and other recent technical postings are to be believed, this is a non-issue. The file format already allows arbitrary byte sequences in the field we're talking about, on top of the fact that that field isn't exposed to readers and doesn't limit the language of documents at all. If the ASCII link anchor limitation existed in PDF it would be not much different from the genuine limitation that object ID numbers must be integers even if you would prefer to make them text. Link anchors are internal codes; they are not text at all, and it's not reasonable to demand that they must be UTF-8-encoded text in particular. But PDF doesn't actually limit link anchors to ASCII anyway. As far as PDF is concerned (according to recent postings on this list) you can use UTF-8. The fact that you can't do that with TeX is TeX's fault, and relates to the issue Heiko Oberdiek described that TeX can't write arbitrary byte sequences in all contexts. He also suggested some possible workarounds that someone could implement if it were important to do so; but it really isn't. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Future state of XeTeX in TeXLive
On Fri, 28 Oct 2011, William Adams wrote: majority of documents are created using GUI tools. What use cases are better served by batch mode, and in what cases is TeX used by default because of available GUI tools refuse to play. Large database publications. Variable data printing. Also, anything where documents end up checked into the source control and configuration management systems used for software development. It's really nice to be able to compile my TeX documents along with my code. I can't do that with GUI tools. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Performance of ucharclasses
On Wed, 26 Oct 2011, Philip TAYLOR (Webmaster, Ret'd) wrote: He does /not/ deny you the right to do so; he discourages you, which any competent native speaker of English would recognise as being completely different. I'm sure any competent lawyer will tell you that if you do something that has been discouraged by the person whose permission is required for it, then you're asking for trouble even if your actions have not been literally forbidden. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Compatibility issues with ednotes and pstricks or TikZ
On Fri, 23 Sep 2011, VAFA KHALIGHI wrote: When I started as the maintainer of bidi, I contacted some of the package/class authors unfortunately no one even bothered to reply back (at least saying, no I do not have time or I do not know how to do it) and indeed that is why bidi itself, support so many packages. Knowing that your attitude is that compatibility is everybody else's job and not yours, I sure wouldn't have been quick to reply to you if I were one of those package maintainers. Perhaps it's not really what you meant to say, but when I read this comment of yours: it is not the duty of bidi package to add support for other packages but other packages themselves have to add bidi support. bidi should only support it created a very negative impression. I get the idea that some of your difficulties with other package maintainers may be to some extent of your own making. My own point of view is that compatiblity should involve effort and accomodation on *both* sides. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] fontspec's \setmathrm seems to have no effect
On Thu, 1 Sep 2011, Peter Dyballa wrote: So instead of the \setmathrm giving me the font I requested, I seem to be getting a computer modern font. Why would this be??? Because you don't set your maths in \mathrm! The default for maths is a sans-serif font, because the text usually consists of a serif font. It depends which symbols you're talking about, but variables in math (at least in English-language documents) are normally set in italic by default. Roman is typically used for function names like sin and log. Sans-serif is rarely used in math; when it is, it's often for special kinds of variables, such as vectors (though other conventions are more popular for indicating vectors). -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] epsdice package.
On Sat, 16 Jul 2011, Peter Dyballa wrote: like hay (or some other form of money) or different, like in German for example? (That's the reason IPA was invented: it's completely clear.) I think the point Michael was making is that because Cherokee is already written in a phonetic script, transliterating it into a different phonetic script the students don't know and don't need to know and requiring them to learn that on top of the script they actually want to learn, would be counterproductive. Bear in mind that the audience for his project is not linguists who might already know IPA, but language learners. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Loading fonts from a common server or http URL
On Thu, 23 Jun 2011, Keith J. Schultz wrote: I was not talking about implementing a full http-client. I don't see how the system can reliably download files from http: URLs without being or using a full HTTP client. That's the point I was responding to. If your main point was something else, fine. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Roman Numerals as stylistic alternatives
On Sun, 19 Jun 2011, Tobias Schoel wrote: if I understand correctly, that way the output still shows the letters or the deprecated unicode codepoints. It should be analog to medieval / lowercase numbers. E.g. it's still the number 123 it only uses different glyphs. So when I copypaste it, it shows the number 123 and not cxxiii. I think the only plausible way for that to happen would be for it to be a feature of the font, specifically a type of ligature substitution that replaces the numeral glyphs with appropriate other glyphs while naming them such that reader software can determine the original sequence of code points. If it's built into the font as an OpenType feature, then you could turn it on with fontspec. But it would be a feature of the font, not a feature of fontspec; wanting fontspec to do it in a font that doesn't have such a feature built in would make about as much sense as wanting a fontspec feature to enable Tamil script in a font that only contains Latin glyphs. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
