Re: [XeTeX] converting to rft or .docx

[BPJ]

On 2012-09-15 18:05, Jacobo Myerston wrote:


I know this must be a annoying question, but I'm  frequently asked to send my 
texts to others  in  ms word format.  I just would like to know what is the 
best option to do this.

thanks,


You may find pandoc helpful.

<http://johnmacfarlane.net/pandoc/index.html>

/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Ubuntu and XeLaTeX

[BPJ]

On 2013-02-21 08:50, Mojca Miklavec wrote:

If you have all the prerequisites installed (compiler,
automake/autoconf, pkg-config, fontconfig etc.), it's just a matter of
running
 git clone git://github.com/khaledhosny/xetex.git
 cd xetex
 ./autogen.sh
 ./build.sh

The only thing that needs to be done is to replace
 /usr/local/texlive/2012/bin//xetex
(and possibly xdvipdfmx) with the new version and remake the formats.
Path might vary depending on your installation.


You mean that it's not enugh to put it somewhere else and have the 
system find it?


/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Fonts without proper combining diacritic placement

[BPJ]

Did Khaled post a while back that recent versions will center
(and rise/lower?) combining diacritics based on calculations
of the base character's bounding box if the font lacks proper
instructions, or did I dream that?

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Fonts without proper combining diacritic placement

[BPJ]

2013-06-02 01:25, Andrew Cunningham skrev:

Ir is still better to use fonts that have properly designed diacritics than
rely on a hack for diacritic placement jn fonts that weren't designed for
it.


Sure, but you also need to find fonts which contain the characters 
you need!




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Fonts without proper combining diacritic placement

[BPJ]

2013-06-02 23:50, Andrew Cunningham skrev:

On 03/06/2013 1:24 AM, "BPJ"  wrote:


Sure, but you also need to find fonts which contain the characters you

need!




Very true.

But usually I've found that combining diacritic support isn't the
limitation, its acfually finding the necessary base characters and glyph
combinations I need that is the difficult part.


In my case there are some *letters* I need in the same text
which only are supported in a few fonts.  If it were only a matter
of support for marks I could have used another font.




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Strange error

[BPJ]

2013-06-09 15:01, Arthur Reutenauer skrev:

It is strange because I am unable to find a package named etoolbox in ctan.


   Wilfred has already given the link to the package on CTAN, and as he
said it is part of TeX Live; in the collection latexextra, to be
precise.  What's strange is how you managed to install polyglossia
without installing etoolbox, as the former lists the latter as an
explicit dependency.


Could it happen if you uninstall etoolbox after installing 
polyglossia? Just wondering...


/bpj




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] TECkit mapping for Beta Code?

[BPJ]

Does anyone know if there exists a TECkit mapping for Beta Code?
<http://en.wikipedia.org/wiki/Beta_code>

I've found the betababel package, which I assume uses some single-
byte encoding, and am aware, though challenged to handle, that
some workaround to handle '\#=' as a text characters is needed;
any help in this regard would be much appreciated.

What I got are non-LaTeX plaintext files (which I'd like to not
need to retype manually at all) written with Greek in uppercase
Beta Code and Latin-script text (mostly English but some German
and French quotes) written in lowercase with Beta Code
conventions for uppercase letters and diacritics, plus the ad hoc
'**' for literal asterisks, moreover it uses 'v' and 'j' for
digamma and jod in reconstructed forms, and the non-Beta Code
conventions '_' for macron, and TeX-like '--' for dash.

I'm really suspecting that I'd be better off prefiltering the
sources with some ad hoc (computer) script before marking them
up, am I not?

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Large brace in multiline table cell

[BPJ]

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?

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.

I use LaTeX and XeLaTeX regularly, but am not used to math stuff,
so I'm out of my depth here. It's important that the text of the
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.



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Large brace in multiline table cell

[BPJ]

Thanks! A slight complication though: the other two braces which
I didn't include in my illustration enclose an even number of
lines/cells, six and two respectively.

/bpj

2013-10-12 15:20, John Was skrev:

Hello

I use plain XeTeX, and occasionally have to do something like
this.  The coding should (I think) still be comprehensible to
LaTeX, so you could try including something like this at the end
of the first cell of line 3:

\rlap{\kern 3pt
   $\smash{\left .\vbox to 30pt{}\right\}}$}


If '30pt' doesn't work (the brace is too large or too small), just
fiddle with the amount till it's right:  it ought to be more or
less correct if your five tabular lines take up 60pts of vertical
space.   If the brace isn't the right distance from the text,
alter '3pt' to what looks best. Remember to allow for the space
occupied by the brace when you specify the right-hand part of the
table, e.g. by  introducing an 12pt space or whatever looks best.


John





-Original Message- From: BPJ
Sent: Saturday, October 12, 2013 1:39 PM
To: XeTeX (Unicode-based TeX) discussion.
Subject: [XeTeX] Large brace in multiline table cell

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?

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.

I use LaTeX and XeLaTeX regularly, but am not used to math stuff,
so I'm out of my depth here. It's important that the text of the
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.



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex





--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Large brace in multiline table cell

[BPJ]

2013-10-12 17:23, Philip Taylor skrev:



BPJ wrote:
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.


Do you need to manually specify the line-turns in the
left-hand column,


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


or would it be sufficient to specify
the target width of that column and allow TeX to wrap
the text to the best of its ability ?

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
   http://tug.org/mailman/listinfo/xetex





--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] stacking diacritics without mark-to-mark

[BPJ]

If the problem is only one specific letter with two specific diacritics you
can hack a solution by writing a (La)TeX macro which puts the letter and
marks into boxes and position them by trial and error using fractions of
the width/height of the boxes rather than absolute lengths. Once you have
calculated the numbers you just wrap the macro invocation in another macro
for the specific letter+marks combo. I had to do that last year, so I'll
see if I can find the file when I get on that machine later today. Not
terribly elegant but the results were acceptable.
Den 13 mar 2014 04:28 skrev "Mike Maxwell" :

> On 3/12/2014 10:19 PM, Andrew Cunningham wrote:
>
>> Although personaly I'd consider such a solution a poor hack compared to a
>> well
>> designed font that is fit for purpose.
>>
>
> I won't disagree.  We've been told by the publisher, who original built
> the font (or more likely subcontracted it) that the problem is a
> shortcoming of their OpenType font files, that could only be eliminated by
> revising the font as a whole.  I'm inclined to tell them to go for it, or
> else we'll use a font that does work (Charis SIL comes to mind).  That
> would have the unfortunate consequence that the first book in our series
> would use the publisher's font (we didn't have the stacked diacritic
> problem in that book), but the rest of the books in the series would use
> some other font.
>
> But in order to convince them to make such a change, I need to understand
> better what is involved in revising a font to make mark-to-mark positioning
> work.  I gather that only the diacritics need the two mark-to-mark points
> (top and bottom) to be defined, not every character--correct?
>
> Is it done at the character level, or at the glyph level?  Does it need to
> be done separately for each point size/ weight/ style that the font
> supports?
>
> And do those attachment points need to be defined manually, or is there a
> way to automate that process?  Can this be done in a tool like FontForge,
> or does one need specialized tools that only the font manufacturer would
> have?
>
> I'm assuming that base characters already have top and bottom marks, but
> that may not be a safe assumption.  The problems we've seen so far have
> been with stacked diacritics.
>
> And of course there may be a better forum than this to ask this question.
> --
> Mike Maxwell
> maxw...@umiacs.umd.edu
> "My definition of an interesting universe is
> one that has the capacity to study itself."
> --Stephen Eastmond
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>  http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] wrong r+vocalic r ligature in FreeSerif font

[BPJ]

I just tried it and it seems no ligaturization happens at all:
I get an ordinary combining -ṛ under an ordinary ra,
rather off to the right, which suggests that no
positioning happens either.

With Sahadeva font I get the right glyph, so this is a bug in Free 
Serif.


Alas I'm not quite sure which version of FS gets used on my system.
Being a IEnist I seldom use Devanagari.

See attached output.

/bpj


2014-07-04 11:15, François Patte skrev:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonjour,

I found a wrong ligature r+vocalic r in FreeSerif fonf:

रृ

Is that a known bug?

- --
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)1 8394 5849
http://www.math-info.univ-paris5.fr/~patte
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO2cLIACgkQdE6C2dhV2JXghQCfWQB2m7b3boHvwYNAsQqd22nI
GFgAnjgMx+JfvyCjiTYX39zGl7DJ07jd
=tA52
-END PGP SIGNATURE-




--
Subscriptions, Archive, and List information, etc.:
   http://tug.org/mailman/listinfo/xetex





FS-rri.pdf
Description: Adobe PDF document


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] jpg image and text overlapping

[BPJ]

Acfording to the guy who once printed some posters for me you can always
convert the jpeg to some non-lossy format (tif), do your changes and then
save back to jpeg. Is that incorrect?
Den 4 aug 2014 23:54 skrev "Stefan Solbrig" :

> OK, I can see that 'JFIF' in the tombe.jpg file.  But it turns out it's
>> not in my file at all, only the 'Exif' header is there.  Our sysadmin guys
>> haven't installed the suggested exiftool tool yet; presumably exiftool will
>> be capable of *adding* the JFIF header (which I gather should come before
>> the Exif header, although apparently both headers want to be first).
>>
>
> You don't have to wait for sysadmins  ;-)  . Just get the tarball (the
> home of exiftool seems to be http://www.sno.phy.queensu.ca/~phil/exiftool/)
>   and you can run the script from the tar directory. (Or by setting PATH
> and PERL5LIB environment variables.)
>
>  Turns out GIMP will also save it with both the JFIF and Exif headers, and
>> that works with XeTeX, and has a batch method.  So I guess I could use that.
>>
>
> As it as already been pointed out, be careful that the jpegs are not
> re-encoded. If not done very carefully, it will degrade the image quality.
> (Re-encoding a lossy format will loose even more information.)
>
> best,
> Stefan
>
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>  http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeLaTeX generated pdf metadata

[BPJ]

If I am not mistaken you can change the metadata with pdftk, although it is
probably a pain to do so. Also I do not know if pdftk comes for Windows.

lördag 20 september 2014 skrev Daniel Greenhoe :

> Dear XeTex,
>
> 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.
>
> Therefore, if it is not too much trouble, I would like the metadata in
> my XeLaTeX/xdvipdfmx generated pdf file to clearly indicate that it
> was generated by XeLaTeX (*not* by LaTeX). Would any one have time for
> this?
>
> Many thanks in advance,
> Dan
>
> - please ignore the following -
> Dear arXiv-moderation
> [arXiv #128343]
> [arXiv #128400]
>
> On Sat, Sep 20, 2014 at 10:15 AM, Daniel Greenhoe  > wrote:
> > Dear XeTeX,
> >
> > I have tried uploading a paper in pdf format that I typeset using
> > XeLaTeX to arXiv.org. However, it was later removed because it
> > "appeared to be PostScript/PDF generated from TeX source". I wrote to
> > arXiv-moderation, strongly arguing my case for using XeLaTeX rather
> > than LaTeX. They responded saying "In order to approve such a request
> > we'd have to have a PDF which includes it's XeTeX nature within the
> > pdf properties...".
> >
> > When I typeset my paper using xelatex.exe, an xdv file is generated
> > which contains this in the metadata:
> >   \Creator(LaTeX with hyperref pacakge)\Author()\Producer(XeTeX 0.1)
> > Later I use xdvipdfmx.exe to generate a pdf file. It contains this
> > information in the metadata:
> >   Creator:LaTeX with hyperref package
> >   Producer:   xdvipdfmx (20140317)
> >
> > So although the producer fields provides evidence that I am using
> > XeLaTeX, the creator field erroneously implies that I have typeset
> > using LaTeX. Hence, there will be a high probability that my paper
> > will either be removed by an automated server at arXiv.org or a human
> > administrator.
> >
> > I realize that I could possibly hand edit the xdv file or use a
> > metadata editor to edit the pdf file. But I would rather not do this.
> > I would rather work transparently, not surreptitiously changing the
> > metadata of files.
> >
> > Would it be possible that some qualified person could correct the
> > creator metadata output of XeLaTeX? I am currently using xelatex from
> > TeXLive 2014 running on Windows. Here is the first line from the log
> > file:
> >   This is XeTeX, Version 3.14159265-2.6-0.1 (TeX Live 2014/W32TeX)
> > (preloaded format=xelatex 2014.9.20)  20 SEP 2014 07:16
> >
> > Many thanks in advance,
> > Dan
> >
> > -please ignore the following-
> > Dear arXiv-moderation,
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Case changing for Greek

[BPJ]

Den 2015-05-07 16:02, Jonathan Kew skrev:

Would it be feasible to define this negatively instead --
something like "a sigma is final if it is NOT followed by another
letter"?

A possible refinement is that a lone sigma, neither preceded nor
followed by another letter, should probably be lowercased as σ
rather than ς.


I have used this Perl regular expression substitution to change σ into
ς for some years, with satisfactory results so far,

s/(?<= \p{Script=Greek} ) (?<= \pL ) σ (?! \pL | - )/ς/gx

That is: change a σ into ς if it is preceded by a Greek letter
and not followed by a letter or a hyphen. NB that this
substitution as written above only works with NFC text. For NFD
you would need to use the following, since the perl regex engine
doesn't support variable-length lookbehind:

s/(?<= \p{Script=Greek} ) (?<= \pL ) ( \pM* ) σ (?! \pL | - 
)/$1ς/gx


I guess that when intersection character classes are possible one
should change the negative lookahead into "when not followed by a
Greek letter or a hyphen.

(?! (?[ \p{Script=Greek} & \pL ]) | - )

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Case changing for Greek

[BPJ]

Den 2015-05-10 23:01, Maïeul skrev:

; be careful the ; for question mark in greek is U+037E will the
semicolon is U+003B.


Yes but U+037E is deprecated, meaning one should use U+037E,
so one would have to list both in this case!

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Fwd: Re: Case changing for Greek

[BPJ]

Watching this discussion and thinking about the various contexts which
should or should not trigger σ → ς substitution are surely the Greek
number signs:

-   U+0374 GREEK NUMERAL SIGN:'ʹ'
-   U+0375 GREEK LOWER NUMERAL SIGN:'͵'


I have just been fortunate to not run into -- or unfortunate not 
to notice! -- that yet.


So my substitution regular expression, which defines the following 
context negatively,

should rather be

s/(?<= \p{Script=Greek} ) (?<= \pL ) ( \pM* ) σ (?! \pL | 
[-ʹ͵] )/$1ς/gx


There certainly are edge cases which this doesn't handle.  The one 
which immediately comes to mind is `(s)` and similar, which should 
be sensitive to what comes before and after the parentheses.


on Thu, 07 May 2015 I wrote:


Den 2015-05-07 16:02, Jonathan Kew skrev:
> Would it be feasible to define this negatively instead --
> something like "a sigma is final if it is NOT followed by another
> letter"?
>
> A possible refinement is that a lone sigma, neither preceded nor
> followed by another letter, should probably be lowercased as σ
> rather than ς.



I have used this Perl regular expression substitution to change σ into
ς for some years, with satisfactory results so far,



s/(?<= \p{Script=Greek} ) (?<= \pL ) σ (?! \pL | - )/ς/gx



That is: change a σ into ς if it is preceded by a Greek letter
and not followed by a letter or a hyphen. NB that this
substitution as written above only works with NFC text. For NFD
you would need to use the following, since the perl regex engine
doesn't support variable-length lookbehind:



s/(?<= \p{Script=Greek} ) (?<= \pL ) ( \pM* ) σ (?! \pL | - )/$1ς/gx



I guess that when intersection character classes are possible one
should change the negative lookahead into "when not followed by a
Greek letter or a hyphen.



(?! (?[ \p{Script=Greek} & \pL ]) | - )



/bpj





--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Case changing for Greek

[BPJ]

Den 2015-05-17 12:10, Bruno Le Floch skrev:

On 5/7/15, Apostolos Syropoulos  wrote:

That is correct Jonathan. In fact the general rule is that a σ at the end of
a word becomes always a ς. The only exception is when the final vowel is
cut due to a grammatical phenomenon that occurs is the following:

  σώσ' τα (save them)


This case seems really hard to detect.  The Unicode definition (that a
sigma is final if the last non-Case_Ignorable character is Cased and
the next is not) wrongly considers the second sigma in your example as
a final sigma.


Moreover Unicode has decided to keep apostrophe and English-style 
closing single quote unified, so there is no way to set up a set 
of punctuation marks which should or should not trigger final 
sigma, since apostrophe and closing single quote would fall in 
different sets.  Luckily Greek uses guillemets, but for Greek 
embedded in English text all bets are off! (Swedish fortunately 
knows a style with »…» as outer quotes and ”…” as inner quotes. 
It's seriously old-fashioned but I use it for text with embedded 
Greek whenever I can, not because I was aware of this issue -- 
although it can in principle happen in Ancient Greek verse -- but 
because single quotes don't mix well with breathings!) I wonder 
how often a closing quote is not followed by another punctuation, 
statistically speaking.




Perhaps we need an explicit way to say that a given sigma is final or not.


As I can see it there are three possible solutions:

*   An 'uppercase final sigma' which looks identical to the 
ordinary uppercase sigma.


*   Disunifying apostrophe and single quote.

*   Putting some suitable non-spacing character between a 
non-final sigma and an apostrophe, to preserve the distinction in 
case roundtripping.  This is perhaps the most realistic, as anyone 
can just start using it right away.


The problem with all three is that most people won't do it, since 
for most people what looks the same is the same!


As for the Unicode definition of a final sigma it is IMO 
deficient: clearly the last preceding character which is not a 
combining mark must be *a Greek letter*. 'Finalizing' a sigma 
after non-Greek letters just doesn't make sense, and quite 
obviously a sigma before any of the Greek number marks or a hyphen 
should not be final. Clearly they have not consulted any 
classicists or comparative philologists when making that 
definition! :-)  As so often no algorithm is going to make 
proofreading unnecessary (Which is good for me, professionally 
speaking! :-)


/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Incorrect rendering of Vedic Sanskrit accents

[BPJ]

Den 2015-05-22 21:14, David M. Jones skrev:

Arguably, it never is -- if you want a dotted circle, you can add it
yourself, whereas it's not at all unusual to want to show combining
marks in isolation in, say, textbooks.


Showing it with a dotted circle as stand in for a base character, 
whether automatically inserted (which I wouldn't like) or with an 
explicit U+25CC is the correct way to show a combining character 
in such a case, since it shows clearly where the combining mark 
would be in relation to the base character. You can always add a 
footnote to the effect that ◌ is conventionally used in place of a 
base character when discussing a combining mark without reference 
to a base character.


Even if you want the mark to 'hang in the air' a combining mark
needs something with width to 'hang' it on even in that case, and
a nonbreaking space would seem to be the natural choice. If you
(likely) need finer control over spacing one or more of the
characters in the U+2000...U+200A range may serve, but remember 
that the visual effect may be font dependent.


FWIW I checked some lead-printed Sanskrit grammars and 
dictionaries and they all use some base character (क or त in all 
cases) when discussing combining marks; there simply weren't any 
type for marks without a base character.  Compared to that the 
dotted circle is a huge advance! Especially in a table it makes 
the difference between superscript, subscript and superimposed 
marks immediately clear.


Alas U+25CC seldom is equipped with the anchors necessary to 
display marks correctly in relation to it, if there is a glyph for 
it at all.  Often you need to use another font and adjust the size 
of the dotted circle itself.




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Alternate Ξ glyphs in GFS Neohellenic

[BPJ]

Dear Greek-users on the list,

according to the type specimen[^1] there are three different Ξ glyphs in the 
OTF version of the font GFS Neohellenic[^2] but I can only access two of them 
-- of course not the one I want at this time, the one without vertical or 
diagonals!  Peeking inside the font with FontForge hasn't made me any wiser.  
Does anyone know how to access them all?

TIA,

/bpj


[^1]: http://www.greekfontsociety.gr/images/NeoHellenic%20Specimen.pdf
[^2]: http://www.greekfontsociety.gr/GFS_NEOHELLENIC_OT.zip


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Alternate Ξ glyphs in GFS Neohellenic

[BPJ]

Den 2015-09-06 kl. 16:28, skrev Joel C. Salomon:

On Tue, Sep 1, 2015 at 12:19 PM, Arthur Reutenauer
 wrote:


   For some strange reason the glyph you want is not accessible through
OpenType features, as a look into the GSUB table confirms, but is
included as a separate character from the Private Use Area (U+E004);
that's why copy-pasting from the PDF file works for this particular
glyphs, as Phil showed; but it's obviously a bad idea to do so because
you would need to input all Ξ as this PUA character, and then your PDF
files won't be searchable.




The zig-zag glyph was, if I don't misremember, the original glyph 
in New Hellenic. It had a number of weird glyphs for other 
letters, which are included as alternates in GFS Neohellenic. 
More standard glyphs were added to New Hellenic later to make it 
sell better, but it may well be that they never added a 'plain' Ξ, 
and that that glyph was added, albeit in a halfhearted way, by the 
GFS.  The zigzag form doesn't bother me that much -- it did 
actually occur in ancient times and is the ultimate origin of the 
current lowercase ξ -- but I certainly wouldn't insist on it when 
someone disprefers it!




The http://ctan.org/pkg/accsupp package could be helpful in a
temporary work-around:

\usepackage{accsupp, newunicodechar}
\newunicodechar{Ξ}{\BeginAccSupp{unicode,ActualText=Ξ}‹PUAchar›\EndAccSupp{}}


I knew to use newunicodechar, but this trick seems very useful.
We will have to use another font for this project because we 
needed lowercase digamma in two reconstructed forms, but this will 
certainly come in useful another time!


Thanks, all of you!

/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Faking small caps?

[BPJ]

I have a text where certain words should be set in small caps. The 
problem is that some of these words contain the character ŋ, which 
isn't supported in small caps in the font used.  Might there be 
some way to fake a small cap ŋ in these words -- preferably 
smarter than search-replacing ŋ with {\small Ŋ} in those words?  I 
already use a semantic custom command, \let to \textsc for those 
words, so a solution which 'automatically' replaces ŋ with 
something suitable inside that command would be preferable, but 
I'm not sure to achieve such an automatic replacement, nor what 
the smartest replacement may be. Leaving ŋ as lowercase looks 
absolutely horrible!


TIA,

/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Faking small caps?

[BPJ]

Den 2016-01-25 kl. 16:06, skrev Philip Taylor:



BPJ wrote:

I have a text where certain words should be set in small caps. The
problem is that some of these words contain the character ŋ, which isn't
supported in small caps in the font used.  Might there be some way to
fake a small cap ŋ in these words -- preferably smarter than
search-replacing ŋ with {\small Ŋ} in those words?


Why not make ŋ active and program it to expand to {\small Ŋ} ?
Philip Taylor



I discovered (1) that some other problematic characters also occur 
in this context and (2) made some further experimentation and 
found that the following actually looks practically 
indistinguishable from real small caps:


\newcommand{\Morph}[1]{{\addfontfeatures{Scale=0.7,FakeStretch=1.2}\MakeUppercase{#1}}}

/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] babel

[BPJ]

> characters] ङ  and ञ are not used in Hindi, they should be removed from
index

Aren't they used in conjuncts either?

/bpj


onsdag 23 mars 2016 skrev Zdenek Wagner :

> Hi Javier,
>
> I am copying my reply to the cstex list because I am not autoritative for
> Slovak and maybe I will not be precise enough. I am giving my commnents to
> Czech (cs.ini), Slovak (sk.ini), and Hindi (hi.ini). Some comments are
> common for all.
>
> I do not understand the meaning of the encoding field. T1 and OT1 are font
> encodings for use with 8-bit TeX, XeTeX is able to use UTF-8 or UTF-16 and
> such fonts are available. IL2 (in Czech) was historically used in cslatex.
> It is preserved for legacy documents but deprecated, unsupported in babel
> and should be deleted. I know nothing about LY1. Before Unicode there
> existed many private encodings for Devanagari, many web pages used it and
> it was necessary to install a special font. Such fonts can still be found
> but IMO there is no sense to support them.
>
> I understand hyphenchar (should be the same as in English in all mentioned
> languages) but do not understand the other hyphen* fields.
>
> The minus sign in both Czech and Slovak should be –
>
> The quotes in both Czech and Slovak are „ and “ (the closing quote has its
> codepoint in Unicode but is rarely present in fonts, it is better to use
> English opening quote which has the same shape).
>
> In Czech (and maybe also in Slovak) the time separator is a period, in
> sport results and time tables a colon is used.
>
> Slovak: characters Ä Ď Ô Ť in index look strange to me, it should be
> proved by a native Slovak speaker.
>
> Hindi
> 
>
> See the note on the encoding above
>
> A few misprints and missing items in the captions
> bib = संदर्भ-ग्रन्थ (or संदर्भ-ग्रंथ)
> contents - the version you have is one of the alternatives suggested by
> Anshuman Pandey but most books I have bought in India contain अनुक्रम
> part = खण्ड (or खंड)
> page = पृष्ठ
> proof = प्रमाण
> glossary = शब्दार्थ सूची
>
> cc, encl, and headto make no sense, I am probably the only man who writes
> business e-mails in Hindi...
>
> I have never seen abreviated months (a native Hindi speaker should help).
> The only abbreviations for days of week I have seen at the Aligarh railway
> station are:
> Monday = सो॰, Tuesday = मं॰, Wednesday = बु॰, Thursday = बृह॰, Friday =
> शुक॰ (or शुक्र॰, the plate was not clearly readable), Saturday = शनि॰,
> Sunday = रवि॰. I would not be surprized if the ॰ punctuation were omitted.
>
> [characters] ङ  and ञ are not used in Hindi, they should be removed from
> index
>
> frenchspacing – I am afraid that it has no sense in Hindi as well as other
> Indic languages. The proper spacing was implemented in GNU Freefont (at
> least for Hindi) and is activated automatically by language switching. The
> rules are explained (in Hindi only, links to other languages switch to a
> different text) at
>
> https://hi.wikipedia.org/wiki/%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A4%BF%E0%A4%AA%E0%A5%80%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE:%E0%A4%B9%E0%A4%BF%E0%A4%A8%E0%A5%8D%E0%A4%A6%E0%A5%80_%E0%A4%AE%E0%A5%87%E0%A4%82_%E0%A4%B8%E0%A4%BE%E0%A4%AE%E0%A4%BE%E0%A4%A8%E0%A5%8D%E0%A4%AF_%E0%A4%97%E0%A4%B2%E0%A4%A4%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%81
>
> punctuation: danda । and double danda ॥ should be listed as the most
> important punctuation
> quotes: either English double quotes or English single quotes are used
> (depends on the preference of an author and/or a publisher)
>
> number: Both Devanagari and Arabic digits are used, it is hard to say
> which one should be he default
>
> counters: the way how list items are numbered does not conform to the
> LaTeX system. I have a normative document how it should be done, it is
> written in Marathi and I probably have also a Hindi version. Unfortunately
> I have not found time to implement it so far.
>
>
>
> Zdeněk Wagner
> http://ttsm.icpf.cas.cz/team/wagner.shtml
> http://icebearsoft.euweb.cz
>
> 2016-03-23 19:31 GMT+01:00 Javier Bezos  >:
>
>> Hi all,
>>
>> I'm working on a new version of babel, with a new way to define
>> languages in a descriptive way, more than in a programmatic one (of
>> course, the latter won't be excluded because it's still necessary).
>>
>> The idea is to create a set of ini file like those you can find on
>>
>>
>> https://latex-project.org/svnroot/latex2e-public/trunk/required/babel/locales/
>>
>> They are tentative and some of them are incomplete. I'm working on the
>> code to read and 'transform' their data, but in the meanwhile I'd like
>> to improve the ini files. The first s

Re: [XeTeX] fontspec and Nikosh font

[BPJ]

Den 2016-06-21 kl. 23:15, skrev Dominik Wujastyk:

About the other version of the FreeFonts, see
http://cikitsa.blogspot.ca/2014/12/gnu-freefont-fonts-and-xelatex.html


Am I remebering correctly that the FreeFont developer was somewhat 
annoyed about that build?


BTW any idea where the font gets installed to? Grepping the 
texlive tree is tricky for some reason.


/bpj



​Dominik​


On 21 June 2016 at 03:02, Zdenek Wagner  wrote:


Hi all,

I ran an extensive test of devanagari during the TL 2016 pretest
period using XeLaTeX, LuaLaTeX and ConTeXt. I cannot guarantee that my
test covers everything but I have not found any error. The only
problem is that the released version of FreeFont does not work with
HarfBuzz, there is another repository (I forgot it) with a not
released version that works or you have to build it from the source
avilable from savannah.

One of my test files can be found here:
http://hroch486.icpf.cas.cz/freefont-devanagari/

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz


2016-06-21 10:10 GMT+02:00 Jonathan Kew :

On 20/6/16 23:22, maxwell wrote:


Not sure if Will is on this mailing list, but I'm cc'ing him using his
email address on the fontspec document.  (The doc doesn't have the
co-author's email, Khaled Hosny, but I think I've seen him here.)

On 2016-06-20 17:55, Jonathan Kew wrote:


My guess is that this might be a bug in the TL'16 version of fontspec,
which looks like it is intended to support both the "new Indic spec"
OpenType tags such as 'dev2', 'bng2', etc, as well as the "old Indic"
versions 'deva', 'beng', etc, with preference being given to the v.2
tags. Perhaps that feature is broken?
...

One way to check what's wrong would be to search for the

   \newfontscript{Devanagari}{dev2,deva}

declaration around line 2247 in fontspec-xetex.sty, and remove "dev2,"
from it so that it only looks for the old-style 'deva' tag. If that
makes Gargi work without complaint (using [Script=Devanagari] as
before), then you've identified a bug in fontspec and should report it
to Will.



I confirm that omitting 'dev2,' from that declaration causes fontspec
not to emit a warning when I do
 \newfontfamily\sanskritfont[Script=Devanagari]{gargi}
and similarly for the Nikosh font, fontspec gives a warning when I do
 \newfontfamily\bengalifont[Script=Bengali]{Nikosh}
unless I change
 \newfontscript{Bengali}{bng2,beng}
to
 \newfontscript{Bengali}{beng}
in fontspec-xetex.sty.

Thanks for the pointer, Jonathan!



The other question I have is whether this is a "harmless" (if alarming)
warning, meaning that fontspec warns when it fails to find the v.2 tag,

but

then proceeds to use the old tag and the text is shaped correctly. Or

does

it mean that fontspec is failing to use the second tag, so that the

proper

Indic shaping does not get applied?

It should be easy to test this with a word like हिन्दी, using the Gargi

font

with [Script=Devanagari]. Does the short-i matra ि appear to the left of

the

ह, or after it? If it appears to the left (despite the fontspec warning),
then it's correctly falling back to 'deva' when 'dev2' is not found.

JK




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex




--
Subscriptions, Archive, and List information, etc.:
   http://tug.org/mailman/listinfo/xetex







--
Subscriptions, Archive, and List information, etc.:
   http://tug.org/mailman/listinfo/xetex





--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Find out which font file xetex uses

[BPJ]

This is certainly old hat but my memory, Google and my listmail 
backlog all fail me: how can I find out which file xetex loads for 
a particular font? Will those in ~/.fonts be preferred or not?


/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Embed full font in PDF

[BPJ]

Den 2016-07-22 kl. 21:26, skrev maxwell:

Another alternative, which I have not tried yet, seems to be the
Fira Sans font, which exists in both proportionally and
mono-spaced versions:
   https://en.wikipedia.org/wiki/Fira_Sans
I'm not sure what its code point coverage is, nor whether it
handles stacked diacritics; we'll see.


Its combining marks coverage is *very* meagre.


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] prioritizing OTF fonts

[BPJ]

You can always put symlinks in an easily remembered place like ~/fontlinks/

/bpj

torsdag 28 juli 2016 skrev maxwell :

> On 2016-07-28 07:28, Herbert Schulz wrote:
>
>> You can load the font using file names rather than font names. It's a
>> bit more complicated but certainly doable. That resolves any ambiguity
>> the way you wish.
>>
>
> Yeah, I was hoping there was an easier way than that, like
> [prioritizeOTF=true].  (Although I suppose that might need to be done at
> the level of /etc/fonts/local.conf.)  Thank you though!
>
>Mike Maxwell
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>  http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeLatex and PS-Tricks

[BPJ]

Den 2016-09-04 kl. 18:12, skrev Colin Ramsay:

Hi all,

I use TeXLive 2015 with Winedt 10.0 as my front end on Windows 7 Professional.

My question is: How do I get XeLatex to recognize my ps-tricks drawings? Is 
there some package missing?

Colin


Perhaps one of these can be helpful?

http://tex.stackexchange.com/search?tab=relevance&q=xelatex%20pstricks

/bpj



--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Fake italics for some characters only

[BPJ]

@Zdenek, the point is that other characters inside `\textit` should be real
italics. I at least have tried it using a macro around the "culprit"
characters and I think it looks better than fake italics throughout, which
looks really bad (shades of low-budget publications from the early
eighties! :-). Anyway I'm working on a solution in my head which I'll try
when I get back to my desktop. I think I'll try to use a boolean which I
set/unset at the start/end of my "`\mytextit` and a single macro for the
active characters which checks this boolean. I have no idea yet if it will
work, but it seems the semantically cleanest way to do it to my mind.

/bpj

ons 5 dec. 2018 kl. 10:53 skrev Zdenek Wagner :

> Hi,
>
> I am afraid that I do not understand why to make only 4 FakeSlant
> characters instead of a FakeSlant font. Does it mean that other
> characters will remain upright inside \textit?
>
> Anyway, making a few characters active for \textit is quite simple.
> Let's suppose that A and B should be active. You then define:
>
> \def\mytextit{\begingroup \catcode`\A=13 \catcode`\B=13 \dotextit}
> \def\dotextit#1{\textit{#1}\endgroup}
>
> You will then call \mytextit{Test of A and B}
>
> Zdeněk Wagner
> http://ttsm.icpf.cas.cz/team/wagner.shtml
> http://icebearsoft.euweb.cz
>
> st 5. 12. 2018 v 5:51 odesílatel Alan Munn  napsal:
> >
> > Can you provide a bit more detail? Maybe a small example document?
> >
> > Alan
> >
> >
> > Benct Philip Jonsson wrote:
> > > I have a somewhat unusual problem. In a document produced using
> > > XeLaTeX I need to use four Unicode letters with scarce font support in
> > > italicized words and passages but the font which I have to use
> > > supports these characters only in roman. The obvious solution is to
> > > use the FakeSlant feature of fontspec but I don’t want to enclose
> > > these characters in a command argument, in the hope that a future
> > > version of the document can use an italic font which supports these
> > > characters, but neither do I (perhaps needless to say) want to use
> > > fake italics except for these four characters. In other words I would
> > > like to perform some kind of “keyhole surgery” in the preamble and use
> > > these characters normally in the body of the document, which I guess
> > > means having to make them active and somehow detect when they are
> > > inside the argument of `\textit`. (Note: it is appropriate to use
> > > `\textit` rather than `\emph` here because the purpose of the
> > > italicization is to mark text as being in an object language in a
> > > linguistic text.) Is that at all possible? I guess I could wrap
> > > `\textit` in a macro which locally redefines the active characters,
> > > but I’m not sure how to do that, nor how to access the glyphs
> > > corresponding to the characters once the characters are active. I am a
> > > user who isn’t afraid of using and making the most of various packages
> > > or of writing an occasional custom command to wrap up some repeatedly
> > > needed operation, but I am no expert. I am aware of all the arguments
> > > against fake italics — that is why I want to limit the damage as much
> > > as possible! — but I have no choice here. Waiting for the/an
> > > appropriate font to include italic versions of these characters is not
> > > an option at the moment.
> > >
> > > /Benct
> > >
> > >
> > >
> > > --
> > > Subscriptions, Archive, and List information, etc.:
> > >  http://tug.org/mailman/listinfo/xetex
> >
> >
> >
> > --
> > Subscriptions, Archive, and List information, etc.:
> >   http://tug.org/mailman/listinfo/xetex
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: XeLaTeX to Word/OpenOffice - the state of the art?

[BPJ]

I use, despite myself, Google Docs to convert PDF to DOCX, then Pandoc from
DOCX to everything else. It works even with weird magazine layouts.

Den mån 11 mars 2019 13:42Janusz S. Bień  skrev:

>
> Hi!
>
> I was asked to convert to Word a rather long paper submitted as the
> XeLateX PDF output (if accepted, the Word document will be converted to
> PDF by the editors...; I understand they work on the assumption that the
> reviewers don't know how to comment a PDF file).
>
> I had to do it already from time to time. I used different methods which
> were more or less cumbersome. Of course for the conversion I prepare a
> slightly different text (e.g. no hyphenation).
>
> Before embarking on such a job again I would like to make sure there are
> no new tools that I'm not aware of.
>
> Best regards
>
> Janusz
>
> --
>  ,
> Janusz S. Bien
> emeryt (emeritus)
> https://sites.google.com/view/jsbien
>

Re: XeLaTeX to Word/OpenOffice - the state of the art?

[BPJ]

Den 2019-03-15 kl. 08:31, skrev Janusz S. Bień:

On Fri, Mar 15 2019 at  7:19 +01, BPJ wrote:

I use, despite myself, Google Docs to convert PDF to DOCX,


How???


then Pandoc from DOCX to everything else. It works even with weird
magazine layouts.


Best regards

Janusz



This may be old news to some, but I can’t remember having seen it, 
so I make a post for the record.


I just discovered that you can convert a PDF to Markdown (or any 
other format Pandoc supports) by uploading it to Google Drive, 
opening it in Google Docs and downloading it from there as DOCX, 
then converting the DOCX to Markdown with Pandoc. The result is 
quite good!


The steps:

1.  Log into  in a web browser.

2.  Select the menu [My Drive⏷] → [Upload files…] in the top bar.

More recently there is a “button” [+ New] in the top left 
corner. Click on it and select [File upload] in the menu which 
appears.


3.  At least on my system a file dialog opens. Browse to the PDF 
file; select it; click [Open].


4.  (If this doesn’t work try step 5.)

i.  The file appears in the “Quick access” field just below 
the top bar. You may need to refresh a couple of times.
ii. Right-click the file thumbnail; choose [Open with] → 
[Google Docs].


5.  If step 4 doesn’t work (the PDF file doesn’t appear in the 
quick access field):


i.  Start typing the PDF file name in the [Search Drive] box 
at the top.

ii. Click on the file in the menu which appears.
iii. The file opens in the Drive PDF viewer.
iv. At the top there is a menu [Open with Google Docs]. Click 
on it and select Google Docs.


Or look up the file in the file list and follow 4.ii. (Hard 
when there are lots of files in the list!)


6.  You should now find yourself in the Google Docs document view.

7.  In the [File] menu choose [Download as] → [Microsoft Word 
(.docx)].


8.  Save the DOCX file to disk and convert it with Pandoc the same 
as you would any DOCX file, or edit it with Word/LibreOffice/… if 
you are of that persuasion.


Basic formatting — paragraphs, bold, italics — works very well. 
Some more advanced formatting is more or less broken:


-   Tables become ordinary text, not very well lined up.
-   Nested lists are flattened.
-   Small caps text disappears entirely! If you have access to the 
original LaTeX file I suggest putting this in your preamble:


\renewcommand\textsc[1]{\textbf{\textit{#1}}}

or if bold italics actually occur in your document this:

\usepackage{textcase}

\renewcommand\textsc[1]{\textbf{\textit{\MakeTextUppercase{#1

Uggly as hell but sequences of uppercase bold italics are 
unlikely to actually occur in a document and are relatively easy 
to find and replace with something better in a “word processor” or 
in a text editor after conversion from DOCX to some sensible 
format with Pandoc.


If you post-edit in a “WP” you may try (x)color and something 
like \renewcommand\textsc[1]{\textcolor{red}{#1}} instead. That 
may be hard to find _with_ the “WP” but is relatively easy to find 
_in_ the “WP” for a human eye.


You may want to correct these things in the “word processor” but 
my definite preference is to convert the DOCX file to Pandoc’s 
extended Markdown with Pandoc, fix things up and then convert 
(back) to DOCX. You can then also apply your own custom named 
styles for things like color.


http://pandoc.org/MANUAL.html#custom-styles

http://pandoc.org/MANUAL.html#option--reference-doc

It still says “For best results, do not make changes to this file 
other than modifying the styles used by pandoc” but that is just 
what you want to do if you are using custom styles, including 
adding your own! BTW you may want to avoid non-ASCII and 
non-alphanumeric characters in your custom style names so that you 
don’t need to quote your custom-style attribute values!


Speaking of small caps it has its official Pandoc syntax: [small 
caps text]{.smallcaps}, but that is far too verbose by Markdown 
standards! ;-) I usually overload Pandoc’s generally useless 
strikeout syntax so that I can type ~~small caps text~~ with this 
Pandoc Lua filter:


function Strikeout (elem)
return pandoc.SmallCaps(elem.content)
end

I hope this is of use to someone!

/bpj

Re: XeLaTeX to Word/OpenOffice - the state of the art?

[BPJ]

Den 2019-03-15 kl. 12:31, skrev Zdenek Wagner:

I am also interested how you do it. I have tried with one of my
documents (I do not need this conversion, it was just a test). The
document contains 5 tables and 50 math equations. The first equation
is OK, the remainng equations are total garbage, they will have to be
entered manually from scratch. The tables are total garbage as well,
they even do not look like tables. The table of contents is garbage
but this is not a major issue. The problem is that in the middle of
the first page, probably as an effect of math, the text becomes
garbage as well. In this situation copy&paste and manual conversion
will be faster unless there is a special (hidden) trick which I do not
know.


As I said in my howto just posted your best bet if you have the 
original LaTeX file is to redefine commands etc. in *TeX so that 
the results become less garbagey and easier to correct by hand.
I don't know about math because I don't do math, so for me 
not-so-simple tables are the biggest problem.  If you or anyone 
else comes up with a *TeX hack which makes column boundaries 
"visible",
as in inserting pipe characters or some such, it will be much 
easier to tidy things up after conversion to a text format with 
Pandoc.


You may also want to try Pandoc's direct LaTeX-->Anything 
conversion, although it is rather lossy for more advanced stuff

it does lists, tables, small caps and surely math quite OK.

I only use this PDF-->DOCX trick for PDFs I get from my clients 
where the source is not included or may not exist.

I'm still to encounter a client handing me a *TeX file... :-(

/bpj

Re: XeLaTeX to Word/OpenOffice - the state of the art?

[BPJ]

Den 2019-03-15 kl. 13:51, skrev BPJ:

Den 2019-03-15 kl. 12:31, skrev Zdenek Wagner:

I am also interested how you do it. I have tried with one of my
documents (I do not need this conversion, it was just a test). The
document contains 5 tables and 50 math equations. The first 
equation
is OK, the remainng equations are total garbage, they will have 
to be
entered manually from scratch. The tables are total garbage as 
well,

they even do not look like tables. The table of contents is garbage
but this is not a major issue. The problem is that in the middle of
the first page, probably as an effect of math, the text becomes
garbage as well. In this situation copy&paste and manual conversion
will be faster unless there is a special (hidden) trick which I 
do not

know.


As I said in my howto just posted your best bet if you have the 
original LaTeX file is to redefine commands etc. in *TeX so that 
the results become less garbagey and easier to correct by hand.
I don't know about math because I don't do math, so for me 
not-so-simple tables are the biggest problem.  If you or anyone 
else comes up with a *TeX hack which makes column boundaries 
"visible",
as in inserting pipe characters or some such, it will be much 
easier to tidy things up after conversion to a text format with 
Pandoc.


You may also want to try Pandoc's direct LaTeX-->Anything 
conversion, although it is rather lossy for more advanced stuff

it does lists, tables, small caps and surely math quite OK.

I only use this PDF-->DOCX trick for PDFs I get from my clients 
where the source is not included or may not exist.

I'm still to encounter a client handing me a *TeX file... :-(


BTW you can "tame" recalcitrant LaTeX commands when converting 
with Pandoc by including `\renewcommand`s restating them in terms 
of simpler LaTeX constructs which Pandoc can handle and Pandoc 
will use them.  IIRC there is a feature request out (or I'll make 
one!) for getting some/all LaTeX commands "unknown" to Pandoc as 
Pandoc's native Div/Span syntax with `custom-style` attributes 
which you then could hook into when converting to DOCX with 
Pandoc.  It will probably become reality sooner than later.  The 
problem is how to handle commands/environments with multiple 
arguments (which argument is "the" text?) You can already have 
Pandoc preserve "unknown" LaTeX as raw LaTeX, which you then can 
use a Pandoc filter (written in Lua, Python, Perl, your language 
of choice) to massage into something suitable  UTF-8 is no problem 
as Pandoc uses it natively. It also understands standard 
babel/polyglossia commands, giving you a native span or div with a 
`lang` attribute which it then understands to handle correctly 
when converting to other formats.  There are some warts like 
`\textgreek` giving `lang="el"` rather than "grc" but that can be 
fixed with a Pandoc filter.  DOCX's (lack of) math capabilities 
may be another story though, but Pandoc surely does its best.


/bpj

Re: MikTeX fails to find a font installed in Windows 10 (for XeLaTeX)

[BPJ]

Have you tried omitting " Regular"?

Den mån 25 mars 2019 17:00P P Narayanaswami  skrev:

> I have problem using some open type fonts in Windows 10 with XeLaTeX in
> MikTeX.
> I downloaded a Malayalam language font, "Gayathri" and tried to use it
> in XeLaTeX.
> This font is clearly listed in the Font catalogue accessible from
> Control Panel.
> The Font catalogue lists its name as "Gayathri Regular".
> But when I use them in XeLaTeX with the command
>   \newfontfamily{\mal}[Script=Malayalam]{Gayathri Regular}
> MikTeX complains it cannot find the font and starts building 'tfm's,
> with the following Error message.
>
>   Package fontspec Error: "Gayathri Regular" cannot be found.
>
> I had the same problem with many other fonts in many other languages
> too.
> I guess it must be a  problem related to the way MikTeX identifying the
> fonts in the operating system.
>
> Another Malayalam language font "Kartika" that comes with Windows 10
> (when I installed the
> Malayalam language add-on in Windows 10) works fine in XelaTeX.  Hence I
> am puzzled.
> Any help will be appreciated.
>

Re: [XeTeX] bug in polyglossia/sanskrit? (problem with diacritical marks)

[BPJ]

Is it such a big deal? After all the long vocalic L occurs only in made up
words.

Den mån 20 maj 2019 20:44Steve White  skrev:

> Dominic,
>
> I already wrote to somebody listed at the tiro.com website.
> Yes, please, you point out the issues to the Sanskrit2003 people.
>
> On Mon, May 20, 2019 at 7:40 PM Dominik Wujastyk 
> wrote:
> >
> > Thank you for all this exploration, Steve!
> >
> > If you can talk to the Murty people, perhaps I can try the Sanskrit 2003
> folks.  I've emailed with them successfully in the past, about (C) (which
> is liberal but not well documented by them).
> >
> > Dominik
> >
>

Re: [XeTeX] Colour specials for XeTeX

[BPJ]

Den sön 7 juni 2020 11:02Philip Taylor 
skrev:

>
>
>   As it turns out, the \special {color push} that
> he mentions no longer works, but \special {color push }) does, as
> do the other two, yet I cannot find out where their behaviour
> is defined other than in the source code. /Surely /they must be defined
> somewhere, and not just have sprung into existence of
> their own volition ...
>

Well as everything in a computer program they are defined in the source
code.
It is not the first time some feature of a computer program is
insufficiently or not at all documented, and probably not the last time
either. It is certainly disappointing when you for whatever reason can't
figure them out from looking at the source code, but it is also good to
keep in mind that the reason some feature is undocumented often is that the
developers consider the feature unreliable. The code may be retained either
because the developers hope to fix it if and when they figure out how to do
it, or because removing it may cause other things to break, so there may be
"good" reasons if you can't get them to work as intended or expected.

I sincerely hope you find a workaround.

/Benct

>

Re: [XeTeX] Colour specials for XeTeX

[BPJ]

Den sön 7 juni 2020 21:34Philip Taylor 
skrev:

>
>
> BPJ wrote:
>
> > Well as everything in a computer program they are defined in the source
> code.
>
> That is the very antithesis of Dijkstra's position on the subject, and I
> strongly agree with him !  The behaviour / syntax / semantics are described
> outside of the program — the program is merely one of many possible
> realisations of the desired behaviour.
>

Dijkstra was a great theoretician, and in principle it is of course right
that the spec/documentation should dictate the behavior, but as we all know
there is usually, for practical reasons, more or less distance between
theory and practice, and in practice a piece of software does what the code
tells it to do, no more no less.  Personally I hate it when the
spec/documentation describes some feature only to be told that it is "not
(yet) implemented", yet partial or divergent implementations are quite
common, and at the end of the day a partial implementation is usually
better than no implementation at all. I am myself involved in a project
which has several implementations for different languages and it is very
hard to keep them all in synch, not least because the different
implementations depend on different libraries which dictate how and if
things can be done more or less easily. In practice one implementation is
ahead of the other two while another is more or less stalled. No fun but a
fact of life, especially in a volunteer project where time is limited.

In my daytime work as a documentation writer/translator (since comparative
philology jobs are short in supply so that I must take whatever job needs a
polyglot :-) it is rather the rule that the documentation lags behind the
implementation than the other way around, not least because documentation
writers depend on information relayed from designers and/or developers,
which often is of let's say differing quality. I'm usually faced with notes
in what amounts to a mixture of Swedish/Danish and English jargon which I
have to iron/flesh out to something users will understand. With volunteer
projects documentation is of course usually written by the developers
themselves and documentation may lag behind implementation because writing
documentation is seen as hard and/or time consuming


> > It is not the first time some feature of a computer program is
> insufficiently or not at all documented, and probably not the last time
> either. It is certainly disappointing when you for whatever reason can't
> figure them out from looking at the source code, but it is also good to
> keep in mind that the reason some feature is undocumented often is that the
> developers consider the feature unreliable. The code may be retained either
> because the developers hope to fix it if and when they figure out how to do
> it, or because removing it may cause other things to break, so there may be
> "good" reasons if you can't get them to work as intended or expected. I
> sincerely hope you find a workaround.
>
> Well, the set of colour \specials in which I am interested appear to have
> been existence since 1992 or earlier, so if they /were/ unreliable one
> might think that that would have been noted and reported by now.


I doubt that any one implementation used in 2020 is from 1992, and each new
implementation may bring with it new difficulties.

But I am delighted to say that having searched the online TUGboar archive,
> I was able to track down some of the earlier discussion of this set of
> specials, especially in articles written by Thomas Hafner, and these in
> turn led me to investigate the documentation for Tom Rokicki's "DVIPS"
> program ('TeXdoc dvips'), in which, to my great joy, I was able to read :
>

Good! I hope the current implementation lives up to the spec!

/bpj


> > 7.6 Color support details
> > To support color, Dvips recognizes a certain set of specials. These
> specials start with the
> > keyword ‘color’ or the keyword ‘background’, followed by a color
> specification.
> >
> > 7.6.1 Color specifications [...]
> >
> > 7.6.2 Color specials
> > We will describe ‘background’ first, since it is the simplest. The
> ‘background’ keyword
> > must be followed by a color specification. That color specification is
> used as a fill color for
> > the background. The last ‘background’ special on a page is the one that
> gets issued, and
> > it gets issued at the very beginning of the page, before any text or
> specials are sent. (This
> > is possible because the prescan phase of Dvips notices all of the color
> specials so that the
> > appropriate information can be written out during the second phase.)
> >
> > The ‘color’ special itself has three forms. The first is jus

Re: [XeTeX] Coloured fonts

[BPJ]

Last time I looked the glyphs in colored fonts are bitmap images anyway, so
you might just to create a set of images from the font and use them, or you
might take the right characters from a regular vector font and use XeTeX's
regular font color mechanism to make the red ones appear red, perhaps
adding a box if you can't use characters from the chess symbols block.
Surely not as spiffy but it will work.

-- 
Better --help|less than helpless

Den tors 18 mars 2021 19:40Philip Taylor  skrev:

> Seeking to re-typeset a long out-of-print classic on Xiang-Qi ("Chinese
> Chess"), but with the pieces shewn as they really are rather than as
> upper-case Latin letters requiring a gloss (the presentation chosen by the
> original author), I downloaded and installed Andrew West's BabelStone
> Xiangqi Colour font .  I
> then wrote a short piece of XeTeX code to check that the glyphs/pieces
> appear in the PDF as they should, and very sadly they do not, coming out as
> monochrome rather than in colour (see attached PDF).
>
> The red pieces are described by Andrew as *red Chinese characters on a
> sandy yellow background*, and the black pieces as *black Chinese
> characters on a sandy yellow background.*  In the resulting PDF, however,
> they appear as white Hanzi on a black ground and black Hanzi on a white
> ground.  Does XeTeX support coloured fonts, and if so, how do I persuade it
> to render these glyphs as intended rather than in monochrome ?
>
> I can, of course, load \font \redpieces = "BabelStone Xiangqi
> Colour":color=FF scaled \magstep 5 (see code below), but that still
> does not give me the sandy yellow ground that each glyph was designed to
> have.
>
> 'opentype-info.tex', when run against BabelStone Xiangqi Colour, tells me
> that the font does not provide any Opentype layout features, so it does not
> look as if XeTeX's "/ICU:+abcd" convention would allow me to indicate that
> I require colour support.
>
> % !TeX Program=XeTeX
>
> \font \pieces = "BabelStone Xiangqi Colour" scaled \magstep 5
> \font \redpieces = "BabelStone Xiangqi Colour":color=FF scaled
> \magstep 5
> \font \blackpieces = "BabelStone Xiangqi Colour" scaled \magstep 5
> \pieces
> \centerline {\char "1FA60\relax \ \char "1FA61\relax \ \char "1FA62\relax
> \ \char "1FA63\relax \ \char "1FA64\relax \ \char "1FA65\relax \ \char
> "1FA66\relax}
> \centerline {\strut}
> \centerline {\char "1FA67\relax \ \char "1FA68\relax \ \char "1FA69\relax
> \ \char "1FA6A\relax \ \char "1FA6B\relax \ \char "1FA6C\relax \ \char
> "1FA6D\relax}
> \centerline {\strut}
> \centerline {\strut}
> \centerline {\redpieces \char "1FA60\relax \ \char "1FA61\relax \ \char
> "1FA62\relax \ \char "1FA63\relax \ \char "1FA64\relax \ \char "1FA65\relax
> \ \char "1FA66\relax}
> \centerline {\strut}
> \centerline {\blackpieces \char "1FA67\relax \ \char "1FA68\relax \ \char
> "1FA69\relax \ \char "1FA6A\relax \ \char "1FA6B\relax \ \char "1FA6C\relax
> \ \char "1FA6D\relax}
> \end
>
> --
> *Philip Taylor*
>
> This email, its contents and any attachments are intended solely for the
> addressee and may contain confidential information. In certain
> circumstances, it may also be subject to legal privilege. Any unauthorised
> use, disclosure, or copying is not permitted. If you have received this
> email in error, please notify us and immediately and permanently delete it.
> Any views or opinions expressed in personal emails are solely those of the
> author and do not necessarily represent those of Royal Holloway, University
> of London. It is your responsibility to ensure that this email and any
> attachments are virus free.
>
>

Re: [XeTeX] Guaranteed Unicode replacement glyph in every TeX installation?

[BPJ]

Den sön 22 aug. 2021 00:25Doug McKenna  skrev:

> Ulrike -
>
> Excellent.  Thank you!
>
> Using \setmainfont{DejaVuSerif.ttf} works on my non-Linux machine, and it
> is not listed as "installed" in my Mac's FontBook, which means it's being
> used solely within the TeXosystem.
>
> DejaVuSerif is a variable-width font.  Is there a similar fixed-width
> OpenType/TrueType font distributed with TeXLive that would work?
>

If there is DejaVu Serif there probably is DejaVu Sans Mono too. You may
want to look at the Noto Fonts from Google (that would be Noto Sans Mono
rather than the superseded Noto Mono!) which may have better Unicode
coverage, although the replacement character should be available in both.
Don't forget to use the Scale=MatchLowercase option!

/bpj



>
> Doug McKenna
> Mathemaesthetics, Inc.
>
>
>
> - Original Message -
> From: "news3" 
> To: "xetex" 
> Sent: Saturday, August 21, 2021 10:39:25 AM
> Subject: Re: [XeTeX] Guaranteed Unicode replacement glyph in every TeX
> installation?
>
> Am Sat, 21 Aug 2021 09:25:14 -0600 (MDT) schrieb Doug McKenna:
>
> > Thanks all for your interesting responses.
> >
> > Unfortunately, my possibly poorly worded question remains unanswered.
> Let me try again.
> >
> > Consider the short example just used:
> >
> > \documentclass{article}
> > \usepackage{fontspec}
> > \setmainfont{DejaVu Serif}
> >
> > \begin{document}
> > fffd
> > \end{document}
> >
> > When I run it, fontspec complains that it can't find the font. So
> obviously "DejaVu Serif" is not installed, either on my system or anywhere
> in the bowels of all the ~150,000 TeXLive (2019) files that have been
> installed in the TDS on my machine.
>
> No, it only says that it is not found by fontname. Something that
> happens often on linux. Try with \setmainfont{DejaVuSerif.ttf}
>
>
> > So, is there a font name I can use in the \setmainfont{} command
> > that is ALWAYS available (upon TeX installation) when processing
> > this LaTeX file with XeTeX? Or always available after a certain
> > version of a TeX installation?
>
> I have no idea when DejaVu was added but it is in texlive 2019.
> If you want to support also older systems try e.g. on overleaf.
>
>
>
> --
> Ulrike Fischer
> http://www.troubleshooting-tex.de/
>

Re: [XeTeX] TECkit Mapping Editor

[BPJ]

Den ons 3 nov. 2021 21:44Jonathan Kew  skrev:

> Hi Dominik,
>
> I'm afraid it's unlikely (in my opinion) that any further development
> will be done on that tool.
>
> What I'd suggest is to look for a programmer-oriented text editor or IDE
> that can be configured to conveniently run arbitrary tools command-line
> tools (e.g. from a "Build" menu or similar), and perhaps also has
> configurable syntax coloring features that can be set up to recognize
> the TECkit keywords, etc.
>

I have done so in Vim successfully some years ago, including writing a
rudimentary syntax file. If anyone is interested I can see if I can find
it. (It is on one of the hdds from my old desktop. I have a docking station
so I can access them relatively easily.)

/bpj



> Jonathan
>
> On 03/11/2021 18:20, Dominik Wujastyk wrote:
> > The documentation for TEC mapping files mentions the Mapping Editor. But
> > a) I can't find it for Linux, and b) it "does not handle mapping
> > descriptions written as Unicode text; it is strictly an 8-bit editing
> > environment."  Is there any chance that these limitations, especially
> > the latter, might be addressed in future?  Especially for Asian
> > languages that have widely-used transliteration schemes and multiple
> > alphabets (like Sanskrit), TECket mapping has moved way beyond its
> > original purpose of mapping legacy 8-bit charsets.
> >
> > Best,
> > Dominik
> >
> >
> >
> >
> > --
> > Professor Dominik Wujastyk
> > <https://apps.ualberta.ca/directory/person/wujastyk>
> > ,
> >
> > Singhmar Chair in Classical Indian Society and Polity
> > ,
> >
> > Department of History, Classics, and Religion
> > <http://historyandclassics.ualberta.ca/>
> > ,
> > University of Alberta, Canada
> > .
> >
> >
> > South Asia at the U of A:
> > sas.ualberta.ca <http://sas.ualberta.ca/>
> >
> > SSHRC research: The Suśruta Project <http://sushrutaproject.org>
>
>

Re: [XeTeX] Off topic (interesting) question

[BPJ]

The Indo-European root is _*weyd-_ 'see' > _*weydtōr_ 'seer, knower,
examiner' > ἵστωρ. According to Rix's small historical grammar which is the
only relevant source I have to hand at the moment Attic has _hVs-_ for
_*wVs-_ (V = a vowel), although the only example he gives is ἕσπερος, cf..
Latin _vesper_. He doesn't say whether it is exceptionless but the argument
from silence ought to be that it is. (The normal source of Greek _h-_ is
PIE _*s-_, but _*y-_ — yod — also gives Greek _h-_ cf. ἧπαρ, Latin _iecur_.)

I note that Herodotus spoke and wrote Ionian which was a psilotic
(h-dropping) dialect, which may have influenced the preferred spelling of
ἱστορία in later times, but it would seem that _historia_ is actually the
spelling, and early on pronunciation, which Atticizing Latin literati would
be expected to adopt. Non-psilotic diacriticization of Ionic texts on the
other hand is Atticizing hypercorrection from a time when all Greek had
become psilotic.

Note also that not just English but all Germanic languages write and
pronounce _h_ in this word, so the post-medieval consensus clearly is in
favor of _h_ as far as Latin is concerned.

Over and out from a once-upon-a-time Indo-Europeanist (although mainly
Germanicist!)

/Benct

Den lör 20 aug. 2022 11:24Apostolos Syropoulos via XeTeX 
skrev:

>
> Hi everybody,
>
> Many readers of this mailing list are
> native English language speakers and
> the following question is for them.
>
> Someone claimed that English people (I say
> more generally English language speakers)
>  learn at school why you write history and
> not istory. Since I do not know I'd this holds, I
> am asking: Is this true? Does someone who
> has graduated from high-school know the
> reason why this happens?
>
> Kindest regards,
>
> Apostolos Syropoulos
>
>
> Στάλθηκε από το Ταχυδρομείο Yahoo σε Android
> 
>

[XeTeX] fontspec: loading different shapes/scales of one font as different font instances?

[BPJ]

As the subject line says I wonder if it's possible
with fontspec to load different shapes of the same
font as different font instances?

The thing is I'm going to write a script which
generates XeLaTeX source and where the user is to
be able to choose their own fonts/shapes/sizes for
elements like text and headings, and I hope to be
able to define a font instance for each of these
elements but not to have to check if they want,
say, italic or smallcaps headings scaled n and
stick in formatting commands if they do!

(Some of you may balk at italic/whatever headings,
but in my case the linguistics anti-prescriptivism
pill went down rather successfully, and I'd hate
to be prescriptivist when I don't have to. Besides
it is sometimes the case that bold is used with
some technical signal value beside italics and
I've found it convenient to set headings in
smallcaps in such cases.[^1])

[^1]: This in turn requires an amount of
\addcontentsline gymnastics. I'd appreciate
pointers on methods/packages to globally styling
headings/toc entries independently of each other.
I'm probably showing my ignorance here, or my
needs/wishes are really fringe! texdoc'ing
"contents" or "toc" turns up nothing useful, and
section.sty seemeth to be an olde and arcane dogge
(at least to me!)

/BP 8^)>

--
~~
 "C'est en vain que nos Josués littéraires crient
 à la langue de s'arrêter; les langues ni le soleil
 ne s'arrêtent plus. Le jour où elles se *fixent*,
 c'est qu'elles meurent."   (Victor Hugo)


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] fontspec: loading different shapes/scales of one font as different font instances?

[BPJ]

2010-07-30 06:25, Will Robertson skrev:

\newfontfamily\foo[]{}


The ability to say

\newfontfamily\foo{Foo Bold} Bar baz

or rather

\newfontfamily\foo[Style=Bold]{Foo} Bar baz

% Where "Bold" could be Bold/Italic/BoldItalic/SmallCaps/Normal

and get the equivalent of

\newfontfamily\foo{Foo} \bfseries Bar baz

Though I guess providing a Style option for the user
and insert \bfseries etc. / define commands including
them will actually be necessary anyway...

/BP


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] fontspec: loading different shapes/scales of one font as different font instances?

[BPJ]

2010-08-01 20:11, Khaled Hosny skrev:

On Sun, Aug 01, 2010 at 07:53:58PM +0200, BPJ wrote:

2010-07-30 06:25, Will Robertson skrev:

\newfontfamily\foo[]{}


The ability to say

 \newfontfamily\foo{Foo Bold} Bar baz

or rather

 \newfontfamily\foo[Style=Bold]{Foo} Bar baz

 % Where "Bold" could be Bold/Italic/BoldItalic/SmallCaps/Normal

and get the equivalent of

 \newfontfamily\foo{Foo} \bfseries Bar baz

Though I guess providing a Style option for the user
and insert \bfseries etc. / define commands including
them will actually be necessary anyway...


If you want a specific style, then use \newfontface not \newfontfamily.




D'oh, thats what i MEANT, but the fact remains:
I still need to put in the \bfseries etc.
No big deal anymore as I *will* need to request
the style for each element type as an independent
user input param anyway...

/BP


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] fontspec: loading different shapes/scales of one font as different font instances?

[BPJ]

2010-08-01 22:29, Alan Munn skrev:


On Aug 1, 2010, at 4:08 PM, BPJ wrote:


2010-08-01 20:11, Khaled Hosny skrev:

On Sun, Aug 01, 2010 at 07:53:58PM +0200, BPJ wrote:

2010-07-30 06:25, Will Robertson skrev:

\newfontfamily\foo[]{}


The ability to say

\newfontfamily\foo{Foo Bold} Bar baz

or rather

\newfontfamily\foo[Style=Bold]{Foo} Bar baz

% Where "Bold" could be Bold/Italic/BoldItalic/SmallCaps/Normal

and get the equivalent of

\newfontfamily\foo{Foo} \bfseries Bar baz

Though I guess providing a Style option for the user
and insert \bfseries etc. / define commands including
them will actually be necessary anyway...


If you want a specific style, then use \newfontface not \newfontfamily.




D'oh, thats what i MEANT, but the fact remains:
I still need to put in the \bfseries etc.



If the font has separate Bold, Italic etc., then no.

e.g. \newfontface{\bold}{TeX Gyre Heros Bold}

then \bold foo

will produce 'foo' in the bold version of the font.


Sorry. All's well: an uppercased letter too many had crept in.
I had literally written:

\newfontface{\foo}{DejaVu Serif Bold} \Foo Foo bar

instead of what it should be.  In other words I got what
I deserved for fooing around too much!

I'll still need to stick in commands/define features to
get smallcaps, though...

/BP


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Separate fonts for Latin and Greek with fontspec?

[BPJ]

2010-09-17 10:51, Michiel Kamermans skrev:

There are ways to automate the process, but I pretty much already
wrote those, so I might as well put up the package I have sitting
here... it's currently on
projects.nihongoresources.com/downloadables/ucharclasses.tgz
<http://projects.nihongoresources.com/downloadables/ucharclasses.tgz>.
The package supports setting fonts for Unicode "blocks" as well as
informal groups, so you will probably want to simply bind your
fonts of choice to informal "Latin" and "Cyrillic" groups:


Nice!

My two worthless coins:

1. What about a command for defining arbitrary ranges?
   This would be useful if one mucks around in different
   subblocks of the PUAs, particularly.  Something like:


\setTransitionRange{}{}{}{}

so that one could say e.g.:

 \setTransitionRange{57344}{57471}{\fontspec{MyOwnFont}}{}
 \setTransitionRange{57472}{57583}{\fontspec{MyOtherFont}}{}

Looking at your setup I guess a (first) command giving a
custom name for internal use to the range-as-class would
be needed, but you get the idea.

2. If it would be possible to give the range numbers in the
   hexadecimal usually used to refer to Unicode codepoints
   would be even nicer!

Too bad BTW that "Phonetics" isn't definable as an informal group!

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Separate fonts for Latin and Greek with fontspec?

[BPJ]

2010-09-17 13:14, Michiel Kamermans skrev:

Too bad BTW that "Phonetics" isn't definable as an informal group!


Indeed, but that exposes the inherent problem of multiple
languages using scripts that overlap with other languages...

[snip]

Unicode went with "scripts", but that's basically equivalent to
doing what Polyglossia does, where you indicate what the following
stretch of text is. It works great, but you have to put in more
commands, and the source becomes hard to read if you switch
languages several times on a page, or within a paragraph.


Well, the error was for Unicode to assume that IPA 
be identical to Latin  while being perfectly happy
that Cyrillic  be different.  The IPA a-z (and the
IPA βθχ) have one important property which sets them
off from their Latin (and Greek) counterparts (quite
apart from details of shape in the case of β), namely
that they don't capitalize! This bit me once when a
snippet of IPA got wrongly capitalized in a page
heading.  This is not a problem if you *know* that your
snippet of text contains IPA but any text input which
is going to be handled programmatically must be
tagged/marked up and the program made to look for the
tagging and take measures to apply the right casing
behavior.

I've made a habit of using and defining an \IPA command
-- usually just defined as \let\IPA\MakeLowercase --,
and similarly using an IPA class with proper style
definitions when producing HTML, and using it
consistently just in case I should later apply some
formatting to surrounding text which is unwanted for
the phonetics.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Greek XeLaTeX

[BPJ]

2010-10-12 11:25, Philip Taylor (Webmaster, Ret'd) skrev:

In another forum, I have suggested that one way to permit this
is to define an underlying (numeric) canonical representation
(at the time, I was writing of CSS, but the idea is equally valid
for TeX, or indeed for most other computer-related languages).


That would be living hell for anyone with dyscalculia!
While an underlying representation could of course be
verbal, the idea of needing a renderer is not attractive.
Indeed one of the advantages of *TeX is that you can view
it and work on it in a text editor. It's for a reason
that I'm not using WYSIWYG! The main disadvantage with
WYSIWYG is that you have to look somewhere else -- a
toolbar or the like -- to see the structural information,
and you can only see it for the elements enclosing the
cursor. But everybody here knows that, of course!

Personally I find it advantageous to have the markup
based on another language than the text, since then
text and markup stand out better from each other.
It's harder for me to *read* LaTeX source with
English text, not that I exactly enjoy reading any
marked-up text/source code without color highlighting!

In a way punctuation/symbol-based markup is the best
of both worlds, but markdown/wiki markup only gets you
so far.  If there were more symbolizations than a dozen
or two it would be too hard to remember and type them!

/bp


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] Unicode hyphens etc. and Xe(La)TeX

[BPJ]

I'm trying to find out if and how Xe(La)TeX does
or can be made to treat the following characters
different frem each other and/or in a 'smart' way:

1) U+002D HYPHEN-MINUS
2) U+00AD SOFT HYPHEN
3) U+2010 HYPHEN
4) U+2011 NON-BREAKING HYPHEN

Specifically I'd like to get the correct behavior for
Swedish so that a linebreak may occur after an ASCII hyphen
but not after a Unicode non-breaking hyphen. While globally
replacing every Unicode soft hyphen with \- is easy you
cannot, unfortunately, globally replace every ASCII hyphen
with some command which would do the right thing (whatever
that command may be) as the ASCII hyphen may occur in
command arguments which I've already inserted, and which are
not to be interpreted as text. (Though I think that such would 
typically be followed by a digit rather than a letter...)


I also have sort of the same thoughts about

5) U+00B7 MIDDLE DOT
6) U+2027 HYPHENATION POINT

or rather I would want some way to distinguish between a
middle dot after which a linebreak may occur and one after
which it may not.

I guess I'm basically looking for a \maylinebreak command!

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Unicode hyphens etc. and Xe(La)TeX

[BPJ]

2010-11-01 13:53, Roland Kuhn skrev:

Generally, I recommend using the correct unicode characters in
the TeX source and then define the behavior you want for them.


Yup, that's kind of the idea!


In this case, this is fairly straight-forward:


Yes. Since I didn't know about discretionaries I looked up the
description of \discretionary at

<http://www.tug.org/utilities/plain/cseq.html#discretionary-rp>

But I ended up replacing Unicode characters with commands anyway.
That the various Unicode hyphens don't look different in the
TeXWorks editor is a real problem. The perl oneliners

perl -pe's/(?<=\pL)\x{2011}(?=\pL)/\\\x{2013}/g'
perl -pe's/(?<=\pL)\x{2027}(?=\pL)/\\\x{b7}/g'

and defining

\def\–{\hbox{-}} % \ = nobreak hyphen
\def\·{·\discretionary{}{}{}}% Middle dot

pretty much did the trick.  Thanks!

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

[XeTeX] \textsuperscript and \textsubscript size

[BPJ]

Is it an optical illusion, or is the size of \textsuperscript and
\textsubscript rather like \tiny than like \scriptsize?

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] \textsuperscript and \textsubscript size

[BPJ]

2010-11-06 21:25, Peter Dyballa skrev:


Am 06.11.2010 um 20:08 schrieb BPJ:


Is it an optical illusion, or is the size of \textsuperscript and
\textsubscript rather like \tiny than like \scriptsize?



Sometimes is neither this nor that but a decision of the font
designer – some fonts have subscript and superscript glyphs!


Yes, I found out it was exactly that.

Also found out that xltxtra has an option to influence this.

The thing is I specifically wanted to get some characters on
the line which were the same size and shape as the s*scripts.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Hyphenated, transliterated Sanskrit.

[BPJ]

2010-11-21 10:22, Manuel B. skrev:

1) I saw that that all diacritics used for IAST appear in the pattern,
while some of them (for example ṛ and ṝ) are marked as "non standart
transliteration". That is OK, insofar as IAST is not a standart in the
official sense. But IAST is most commonly used and the "standart"
transliteration of vocalic r in IAST is ṛ, not r̥.


The problem is that since for Hindi and other modern
Indic languages ṛ is used for the retroflex flap
-- ḍ with underdot in Nagari -- modeled on the
Urdu letter for that sound.  In a strict
transliteration you need a way to distinguish
between the two, and between ri and r̥.  Since
Indo-Europeanists have been using r̥ for over a
century that's obviously the best choice.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Hyphenated, transliterated Sanskrit.

[BPJ]

2010-11-22 18:24, Dominik Wujastyk skrev:

Those who write both transliterated Hindi and Sanskrit in the
same publication will be glad of the ISO standard, I suppose.


You have the problem in transliterated Hindi on its own, since
both graphemes occur there.  In fact they are in complementary
distribution, and in a way which would be easy to automatize,
but being different graphemes they should be transliterated
differently.  Retransliteration shouldn't require linguistic
analysis.


Typical standard's work: result of a committee that has a
certain limited logic to it, but pays not enough attention to
usage amongst professional groups, and consequently leaves
nobody actually happy.


Agreed.  I'm definitely not a friend of standards for
standards' sake, but that applies to century-old standards
founded by people not considering modern languages too!
Of course you _can_ use different transliterations for Sanskrit 
and Hindi, but IMHO transliteration should be by script and not

by language. But let's be thankful nobody came up with d̤ for ड़
since IPA uses d̤ for ध!

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] No-Break Space

[BPJ]

2011-02-20 18:03, enrico.grego...@univr.it skrev:

Alexander wrote:


I decided to try to replace the sign "~" in my text on the analogue of
the Unicode (code 00a0), and the words that are connected in such a
space no longer hyphenated. Is this normal? Or a feature not yet
implemented?


The problem is that U+00A0 has zero lccode and (Xe)TeX abandons hyphenation
whenever it finds such a character. So the solution would be to add

   \lccode"A0="A0

to you preamble. However, this is not a good solution, because this "space" will
not stretch or shrink together with the other interword spaces on the same line.
The explicit tie is way better. You can achieve the same behavior as ~ with

   \catcode`=\active
   \protected\def{\nobreakspace{}}

or, loading the new package newunicodechar,

   \newunicodechar{}{\nobreakspace{}}

Here  denotes the character U+00A0, of course and that
character must be used.


I just realized that the solution to a problem I've had may lurk 
here: I've been using interpuncts U+00B7 inside some words, and

XeTeX won't hyphenate those words.  However it's not only that I
want them hyphenated -- I don't want them hyphenated too close
to the interpunct!  Never closer than two ordinary letters and
preferably more if possible.  When there are many of those words
it gets quite annoying to insert soft hyphens by hand.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] No-Break Space

[BPJ]

2011-03-02 17:04, enrico.grego...@univr.it skrev:

BPJ wrote:


I just realized that the solution to a problem I've had may lurk
here: I've been using interpuncts U+00B7 inside some words, and
XeTeX won't hyphenate those words.  However it's not only that I
want them hyphenated -- I don't want them hyphenated too close
to the interpunct!  Never closer than two ordinary letters and
preferably more if possible.  When there are many of those words
it gets quite annoying to insert soft hyphens by hand.


You can try with

\newunicodechar{·}{·\nobreak\hspace{0pt}}

Thus the MIDDLE DOT will typeset itself, there will no line break
after it and the \hspace{0pt} allows the following word to be
hyphenated. You can't control the number of letters before the
hyphen, but (Xe)TeX is generally not abundant with hyphens.

Note that you can use the defined character in the second argument
as itself, this is a felicitous consequence of the implementation of
\newunicodechar. :)


Thanks, I'll try it.  What about *before* the dot?
Will \newunicodechar{·}{\hspace{0pt}\nobreak·\nobreak\hspace{0pt}}
do the trick? Although most dots appear after prefixes some
don't, and some prefixes are long too.

\bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Your advice for generation of tables/forms with decorations?

[BPJ]

2011-04-28 15:14, Kārlis Repsons skrev:

On Thursday 28 April 2011 09:27:22 André Bellaïche wrote:

Use Adobe Illustrator.

Typeset the table into a one page PDF file, open the file with Illustrator,
and add the decorations. Inport the decorated table using includegraphics.


But I need automation... Meaning, the created (EPS, MetaPost-like etc)
decorations get composed with text in *TeX!


Do you need automation in the sense of automatized
production of different PDFs with different tables *and*
different graphics in each file? If so Metapost probably is
your best choice for the graphics, though you will probably
need a script (shell, Perl or something else) to generate
the Metapost and *TeX source files. Needless to say that can
get ugly pretty quickly (code to write code -- been there,
done that! ;-). You can have the same script, or another
script invoked by it, invoke ps2pdf to convert Metapost
output to PDF and pdftk to stamp the one PDF with the other
(if you are comfortable with Perl and need a biggish script
for the job there is a PDF::Tk module which I've used, and
searching CPAN for "latex" may also turn up some useful
things), unless you can import the graphics file into the
PDF generated by *TeX from inside *TeX.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Diacritic marks in various fonts

[BPJ]

2011-06-23 19:11, Peter Baker skrev:


I'm working towards a new release, perhaps in late July or August.
If anyone is having a problem with Junicode, I'd love to hear from
you between now and then.


Please make it that U+0067 U+0327 display properly as U+0123!

U+0123 LATIN SMALL LETTER G WITH CEDILLA
UTF-8: c4 a3  UTF-16BE: 0123  Decimal: ģ
ģ (Ģ)
Uppercase: U+0122
Category: Ll (Letter, Lowercase)
Bidi: L (Left-to-Right)
Decomposition: 0067 0327

Also would you mind providing a shape for U+A763 with a larger
upper loop -- i.e. more similar to the uppercase glyph --
at least as a stylistic alternative? The current glyph looks
cramped in a hard-to describe way. I suppose it's meant to
resemble early MSS shapes, but that seems to conflict with
harmonic glyph design in this case. (Admittedly my main
concern is to illustrate the origin of U+00E7 (ç) and that's
kind of hard with the current glyph; I'd like to have an
"intermediate stage" available. I guess a small-cap might do!)

Thirdly, do you plan to support the critters in the
Phonetic Extensions supplement? I use U+1DBB and U+1DBD
as diacritics for syllabic fricatives in Swedish dialects
(including my native dialect in fact!)

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] \hyphenation{} and combining diacritics

[BPJ]

2011-07-08 23:13, Dominik Wujastyk skrev:

Unicode normalization was discussed on this list a couple of
months ago.  Phil Taylor provided a small program to do the job,
and other utilities were referred to.  There's also a command
within XeTeX  that normalizes unicode before passing it to TeX's
digestion.  Try this in your header:

% Normalize any residual Unicode combining accents,
% and write out error messages, if any:
\XeTeXinputnormalization=1
\tracinglostchars=1
\tracingonline=1


Does \XeTeXinputnormalization=1 normalize to NFC or NFD?
I need to use U+0123 LATIN SMALL LETTER G WITH CEDILLA
sometimes, and have found that most fonts make a mess of
it in NFD!

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xelatex question

[BPJ]

On 2011-08-16 00:07, Ross Moore wrote:

Hello Steve,

On 15/08/2011, at 4:27 PM, Steve Deckelman wrote:


Dear Ross, I came across one of your posts on the net. Would you know if there is 
something like a "pinyin" package for xelatex?  Something similar to the one 
for CJK that would allow me to type set things like \Wo2 and have it typeset in pinyin 
with accent 2.


Please post to the XeTeX mailing list.
See:
http://tug.org/mailman/listinfo/xetex


Someone there is likely to be able to help with such technical
problems.


You could create a TECkit mapping with all possible syllables
(in all possible case variations), or even better, write a
script which writes the mapping. In fact I might just go about
doing that if someone can suggest somewhere to host it.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] traditional to simplified Chinese character conversion utility or data base

[BPJ]

On 2011-10-22 08:11, Zdenek Wagner wrote:

On Tue, Oct 18, 2011 at 2:53 PM, Zdenek Wagner  wrote:

>>  If you wish to do it on the fly in XeTeX,  you can write a TECkit map.

>
>  I do have a map now. Can someone tell me how to do the conversion "on
>  the fly" in XeLaTeX? I did see the command line option
>  "-translate-file=TCXNAME", but for that it says "(ignored)".
>

\usepackage{fontspec}
\setmainfont[Mapping=mapname]{fontname}

or

\fontspec[Mapping=mapname]{fontname}


or

\newfontfamily\[Mapping=mapname]{System Family Name}

or

\newfontface\[Mapping=mapname]{System Family Name Bold}
where bold can be Bold/Italic/Bold Italic/Normal,

if only part of the document should use the map or the font.

see section I.6 of the fontspec documentation.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [tex-live] Future state of XeTeX in TeXLive

[BPJ]

On 2011-10-28 21:02, Zdenek Wagner wrote:

2011/10/28:

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.


Documents being written by several people in cooperation in real time
(usually living in a versioning system)

Documents that have to be rendered from sources on several different platforms

Documents that have to be rendered from sources years later

Documents containing math

Documents created on-the-fly by a web service


Documents produced by people with motor or vision disabilities
which make it hard for them to use a WYSIWYG/GUI tool.

(I have both a motor disability and some vision difficulties,
but that shouldn't be a requirement for caring about the issue.)

BTW: is there a symmary of Xe(La)TeX/LuaTeX differences somewhere?
I can't say that I'm wild about the prospect of having to learn
another programming language on top of LaTeX to get things
working. This said I use perlTeX quite a bit, so I might have a
gain in learning Lua(TeX) all the same.

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Synching PDF paper size with typesetting size

[BPJ]

On 2011-11-07 13:43, William Adams wrote:

%converted to BP 'cause using mm made Acrobat 8 report an error


Aha, that's what I've been experiencing when trying
to create pdfs in PA4 (210 x 280 mm) format.

What's the conversion formula? According to
wikipedia 1 DTP point == 0.3528 mm. Is that it?

/bpj


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[BPJ]

On 2012-07-30 17:15, Dominik Wujastyk wrote:

Not long ago, Jonathan noted about a particular problem that,



The best chance of fixing this will be if xetex is updated some day to use
the new harfbuzz engine, but there's no immediate prospect of that, I'm
afraid.



Like most of us on this list, I use XeTeX, value it enormously, and depend
on it for day-to-day work.  But it's becoming clear to me that the
long-term maintenance of XeTeX is not assured.

Can we discuss this?


It says everywhere that luatex supports UTF-8, yet my (very
limited) understanding is that Unicode string support in *lua*
is entirely dependent on third party additions.  How does this
affect what one can do with lua in luatex?

I ask because I currently use xetex + perltex for some things.

/bpj




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[BPJ]

On 2012-08-01 01:48, Arthur Reutenauer wrote:


  How does this
affect what one can do with lua in luatex?


   It does not, really.  And this is not relevant to a discussion about
XeTeX.


It is, since it may determine how dependent I and others
may be on xetex still being around.  If the replacement
can't do what you want then you can't do the switch.

However I very much like being able to use teckit mappings,
so I really wish xetex will stay around.

/bpj




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] The future of XeTeX

[BPJ]

On 2012-08-01 13:44, Zdenek Wagner wrote:

2012/8/1 BPJ :

On 2012-08-01 01:48, Arthur Reutenauer wrote:


   How does this
affect what one can do with lua in luatex?



It does not, really.  And this is not relevant to a discussion about
XeTeX.



It is, since it may determine how dependent I and others
may be on xetex still being around.  If the replacement
can't do what you want then you can't do the switch.

However I very much like being able to use teckit mappings,
so I really wish xetex will stay around.


If you find the right hook, you can do the same eg with regular
expressions. it will be possible to do even more then with teckit but
the correct hooks must be found.


Of course -- I have written transliterators for use outside the
TeX world -- but it's very convenient to have such a thing
ready-made! :-)

/bpj




--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex