Re: [XeTeX] wrong glyphs with FreeSerif Italic

[Julian Bradfield]

On 2013-12-27, Khaled Hosny khaledho...@eglug.org wrote:
 On Thu, Dec 26, 2013 at 02:36:55PM +, 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

Re: [XeTeX] \centerline on custom paper size with plain XeTeX

[Julian Bradfield]

On 2014-11-03, Deepak Jois deepak.j...@gmail.com 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] Σχετ: Re: Σχετ: Re: Assignment of codes (particularly \catcode) based on Unicode data

[Julian Bradfield]

On 2015-05-07, Apostolos Syropoulos asyropou...@yahoo.com 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

[Julian Bradfield]

On 2015-05-06, Apostolos Syropoulos asyropou...@yahoo.com wrote:
 I checked a bit the file and I have noticed that 
 \L 1F10 1F18 1F10 % 
 while xgreek.sty defines 
 \global\lccode1F10=1F10 \global\uccode1F10=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

[Julian Bradfield]

On 2015-04-16, David Carlisle d.p.carli...@gmail.com wrote:
 On 16 April 2015 at 20:51, Khaled Hosny khaledho...@eglug.org 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] Overfull boxes return status of 0 in XeTeX

[Julian Bradfield]

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] Overfull boxes return status of 0 in XeTeX

[Julian Bradfield]

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] ifcat changed?

[Julian Bradfield]

On 2017-04-16, Zdenek Wagner <zdenek.wag...@gmail.com> wrote:
> 2017-04-16 10:08 GMT+02:00 Julian Bradfield <jcb+xe...@jcbradfield.org>:

>> 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?

[Julian Bradfield]

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: no more subject prefix for xetex mailing list

[Julian Bradfield]

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

[Julian Bradfield]

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.

[XeTeX] mktexfmt fail on non-letter

[Julian Bradfield]

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: [XeTeX] Problem with ifpdf switch

[Julian Bradfield]

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!

Re: [XeTeX] Σχετ: Re: Σχετ: Re: Off topic (interesting) question

[Julian Bradfield]

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] Σχετ: Re: Σχετ: Re: Off topic (interesting) question

[Julian Bradfield]

> 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" !