Re: [XeTeX] Σχετ: Re: Σχετ: Re: Off topic (interesting) question
> I have no axe to grind in this intra-Hellenic debate, but may I ask the > two protagonists whether they view the current American practice of both Come, come: you mean "the protagonist and deuteragonist" !
Re: [XeTeX] Σχετ: Re: Σχετ: Re: Off topic (interesting) question
On 2022-08-20, Apostolos Syropoulos via XeTeX wrote: > My question is if English language speakerslearn in school why they write > history andnot istory. The answer seems to be: No.What you say is completely What do you expect us to learn? The word is pronounced with /h/ and written with h-. It's written with h- because we borrowed it from languages which wrote it with h-, some of which pronounced it (classical Latin, Greek) and some of which no longer did (French); we borrowed it in writing and pronounced it accordingly. That doesn't seem like something one has to learn - it's the obvious. What one has to learn is why we write some words with an h that we *don't* pronounce. The answer to that is a fairly complex sociolinguistic explanation plus random chance in evolution.
Re: [XeTeX] Problem with ifpdf switch
On 2020-07-06, John Was wrote: > On acquiring a new PC I decided to install the latest TeXLive (previously I > was on the 2013 version). I use plain XeTeX. To my surprise, the first > page now has at the top the text: > > ifpdf [2016/04/04 v3.0 Provides the ifpdf switch] > > See the attached one-page PDF. > > Below I give some lines from my log file - it's the last line that is of > interest, viz.: No, that's not the line of interest. The lines of interest are all the other files you might have loaded that might cause this breakage. The line you see is, naturally, coming from ifpdf.sty, and to see it, something must have broken the \ProvidesPackage, messed with catcodes, or done something else to cause the break, unless the (rather old) ifpdf.sty itself is buggy, which seems unlikely. Please construct a minimal (non-)working example, and post the full log file, with links to all non-standard files loaded. Unless of course somebody jumps in to say they recognize the problem!
[XeTeX] mktexfmt fail on non-letter
I just ran xetex for the first time on my work desktop, which is running RHEL7 Linux, with a texlive 2018 distribution. Making the .fmt file failed owing to numbers in hyphenation patterns in three languages: for example: (/opt/texlive/2018/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-cu.tex UTF-8 Church Slavonic hyphenation patterns (/opt/texlive/2018/texmf-dist/tex/generic/hyph-utf8/patterns/tex/hyph-cu.tex ! Nonletter. l.41 .а҆кта́7ꙋ ? ! Emergency stop. l.41 .а҆кта́7ꙋ No pages of output. Transcript written on xelatex.log. Presumably this doesn't happen to other people, so what could be causing it? Checking the log, it's loading all files from the right place - no shadow files anywhere. For the moment, I've solved it by shadowing the three offending hypenation files with empty files, but I'd like to understand!
Re: no more subject prefix for xetex mailing list
On 2019-03-05, Zdenek Wagner wrote: >> > And the last thing, setting of DMARC at tug.org is wrong, the DNS >> > query returns the SPF record, not the DMARC record. >> >> No, it isn't wrong - there is no setting for DMARC. >> A dns query for _dmarc.tug.org TXT records returns two records: >> >> _dmarc.tug.org. 8555IN CNAME tug.org. >> tug.org.8555IN TXT "v=spf1 a a:freefriends.org >> mx:freefriends.org a:fencepost.gnu.org include:_spf.google.com ~all" >> >> tug.org has a wildcard CNAME *.tug.org -> tug.org (which strikes me as >> bad practice, but not wrong). >> >> DMARC does not specify whether CNAMEs should be followed, but even if >> they are, DMARC only looks at valid DMARC records. >> > Yes, there is CNAME but it refers to a SPF record, not to DMARC > record. DMARC should contain a different type of information with a > different syntax. It seems you understand the DNS no better than DMARC. A CNAME record is an alias, and it does not refer to an SPF record. The CNAME redirects the name *.tug.org (including _dmarc.tug.org) to tug.org . Since TUG has SPF set up, there is a TXT record at tug.org containing SPF information. There could be many other TXT records at tug.org, as well as A, MX and other records. Hence a query for TXT records at _dmarc.tug.org returns the information that there is an SPF TXT record at tug.org . It does not return any DMARC TXT record, either at _dmarc.tug.org or at tug.org . Thus DMARC correctly concludes that tug.org does not have DMARC set up. Having just checked the DMARC wiki, I find that CNAMEs are expected to be followed when looking up DMARC records. So now tug.org could do two thing to deploy DMARC - it could attach a DMARC TXT record to tug.org, in which case lookup for _dmarc.tug.org wil find that via the CNAME; or it could - correctly - put the DMARC record at _dmarc.tug.org, in which case lookup for _dmarc.tug.org will find that record directly, as wildcard CNAMEs are not applied to any domain for which a real record exists.
Re: no more subject prefix for xetex mailing list
On 2019-03-05, Zdenek Wagner wrote: [ Please don't top-post. ] > Now assume that someb...@nodkim.org sned a mail to the list. > @nodkim.org has neither DKIM nor DMARC. The mail is distributed to the > subscribers. SPF passes, @nodkim.org does not provide DKIM and there > are no headers. There is thus nothing to verify and the recipient just > reports that SPF passes, there is nothing else what can be done. > Rewritingt From does no harm but it is of no use. Correct. > Now assume that u...@example.com does the same but @example.com > defines DKIM and DMARC. The message is signed, the list of signed > headers is defined by @example.com. This mail is then distributed to > subscribers and some headers are added and/or modified. The > subscribers first verify SPF which passes. Further it finds the DKIM > headers. They contain the identifier of the key. The ley id and the > domain name define the URI of the TXT record containing the public key > and the list of the headers that are signed by the original sender. It > is possible to signed an empty (missing) header which means that the > mailing list is not allowed to add such a header because it > invalidates the signature. > > * If the mailing list adds/modifies headers that were not signed by > the original sender, the signature remains valid and DKIM passes. > * If the signed contents is modified, the signature is no longer valid > and DKIM fails DKIM verification of that signature fails, yes. > 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. If you don't also sign the modified message with a TUG key, DKIM fails; but for DMARC purposes, since the signature is not from the From: domain, it's the same as a missing signature. > 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 No it can't. DMARC passes if at least one of the Authenticated Identifiers passes. There is no mechanism to require both SPF and DKIM to pass (though you can request reports of failed signatures even for messages that pass DMARC). Your own mail server may internally choose to reject messages that fail DKIM, but that's not part of DMARC. > If the From header is rewritten to someth...@tug.org and DMARC at > tug.org is set to the former option, the result will be SPF PASS, DKIM > FAIL, DMARC PASS and the recipients will thus silently accept mails > with invalid signatures. This overcomes the problem with DKIM but IMHO > allowing to accept messages with invalid signatures is not the right > way. The mailing list must remove existing DKIM signature, change the >>From header and then either provide its own DKIM + DMARC and sign the > mail or do not provide them at all and rely on SPF only. This is what I said - it is a good idea to clean out any invalid signatures. But failing a signature from example.com will not affect the DMARC checking for tug.org, and in real life, quite a few messages arrive with some broken signatures, because of mailing lists, forwarding, character-encoding changes, and so on. > And the last thing, setting of DMARC at tug.org is wrong, the DNS > query returns the SPF record, not the DMARC record. No, it isn't wrong - there is no setting for DMARC. A dns query for _dmarc.tug.org TXT records returns two records: _dmarc.tug.org. 8555IN CNAME tug.org. tug.org.8555IN TXT "v=spf1 a a:freefriends.org mx:freefriends.org a:fencepost.gnu.org include:_spf.google.com ~all" tug.org has a wildcard CNAME *.tug.org -> tug.org (which strikes me as bad practice, but not wrong). DMARC does not specify whether CNAMEs should be followed, but even if they are, DMARC only looks at valid DMARC records.
Re: no more subject prefix for xetex mailing list
In mail.xetex, you wrote: > Hi all, > > mere rewriting of the From header will not work. There are four beasts > involved: Yes it will. It's what I successfully use for my user(s) who want their mail forwarded to gmail, and if it works for that, it works for anything! > The recipient sees that MAIL FROM says that the mail came from > tug.org. It thus looks at DNS, finds the SPF record (in fact a special > type of TXT) and verifies whether the IP address is in the list of > allowed servers. This is configured correctly at tug.org hence SPF > passes. However, this is not an SPF pass for DMARC purposes, because DMARC only considers an SPF pass when the From: address "aligns with" the envelope sender (which usually means being the same domain). > DMARC is a more flexible way superseding ADSP. It looks both at SPF > and DKIM and then decides what to do. Remember that DKIM as well as > DMARC are defined by the mail systems of the original senders hence > tug.org cannot do anything. In addition, it is not known which eaders > are included in the signature. But DMARC only looks at the policy of the From: address, so if you rewrite the From: address to a tug.org address, tug.org's DMARC policy will be applied. It doesn't matter that the message now fails the original DKIM signature (though for cleanliness it's better to remove the broken signature). So re-writing the From: address should solve the problem. In addition, DKIM-signing the (modified) message with a tug.org key will increase the chance of the message not being diverted to spam folders.
Re: [XeTeX] ifcat changed?
On 2017-04-16, Zdenek Wagner wrote: > 2017-04-16 10:08 GMT+02:00 Julian Bradfield : >> Definitely a bug. The TeXbook defines the behaviour of \if and \ifcat, >> and all control sequences are considered to have character code 256 >> and category code 16, unless \let equal to a non-active character, in >> which case they have the value of that character. >> >> Not all control sequences but primitives. Unlike \ifx, \if and \ifcat > perform full expansion. (a) Yes, they do perform expansion. That's irrelevant to the point at hand, since expansion happens before the comparison. (b) All control sequences, not just primitives: \ifcat\noexpand\foo\noexpand\baz true\else false \fi \ifcat\noexpand\foo\halign true\else false \fi As Philip pointed out, I was reporting Knuth's words, which are by definition authoritative. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] ifcat changed?
On 2017-04-15, Bruno Le Floch wrote: > The primitive conditional "\ifcat\relax\cr true\else false\fi" gives > "true" in pdfTeX, LuaTeX, (e)(u)pTeX, and XeTeX from some time ago > (could be years), but "false" in XeTeX 0.6 Definitely a bug. The TeXbook defines the behaviour of \if and \ifcat, and all control sequences are considered to have character code 256 and category code 16, unless \let equal to a non-active character, in which case they have the value of that character. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Overfull boxes return status of 0 in XeTeX
On 2016-03-13, Philip Taylor wrote: > I respectfully disagree. I am advocating the philosophically correct > approach, requiring a small amount of work by a small number of people > -- those responsible for eTeX, PdfTeX and XeTeX : I assume that LuaTeX > can already handle this, as opposed to an inelegant and inefficient > work-around which may require a considerable amount of work by an > unknown but potentially somewhat larger set of people -- those > responsible for the various now-and-future front-ends to *TeX. Do you have a full list of all possible now-and-future events that you might want to flag this way? If not, you're requiring indefinite attention from the various *TeX maintainers. What about LaTeX/Plain TeX/AMSTeX warnings? They can be equally important, but I don't think the core *TeX engine knows about them. Just wrap *TeX in a script that greps the log file and accepts your desired command line arguments. Then only *one* person, namely you, has to do the work, and you can make the script available to any other front-end authors and maintain it for them. It wouldn't take long. In terms of programmer efficiency, that's much better than asking several different people to hack on C (or whatever language *TeX is written in) and maintain consistent lists of possible command-line switch values every time you think of a new case you want to detect. As observed by several of us, computer time efficiency is irrelevant for such trivial tasks as grepping *TeX log files. (Even on a decade-old computer, the time to grep a typical log file will be measured in a very small number of milliseconds.) -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Overfull boxes return status of 0 in XeTeX
On 2016-03-13, Philip Taylor wrote: > Yes, it is the "inspecting the log file" that I am trying to avoid, in > the interests of efficiency; an inspection of the log file should be > required (as it currently is) only if the status code returned by *TeX > is non-zero. You are living 30 years ago. Today (or even 10 years ago), grepping a log file for specified text consumes an unnoticeable amount of time for any log file generated by a non-pathological TeX run, and it allows TeXworks' problems to be solved by TeXworks, as they should be. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Σχετ: Re: Σχετ: Re: Assignment of codes (particularly \catcode) based on Unicode data
On 2015-05-07, Apostolos Syropoulos wrote: > Well I do not know what Dendrinos says I just happen to know what people do in > typography and in everyday practice. Which is not what the Unicode uppercase mapping is for. The uppercase mapping in the data file gives a default mapping, which is appropriate in the absence of any language specific behaviour (although some special cases of Greek are built in, particularly the behaviour of iota subscript and adscript). Case-conversion algorithms may use additional data appropriate to the language and environment. Many languages have conventions that diacritics may be omitted when writing in all capitals. For example, in French, it is quite common to omit accents, or to omit accents unless confusion would occur. >> The only mark that remains when making all capitals is the dieredis >> (dialytika). All other vanish. This is common knowledge for people who This is a different matter again. Conventions for all-capital writing may well be different from conventions for casing in mixed-case text, and in many languages diacritics are freely omitted in all-capital text -- Unicode specifically observes that accents are often omitted from Modern Greek all-capital text. This is something that needs to be handled by the functions that do the conversion; it's not something to be done by the basic uppercase mapping. As it happens, the breathings and accents of polytonic Greek were introduced into the script *before* it developed an upper/lower-case distinction. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Assignment of codes (particularly \catcode) based on Unicode data
On 2015-05-06, Apostolos Syropoulos wrote: > I checked a bit the file and I have noticed that > \L 1F10 1F18 1F10 % > while xgreek.sty defines > \global\lccode"1F10="1F10 \global\uccode"1F10="0395 > > You see the uppercase of 'GREEK SMALL LETTER EPSILON WITH PSILI' > is 'GREEK LETTER EPSILON' and not 'GREEK LETTER EPSILON WITH PSILI. Not in standard representations of Ancient Greek it isn't, and polytonic greek is mostly used for that. I thought you didn't even use the psili at all in modern greek? -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] additional beginL endL nodes in math
On 2015-04-16, David Carlisle wrote: > On 16 April 2015 at 20:51, Khaled Hosny wrote: >> That was very naive and did not work when inline math is broken over >> multiple lines, so I reverted this and the whole TeX-XeT business. XeTeX >> in TeX Live 2015 should behave identical to previous versions in this >> area. > Ah OK, sorry it didn't work out. I do see the problems with \specials > and \writes in RTL text > is a real problem. It seems to me that this is a consequence of some really bad design decisions in TeX ! I have wondered whether the right way to is to make a new variant of TeX in which there are invisible whatsits (could call them boojums, perhaps) which are ignored by most of TeX's list-(un)building activities. For example, a glue-boojum-glue sequence would be treated as a glue sequence, except that the boojum would remain behind when the glue was discarded. Boojum specials would instantly solve the absurd problem of colouring display maths without screwing up the spacing. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \centerline on custom paper size with plain XeTeX
On 2014-11-03, Deepak Jois wrote: > I want \centerline to properly center a line on a page with a custom > size. The minimal example below does not work for me. I even tried to > compile the code with "xetex -papersize=a5" What am I missing? > > Code: > > \special{papersize=5.8in,8.3in} > \hoffset0in > \hsize5.8in > \centerline{hi there} > \bye You're missing that \{h,v}offset are relative to the default position of (+1in,+1in) relative to the top left of the page. You mean \hoffset-1in -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] wrong glyphs with FreeSerif Italic
On 2013-12-27, Khaled Hosny wrote: > On Thu, Dec 26, 2013 at 02:36:55PM +0000, Julian Bradfield wrote: >> My xelatex version is >> This is XeTeX, Version 3.1415926-2.3-0.9997.5 (TeX Live 2011) >> (format=xelatex 20 >> 12.11.27) > > There was a problem with old versions of XeTeX (probably < 0.9998) where > having two different versions of the same font can lead to XeTeX using > one to typeset the document while dvipdfmx is using the other to > generate the PDF, which can lead to the shifted glyphs issue you see. Thank you very much! That was indeed the problem. There were a bunch of 2010 Freefont files in the texmf directory, while I'd put the 2012 files in the system directory. I hadn't realized the old files were there. After removing them, all is well. I understand kpathsea, but learning the interactions with fontconfig is still to come! -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] wrong glyphs with FreeSerif Italic
This is probably FA, but I haven't found it by searching... I'm a first-time user of xelatex (but 30-year user of TeX in general), and have used it to typeset a linguistic article with Charis SIL. I then wanted to switch to GNU Freefont, and encountered the weird symptom that all the glyphs are displaced by two codepoints in the Italic version. Here's a minimal example: \documentclass{article} \usepackage{mathspec} \setallmainfonts(Digits,Latin,Greek,Special)[Mapping=tex-text,Fractions=Off]{FreeSerif} \begin{document} ABCabc \it ABCabc \end{document} On processing, the PDF shows ABCabd CDEcde; the right character metrics appear to have been used, but the glyphs are wrong. My xelatex version is This is XeTeX, Version 3.1415926-2.3-0.9997.5 (TeX Live 2011) (format=xelatex 20 12.11.27) and the Freefont is the release of 20120503 (in either otf or ttf). -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex