Re: [XeTeX] strange difference
On 2022-05-29 21:16, Apostolos Syropoulos via XeTeX wrote:
[...] The two files differ as follows:
28,29c28,29
< \node[inner sep=0pt] (light) at (1,2.1)
< {\includegraphics[scale=0.1]{TRAIN-crop.pdf}};
---
\node[inner sep=0pt] (light) at (5.2,3.5)
{\includegraphics[scale=0.1,angle=45]{TRAIN-crop.pdf}};
>
The question is why do I get different paper sizes?
You know that the size of the second \includegraphics with angle=45
is different?
The size of the second \includegraphics is a *square*. If w1 and h1
are the width and height of the first \includegraphics, then
the width w2 and h2 of the second \includegraphics with angle=45 are:
w2 = h2 = sqrt(1/2) * (w1 + h1)
or
w2 + h2
--- = sqrt(2) ≈ 1.4142
w1 + h1
Yours sincerely
Heiko
Re: [XeTeX] color name in headline bleeds into pdf bookmarks
Hello,
On 2022-01-12 16:41, Niemann, Hartmut wrote:
Hello!
I observed a strange thing when experimenting with colored text.
\usepackage{bookmark}
\section{\color{red}Two}
There is a pdf bookmark for each section, but the second one is “redTwo”
instead of “Two”.
Is there a way to avoid that?
Yes, use \textcolor instead of \color. The former macro is disabled
in bookmarks, the latter is not supported.
\section{\textcolor{red}{Two}}
Yours sincerely
Heiko
Re: [XeTeX] strange case of overlapping graphics
Hello, the properties of the PNG file "Zaborowski_MBC_page19y42_a.png" are (retrieved by display from ImageMagicks): png:IHDR.width=112 pixels png:IHDR.height=42 pixels png:pHYs.x_res=984 pixels/m ≈ 25 dpi png:pHYs.y_res=276 pixels/m ≈ 7 dpi The image has different resolutions in the x- and y-directions. The final image size is: width ≈ 113.8 mm ≈ 4.48 in height ≈ 152.2 mm ≈ 5.99 in The TeX compilers pdfTeX and LuaTeX correctly handle the image size. However, there is a bug in the XeTeX pipeline, the dimensions are correctly calculated (extractbb), but the image is embedded with the same resolution in both directions. I assume that the image looks distorted with pdfTeX. That means the different resolutions in the pHYs PNG chunk is wrong. You can fix this in Gimp --> Menu --> Image --> Scale Image: Set the same physical resolution value to both the "X resolution" and the "Y resolution". Some math: 3ex = 12.91663 pt = 42 pixels / resolution resolution = (42 pixels / 12.91663 pt) ≈ 3.25 pixels / pt * (72.27 pt / 1 in) ≈ 235 pixels / in [= dpi] * (1 in / 25.4 mm)≈ 9.2518 pixels / mm Do *NOT* change the width or height. This would cause scaling the image data with the quality settings. If only the resolution settings are changed, the image data are kept intact when the "Scale" button is pressed. Then the scaling operation only changes the resolution values for the images that are used, when the image is exported. Export the image as PNG with "Save resolution" enabled. Then, the new image can be used with pdfTeX, LuaTeX, and XeTeX. Since the x- and y-resolutions are the same, the bug of XeTeX is avoided. Yours sincerely Heiko
Re: [XeTeX] Problem with pdf
Hello, On 30.08.2015 11:14, M. Lin wrote: Please see the file in attached. There is no error when I compile it, The `.log` file clearly shows an error, the last two lines: Error 256 (driver return code) generating output; file test.pdf may not be valid. The next step is taking the advice of Zdenek Wagner: | If there is no error from xetex, it may be a problem of xdvipffmx and | its error message is lost. In such a case it is helpful to run wetex | with -no-pdf in order to create an xdv file and then run xdvipdfmx on | it separately. You will see the error message. xelatex --no-pdf test xdvipdfmx test The last command will show an error, what it is? Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with pdf
Hello,
On 29.08.2015 19:16, M. Lin wrote:
Hi,
I have problem with pdf output when I running xetex. There is no any
errors, but it does not produce pdf file.
This is normal, when there is no material to be shipped out, e.g.:
\documentclass{article}
\begin{document}
\end{document}
Therefore, more details are helpful, e.g.:
* Minimal example, which is supposed to set something like
\documentclass{article}
\begin{document}
Hello World
\end{document}
* The .log file of the XeTeX run.
Yours sincerely
Heiko
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On 04.08.2014 19:50, Stefan Solbrig wrote: Turns out we've also been bit by this problem... please see my questions below. On 2014-08-04 01:55, Heiko Oberdiek wrote: On 04.08.2014 01:27, Gildas Hamel wrote: I append the jpg file (tombe.jpg). The resolution data in tombe.jpg are inconsistent: * JFIF header: 72 DPI * EXIF header: 300 DPI What program did you use to determine this? Hex editor. Most image programs are quite useless for this problem, because they do not tell, which resolution data they are using. I'm looking at one of our jpgs in a text editor, and while I see the string Exif near the top, I don't see any jfif-like string. You can find 'JFIF' of tombe.jpg at position 6, meaning, there are six other bytes before the string. GIMP reports 72x72 ppi, but I don't know whether that's exif or jfif. Apparently JFIF. Apparently XeTeX uses the EXIF header, whereas xdvipdfmx the JFIF header (or vice versa). Is there a work-around? Fixing the resolution data. * Manual way with hex editor: Putting bytes 0x1 0x2C 0x1 0x2C at position 14 in tombe.jpg replacing bytes 0x00 0x48 0x00 0x48. Then the image has 300 DPI * Removing the EXIF header: jpegtran -copy none -outfile tombe2.jpg tombe.jpg This strips all extra stuff including EXIF from the JPEG file. Like using some image editor to produce a jpg file with jfif and exif headers that agree on the resolution (and I suppose have the correct one :-)), or maybe converting from jpg to some other format? Image editor and other format are problematic, because JPEG is a lossy format and decoding/encoding steps would decrease the quality unnecessary. I suppose I could create a PDF using pdflatex, and import that into my xetex file instead of the original jpg. Also possible, then XeTeX/xdvipdfmx will use the dimensions of the PDF file. The price is a little overhead of the PDF wrapper. There is a tool named exiftool that can do this. It modifies image metadata without changing the image itself. You can install it either via a package manger (in Debian it's libimage-exiftool-perl) or you can install it via CPAN (the perl package manager, because it it part of a perl package. If you use cpan, do: cpan cpan install Image::ExifTool The following two commands will set all resolution metadata known to exiftool to 300. exiftool -'*Resolution'=300 image.jpg The best workaround so far, especially, if the image data are kept unchanged. I haven't done a thorough testing of this tool, but for OP's image, it worked. (The command might need some refinement, depending on your needs.) To just read all the metadata, do exiftool -v image.jpg Very nice, but the interpretation of the output needs some background knowledge from the specifications, e.g.: JPEG APP0 (14 bytes): + [BinaryData directory, 9 bytes] | JFIFVersion = 1 1 | ResolutionUnit = 1 | XResolution = 72 | YResolution = 72 The values of the ResolutionUnit, from the specification (http://www.w3.org/Graphics/JPEG/jfif3.pdf): units = 0: no units, X and Y specify the pixel aspect ratio units = 1: X and Y are dots per inch units = 2: X and Y are dots per cm Result: 72 DPI JPEG APP1 (798 bytes): ExifByteOrder = MM + [IFD0 directory with 9 entries] | 0) Make = NIKON CORPORATION | 1) Model = NIKON D5100 | 2) Orientation = 1 | 3) XResolution = 300 (300/1) | 4) YResolution = 300 (300/1) | 5) ResolutionUnit = 2 That's the start of the EXIF header. (https://en.wikipedia.org/wiki/Exchangeable_image_file_format) ResolutionUnit can have one of two values: 2: dots per inch (DPI) 3: dots per cm Result: 300 DPI Yours sincerely Heiko -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On 04.08.2014 01:27, Gildas Hamel wrote: I append the jpg file (tombe.jpg). The resolution data in tombe.jpg are inconsistent: * JFIF header: 72 DPI * EXIF header: 300 DPI Apparently XeTeX uses the EXIF header, whereas xdvipdfmx the JFIF header (or vice versa). It would be nice, if the TeX programs (XeTeX, *dvipdfm*, pdfTeX, LuaTeX, bmpsize, ...) could agree on the same algorithm, which values resolution are used in which order. Then the images would have the same size on all TeX systems. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Depth of an index entry.
On 31.07.2014 19:14, Sharon Kimble wrote:
How can I have an index entry to a depth of 4? This works -
╭
│\index{ginseng!side-effects!nausea}
╰
but this doesn't -
╭
│\index{herbals!ginseng!s/e!insomnia}
╰
No, makeindex only supports three level.
Probably xindy can support more.
Usually two levels should be enough,
a further level for emergencies.
But IMHO four levels indicate a much too
complex index both for the writer and
the reader.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \subsubsection or something similar?
On 05.07.2014 19:01, Sharon Kimble wrote:
How can I have \subsubsection*{Indications} showing in the PDF, but
not in the toc? This is in the article class, and using the above
there is no differentation between the heading and the rest of the
text. \section is used for the chapter headings, \subsection for the
individual drug names, and \subsubsection for the individual sections of
the drug. Or is there anything that I could use in place of
\subsubsection please?
I assume you meant PDF bookmarks/outlines with PDF:
\documentclass{article}
\usepackage{hyperref}
\usepackage{bookmark}
\bookmarksetup{
depth=subsubsection,
numbered,
}
\setcounter{tocdepth}{2}
\begin{document}
\tableofcontents
\section{Chapter heading}
\subsection{Drug name}
\subsubsection{Individual section}
\end{document}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] embedding PDF, 1.4 vs. 1.5
On 17.06.2014 17:38, maxwell wrote: On 2014-06-17 11:31, maxwell wrote: Late last year, I ran into a problem in which I could embed a PDF v1.4, but not v1.5 (I have not tried this with newer versions of PDFs, which are now up to 1.7). The problem and its work-around are described here: http://tug.org/mailman/htdig/xetex/2012-October/023677.html also http://tug.org/pipermail/xetex/2012-December/023869.html The above work around involved a double conversion using pdf2ps, from PDF to PS and back again to PDF. There are other less invasive options: pdftk old.pdf cat output new.pdf Or use another PDF library for reading/writing. When the file is written, PDF object compression of PDF-1.5 must be disabled. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX/xdvipdfmx or the driver bug with eps images
On 28.05.2014 19:31, Zdenek Wagner wrote: 2014-05-28 18:21 GMT+02:00 Joseph Wright joseph.wri...@morningstar2.co.uk mailto:joseph.wri...@morningstar2.co.uk: On 28/05/2014 16:14, Akira Kakuto wrote: Dear Vafa Karen-Pahlav w.eps is taken from LaTeX graphics companion examples; therefore I do not think there is anything wrong with the image itself. What is wrong? It is sufficient to change the header of w.eps from %!PS-Adobe-2.0 to %!PS-Adobe-2.0 EPSF-2.0 in order to tell Ghostscript that w.eps is an eps file. Please try, then you will obtain an expected pdf. Thanks, Akira All true, but both latex + dvips and pdflatex produce the expected output, as do latex + dvipdfmx or xelatex with the older driver set up. dvips includes EPS directly, it does not need ghostscript, pdflatex is not able to insert EPS and if \write18 is allowed, epstopdf is called. Probably epstopdf invokes ghostscript in a different way than xdvipdfmx does. `epstopdf' does not require that the PostScript file is a strict Encapsulated PostScript file. It takes the BoundingBox it can find, moves the graphics to the origin, sets the new media size (setpagedevice) and calls ghostscript for the conversion to PDF. In the case that the PostScript file is *not* an EPS file, this might succeed or fail. XeTeX/xdvipdfmx/dvipdfmx are using ghostscript with option `-dEPSCrop', configured in TDS:dvipdfmx/dvipdfmx.cfg. This option *requires* EPS files. It seems that ghostscript can be fooled by an EPSF header line, e.g. %!PS-Adobe-2.0 EPSF-2.0 However, PostScript can use any PostScript operator, but EPS files are restricted. Problematic operators such as setpagedevice are forbidden. Renaming a file from .ps to .eps does *NOT* convert an PS file to an EPS file. It is much better to generate an EPS file in the first place (setting an option to create EPS instead of PS in the driver/program that generates the PostScript, ...). Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Tue, Jul 31, 2012 at 01:02:04PM +0200, Peter Dyballa wrote:
Am 31.07.2012 um 01:19 schrieb Zdenek Wagner:
Yes, I know. Similarly as XeTeX can set \pdfpageheight and
\pdfpagewidth (or use \special{papersize=...}) there might be a
similar \special for setting PDF version and compression but such
\special's do not exist.
For very good reason! \pdfminorversion is not only some monadic number,
it's also a guarantee that this document conforms to a particular
standard. XeTeX cannot guarantee that this will be true in the future
No, XeTeX/xdvipdfmx do *NOT* (never in past, present and probably future)
analyzes the PDF data structures that it writes in order to
determine the correct PDF version number. They have no clue what
the correct PDF version would be.
\pdfminorversion does *NOT* say the PDF will be in the specified
format, it merly writes the number in the header.
But *others* can query the number already in the TeX job!
Thus a package for rich annotation media stuff can *see*
a requested version number of PDF-1.2 and say, ``Ooups, sorry,
I can't work with oder PDF versions'' (defensive politics), or
force a higher version number if possible (aggressive politics).
Keep in mind, the PDF file in the PDF world is constructed by
many parties:
* Compiler/driver itself and its features (usually destinations,
annotations, bookmarks, ...)
* Macro software that implement some features using
generic interfaces (\pdfobj, \special{pdf:...}, ...)
* The user by choosing the features.
The compiler (XeTeX, pdfTeX) is only responsible for their own
stuff. For example, pdfTeX complains if object streams are
requested with versions smaller 1.4.
If you want a more reliable version number, then all that
parties have to work together. Also some kind of
version management would help that mediates the
conflicting requests:
* Use of features that need higher numbers.
* Restrictions for lower numbers such as compatibility or PDF/A.
pdfTeX, XeTeX, dvipdfm are too much cooled down for adding such
a system at the compiler/driver level. But the TeX world
is used to manage things at macro level (e.g. register management
in plain or LaTeX formats). But managing is pointless if there
is no control over the things that are managed.
* pdfTeX :-) because of \pdfminorversion.
* XeTeX: :-( annoying.
XeTeX and any other TeX compiler that I know have ever and probably
will be garantee that the version number that they have written
has something to do with the PDF file!
\pdfpageheight and \pdfpagewidth are alternatively set to allow the XDV to
\PDF convertor perform its job properly.
The same is needed for the PDF version. On the XeTeX side the same
mechanism could be used.
It is more difficult to create PDF/X
compliant file because I have to create XDV and then specify the PDF
version when calling xdvipdfmx but pdftex can set it directly.
Pdftex is the creator of the PDF file. It can assure certain things easily.
It makes the information flow easier. PdfTeX does not need
to serialize the date in an intermediate file because the
driver unit can use the data directly. But that is not an exuse
for XeTeX, just a few more bytes for the PDF version could
be added to the intermediate file. And the driver side (xdvipdfmx)
just need a function to read it from there.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] The future of XeTeX
On Tue, Jul 31, 2012 at 12:57:16AM +0200, Peter Dyballa wrote: Am 31.07.2012 um 00:40 schrieb Zdenek Wagner: 4. Setting PDF version: does XeTeX support \pdfminorversion and does it send a proper command to the xdv-pdf driver? I have not found such feature in the dvipdfmx manual. XeTeX cannot because it produces XDV, but xdvipdfmx (invoke it with --help) can. Within limits. It would be as easy as adding \specials, both for the XeTeX side and for xdvipdfmx. Also settings for compression level, object stream compression, ... would be useful. Example to generate uncompressed PDF: xe(la)tex --output-driver=xdvipdfmx -V4 -z0 But the most annyouning bug is the broken/crappy/unspecified interface to transfer binary bytes to PDF output structures. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] List of ligatures in a font
On Wed, Mar 14, 2012 at 07:43:45PM +0200, Tobias Schoel wrote: Could one test if ff and f\/f are equal with tex-primitives? If the width of the single characters differ to the ligture, then you can put both versions in boxes and compare the widths. In case of a ligature this does not necessarily mean that the output file contains a ligature glyph. It could be a fake ligature at TeX level that get replaced by something else, e.g. by using virtual fonts. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Producer entry in info dict
On Wed, Feb 29, 2012 at 09:57:04AM +1100, Ross Moore wrote:
On 29/02/2012, at 8:44 AM, Heiko Oberdiek wrote:
Hello,
the entries in the information dictionary can be controlled
at TeX macro level except for /Producer:
% xetex --ini
\catcode`\{=1
\catcode`\}=2
\shipout\hbox{%
\special{pdf:docinfo%
/Producer(MyProducer)%
/Creator(MyCreator)%
/Author(MyAuthor)%
/Title(MyTitle)%
/Subject(MySubject)%
/Keywords(MyKeywords)%
/CreationDate(D:2012010100Z)%
/ModDate(D:2012010100Z)%
/MyKey(MyValue)%
}%
}
\csname @@end\endcsname\end
Surely /Creator is (La)TeX, Xe(La)TeX, ConTeXt, etc.
while /Producer is the PDF engine:
Ghostscript, xdvipdfmx, pstopdf, Acrobat Distiller, etc.
and /Author is the person who wrote the bulk of
the document source.
Why should it be reasonable that an author can set the
/Producer and /Creator arbitrarily within the document
source?
What's wrong with meantioning XeTeX, for example?
Another reason: PDF/A requires that the information
date are duplicated in the XMP part. If a package
like hyperxmp tries to write the data as XMP, then
it has no chance to know the /Producer value.
The author chooses his workflow, and should pass this
information on to the appropriate package ...
He can't.
The entry for /Producer gets overwritten by xdvipdfmx,
e.g. xdvipdfmx (0.7.8). Result:
* Bug-reports/hyperref: pdfproducer={XeTeX ...} does not work.
* hyperxmp is at a loss, it *MUST* know the value of the
/Producer, because the setting in the XMP part has to be
the same.
... via options to \usepackage[...]{hyperxmp}
and the package should be kept up-to-date with the exact strings
that will be produced by the different processing engines, in all
their existing versions.
That's needs implementing clearvoyance. The (x)dvipdfm(x) driver
is running *AFTER* the TeX processing part.
I know that one processor cannot know in advance how its output
will be further processed, but that is not the point of XMP.
Then the (x)dvipdfm(x) driver must also fix the producer entry
in the XMP part. Changing it only in the information dictionary
violates a requirement for PDF/A.
The person who is the author, or production editor, *does* know
this information (at least in principle) and should ensure that
this gets encoded properly within the final PDF
Yes, there are users that detect that the intended producer entry
is *NOT* the one that gets written in the final PDF and writing
bug reports.
--- if complete
validation against an existing standard is of any importance.
Violation against PDF/A, for instance.
Please fix this issue in xdvipdfmx.
I'm not sure that it is xdvipdfmx's duty to handle this
issue; though see my final words below.
My initial thoughts are as follows:
The nature and purpose of XMP is such that an author
cannot just \usepackage{hyperxmp} with no extra options,
and expect the XMP information to be created automagically,
correctly in every detail.
There is no reason that the trivial stuff (pdf information
entries) should not be working.
The alternative is to have an auxiliary file that contains
macro definitions, to be used both in the docinfo and XMP.
This auxiliary file needs to be created either manually,
or automatically extracting the information from a PDF,
first time it is created.
I don't see any reliable way.
Even if you say good bye to TeX and do the stuff by
a program that fixes the PDF file afterwords, there
is no warning or hint that the PDF file generated
by XeTeX is wrong.
You can't expect from a user that he knows how to get
the version information of xdvipdfmx. He calls XeTeX
and usually does not even know that he is indirectly
running xdvipdfmx. Also the producer strings change
from driver to driver and from version to version.
Also several instances of a driver can be installed:
There is no way to catch the difference between
xetex -output-driver=xdvipmdfx078
and
xetex -output-driver=xdvipdfmx100
at TeX macro level.
With PDF/A and PDF/UA the PDF file is not supposed to be
compressed,
s/PDF file/PDF information dictionary/;
With XeTeX you need a command line like:
xetex -outputdriver='xdvipdfmx -V4'
With pdfTeX/LuaTeX the necessary settings can be done at
macro level and therefore put in a package without bothering
the user with low level stuff.
BTW, what about the /CreationDate and /ModificationDate ?
Surely these should be set automatically too ?
pdfTeX:
/CreationDate and /ModDate are set automatically
unless they are specified by the user.
(x)dvipdfmx:
/CreationDate is set automatically, /ModDate is not set
unless they are specified by the user (see test file).
The same would be nice for /Producer, easy to implement
and document.
Doesn't pdfTeX have the means to do this?
Works fine. Without setting the date of the pdfTeX run
is used for /CreationDate and /ModDate
Re: [XeTeX] Producer entry in info dict
On Wed, Feb 29, 2012 at 12:24:11AM +0100, Zdenek Wagner wrote: 2012/2/28 Ross Moore ross.mo...@mq.edu.au: On 29/02/2012, at 8:44 AM, Heiko Oberdiek wrote: ... BTW, what about the /CreationDate and /ModificationDate ? Surely these should be set automatically too ? Doesn't pdfTeX have the means to do this? Both /CreationDate and /ModDate can be added by macros and both are required by PDF/X. PdfTeX adds both automatically including the time zone. Dvips adds none, thus my zwpagelayout package adds them if dvips is used. TeX does not supply at a macro level the time zone, so that the time zone is not used. Xdvipdfmx sets /CreationDate only and zwpagelayout sets /ModDate. The problem is that /CreationDate set by xdvipdfmx contains time zone while /ModDate set by the macros does not. Time information without a time zone is considered UTC. Depending on the user's time zone upon PDF/X validation it may be reported that the file was modified before it was created. This kind of trouble is the reason for pdfTeX's \pdfcreationdate. It expands to the string that pdfTeX uses in the info dictionary including the time zone. It can also be used in DVI mode. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] (x)dvipdfm(x): Link rectangle problem
Hello,
the (x)dvipdfm(x) drivers fail if the link area contains
rules or images. See the following test file (can be used
with iniTeX):
\catcode`\{=1
\catcode`\}=2
\font\rm=cmr10
\rm
\count0=1
\shipout\hbox{%
\hbox to 0pt{%
\vrule width .1pt height 10mm\relax
\vrule width 10mm height .1mm\relax
\hss
}%
\special{pdf:bann%
/Type/Annot
/Subtype/Link
/A/S/Named/N/NextPage
}%
\vrule width 0mm height 10mm\relax
\kern 10mm\relax
\special{pdf:eann}%
}
\count0=2
\shipout\hbox{%
\hbox to 0pt{%
\vrule width .1pt height 10mm\relax
\vrule width 10mm height .1pt\relax
\hss
}%
\special{pdf:bann%
/Type/Annot
/Subtype/Link
/A/S/Named/N/PrevPage
}%
a%
\vrule width 0mm height 10mm\relax
\kern 10mm\relax
b%
\special{pdf:eann}%
}
\count0=3
\shipout\hbox{%
\hbox to 0pt{%
\vrule width .1pt height 10mm\relax
\vrule width 10mm height .1pt\relax
\hss
}%
\special{pdf:bann%
/Type/Annot
/Subtype/Link
/A/S/Named/N/PrevPage
}%
\ifx\XeTeXpicfile\undefined
\special{pdf:image width 10mm height 10mm (s1.png)}%
\else
\XeTeXpicfile s1.png width 10mm height 10mm\relax
\fi
\special{pdf:eann}%
}
\csname @@end\endcsname\end
Instead of s1.png an existing image file should be used.
The test file test.tex is called, e.g.:
xetex --ini --etex test
tex --ini test dvipdfmx test
The problems:
* Page 1: no link
* Page 2: the link area only covers the rectangle with a and b.
The rule in between is higher than b.
* Page 3: xdvipmx only makes a tiny link spot at the left lower corner,
no link with dvipdfmx.
BTW, setting the width of the invisible rules from 0pt to 1mm
does not make a difference.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Multiple column colors
On Mon, Feb 20, 2012 at 04:08:01PM +0100, Martin Schröder wrote: 2012/2/20 Stephan step...@theched.org: For example, this code (http://pastebin.com/U7B4mjic) works well under pdfLatex (one column turns out blue, the other red), while in XeLaTeX, the colors are mixed AFAIK pdfparcolumns works only with pdfTeX. Because pdfTeX supports multiple color stacks. Also LuaTeX should work with package `luacolor', because LuaTeX supports attributes. XeTeX and other (dvips, ...) offer neither multiple color stacks nor attributs. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX does not define the \XeTeX macro.
On Wed, Dec 21, 2011 at 12:25:08PM +, Philip TAYLOR wrote:
Ulrike Fischer wrote:
My name is Ulrike.
Mea culpa, mea culpa, mea maxima culpa.
Sincere apologies, Ulrike.
I saw that you wanted to use plain. But you didn't ask how to get
the logo with plain but Where is \XeTeX canonically defined. I
assumed as a plain user you would be able to look in the codes and
copy a suitable definition.
Well, yes, of course I could. But I assumed (perhaps naively)
that just as e-TeX had provided the e-TeX logo in a file that
was compatible with Plain e-TeX, XeTeX would have done the same.
I do appreciate that I am now one of an endangered minority of
Plain users, but XeTeX is an /engine/, not a format, and it
seems crazy to me to provide a definition of its logo in style
files that are compatible only with LaTeX. Your demonstration
that Hologo.sty /can/ be used with Plain XeTeX is helpful, but
of course I am put off by the fact that it warns me that it cannot
find a free read register.
Unless you are using iniTeX it's probably a bug. In the latest
version I can't reproduce it, however the latest version isn't
yet on CTAN. I send it off-list to you, thus you can even
use it with iniTeX (xetex --ini):
\catcode`\{=1
\catcode`\}=2
% ... and other settings (\hsize, ...)
% Since 2011/12/21 v1.9
\input hologo.sty
\font\rm=cmr10
\rm
\hologo{XeTeX}
\font\lm=[lmroman10-regular]
\lm
\hologo{XeTeX}
...
The logo uses U+018E if the font has this glyph otherwise
the reversed E is constructed.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX does not define the \XeTeX macro.
On Wed, Dec 21, 2011 at 04:37:08PM +0100, Ulrike Fischer wrote: Am Wed, 21 Dec 2011 15:26:16 +0100 schrieb Heiko Oberdiek: but of course I am put off by the fact that it warns me that it cannot find a free read register. Unless you are using iniTeX it's probably a bug. I get the warning with tex + xetex but not with pdftex and xelatex. But it doesn't seem to affect the output. Package hologo Warning: Configuration file ignored, because (hologo)a free read register could not be found. The package loads a configuration file if it exists. Easy file existence tests are provided by LaTeX (\IfFileExists) and pdfTeX (e.g., \pdffilesize). Otherwise it becomes complicate, because I don't want to waste a read register for this. The new version fixes the bugs in the latter part. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] tabular in footnote
On Wed, Dec 07, 2011 at 06:30:39AM +0800, Daniel Greenhoe wrote:
On Wed, Dec 7, 2011 at 5:46 AM, Heiko Oberdiek
heiko.oberd...@googlemail.com wrote:
You have to compile twice at least.
I compiled at least 8 times using xelatex Heiko.tex. I still get the
same error: the text extends below the text area (see attachment). You
don't get this result on your system?
And I had written:
| The following example addresses calculates the shift to align
| the baseline of the footnote line with the first line of
| the tabular. No time for looking at the problem with the overfull \vbox.
I have seen two problems with your example and one of them solved,
the other remained unsolved. No more, no less.
Taking more time, I see now, that the overfull \vbox is caused
by something different: The header is set to zero (see options
for geometry), but the page number is printed causing the
overfull \vbox. Changing the options of geometry or \pagestyle{empty}
solves the problem.
The exceeding part of the second footnote text is correct behaviour:
TeX tries to align the top and bottom lines of a page in order to
get the baselines at the same position:
* At the top vertical space is added up to \topskip unless
the height of the first element is larger than \topskip.
* At the bottom the bottom element might have a depth up to
\maxdepth. The default for \maxdepth with \documentclass[12pt]{book}
is .5\topskip = 8pt. \maxdepth=0pt doesn't allow the bottom element
to exceed the textarea. Aligning the last line of the tabular with the
bottom of the textarea is much more tricky.
The following assumes that the last line of the tabular contains
normal text without large depths:
\documentclass[12pt]{book}
\usepackage{array}
\usepackage[
a4paper,noheadfoot,nomarginpar,margin=20mm,showframe
]{geometry}
\usepackage{zref-savepos}
\pagestyle{empty}
%\maxdepth=0pt
\makeatletter
\newsavebox\tl@box
\newcount\c@tlcount
\setcounter{tlcount}{0}
\def\thetlcount{\the\c@tlcount}
\newenvironment*{tltabular}[1]{%
\stepcounter{tlcount}%
\begin{lrbox}{\tl@box}%
\begin{tabular}[t]{|#1|}%
\hline
\zref@savepos
\zref@labelbyprops{tl@b\thetlcount}{posy}%
\xdef\g@dp@arstrutbox{%
\the\dimexpr\dp\@arstrutbox+\arrayrulewidth
}%
\ignorespaces
}{%
\hline
\end{tabular}%
\end{lrbox}%
\zref@refused{tl@a\thetlcount}%
\zref@refused{tl@b\thetlcount}%
\dimen@=\dimexpr
\zposy{tl@a\thetlcount}sp-\zposy{tl@b\thetlcount}sp%
\relax
\raisebox{\dimen@}{%
\zref@savepos
\zref@labelbyprops{tl@a\thetlcount}{posy}%
\box\tl@box
}\\*[-\g@dp@arstrutbox]%
\hbox{\vrule width 0pt depth\g@dp@arstrutbox}%
}
\begin{document}%
xyz\footnote{%
\begin{tltabular}{l}
abc\\
def\\
ghj\\
klm\\
\end{tltabular}%\\
}
xyz\footnote{%
\begin{tltabular}{l}
abc\\
def\\
ghj\\
klm\\
\end{tltabular}%\\
}
\end{document}%
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] tabular in footnote
On Sun, Dec 04, 2011 at 07:31:59AM +0800, Daniel Greenhoe wrote:
When I put a tabular in a footnote, the tabular often is extended
outside the text area. Besides placing a newline directive after the
tabular environment, is there anything I can do to prevent this
behavior? That is, how can I best ensure that tabulars in a footnote
get typeset completely within the text area? Here is an example:
\documentclass[12pt]{book}
\usepackage[xetex,a4paper,noheadfoot,nomarginpar,margin=20mm,showframe]{geometry}
\begin{document}%
xyz\footnote{%
%\raisebox{2.5mm}{
\begin{tabular}[t]{|l|}
\hline
abc\\
def\\
ghj\\
klm\\
\hline
\end{tabular}%\\
%}%
}
xyz\footnote{%
%\raisebox{2.5mm}{
\begin{tabular}[t]{|l|}
\hline
abc\\
def\\
ghj\\
klm\\
\hline
\end{tabular}%\\
%}%
}
\end{document}%
I don't see a relation to XeTeX, thus the mailing list texhash
might be the better choice for this question.
The following example addresses calculates the shift to align
the baseline of the footnote line with the first line of
the tabular. No time for looking at the problem with the overfull \vbox.
\documentclass[12pt]{book}
\usepackage{array}
\usepackage[
a4paper,noheadfoot,nomarginpar,margin=20mm,showframe
]{geometry}
\usepackage{zref-savepos}
\makeatletter
\newsavebox\tl@box
\newcount\c@tlcount
\setcounter{tlcount}{0}
\def\thetlcount{\the\c@tlcount}
\newenvironment*{tltabular}[1]{%
\stepcounter{tlcount}%
\begin{lrbox}{\tl@box}%
\begin{tabular}[t]{|#1|}%
\hline
\zref@savepos
\zref@labelbyprops{tl@b\thetlcount}{posy}%
\ignorespaces
}{%
\hline
\end{tabular}%
\end{lrbox}%
\zref@refused{tl@a\thetlcount}%
\zref@refused{tl@b\thetlcount}%
\dimen@=\dimexpr
\zposy{tl@a\thetlcount}sp-\zposy{tl@b\thetlcount}sp%
\relax
\raisebox{\dimen@}{%
\zref@savepos
\zref@labelbyprops{tl@a\thetlcount}{posy}%
\box\tl@box
}%
}
\begin{document}%
xyz\footnote{%
\begin{tltabular}{l}
abc\\
def\\
ghj\\
klm\\
\end{tltabular}%\\
}
xyz\footnote{%
\begin{tltabular}{l}
abc\\
def\\
ghj\\
klm\\
\end{tltabular}%\\
}
\end{document}%
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 11:49:30AM +, Philip TAYLOR wrote: Typesetting a restaurant menu, I have run into two problems : one I can work around, one is completely defeating me. Here is the relevant fragment of code -- \XeTeXpicfile Resources/Images/IMG_2206.JPG width \hsize \relax \XeTeXpicfile Resources/Images/TAR-2.pdf width \hsize \relax \vfil \eject Problem 1 (work-aroundable) : the \vfill \eject has no effect, and the image appears above the \halign that follows. D.E. Knuth, The TeXbook: Chapter 15: How TeX Makes Lines into Pages: | Whenever TeX is moving an item from the top of the recent | contributions to the bottom of the current page, it discards | a discardable item (glue, kern, or penalty) if the current | page does not contain any boxes. Solution, for example: put \XeTeXpicfile ... in an \hbox. Problem 2 (completely intractable) : XeTeX claims to be unable to find TAR-2.pdf, Already answered (\XeTeXpdffile). Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 02:25:43PM +, Philip TAYLOR wrote: Sorry, please read that as \XeTeXpdffile -- not tested with \XeTeXpicfile, which I will now do. Philip TAYLOR wrote: The behaviour is even stranger than I thought. Used unadorned, \XeTeXpicfile introduces a significant right shift for all text that follows it on the current page; concealed within a \centerline, all is well yet concealed within braces the artifact remains (so it is not a scoping issue). Make a minimal example that shows the problem. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 03:03:32PM +, Philip TAYLOR wrote: Heiko Oberdiek wrote: D.E. Knuth, The TeXbook: Chapter 15: How TeX Makes Lines into Pages: | Whenever TeX is moving an item from the top of the recent | contributions to the bottom of the current page, it discards | a discardable item (glue, kern, or penalty) if the current | page does not contain any boxes. Jonathan Kew, Will Robertson, or any other XeTeX documenter : XeTeXpicfile is a discardable item ??? No, it's a whatsit. It is *not* discarded, but it isn't a box. Problem 2 (completely intractable) : XeTeX claims to be unable to find TAR-2.pdf, Already answered (\XeTeXpdffile). I repeat : Why does \XeTeXpicfile say '! Unable to load picture or PDF file', if it is unable to handle PDF files ? Then it cannot load PDF files and the error message is correct. Make a minimal example that shows the problem. To follow : I have to remove cropmarks and various other things essential to the real work. Then my guess is that the problem is caused by the removal code for the crop marks and the various other things. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 03:58:10PM +0100, Zdenek Wagner wrote: 2011/12/1 Heiko Oberdiek heiko.oberd...@googlemail.com: On Thu, Dec 01, 2011 at 11:49:30AM +, Philip TAYLOR wrote: Typesetting a restaurant menu, I have run into two problems : one I can work around, one is completely defeating me. Here is the relevant fragment of code -- \XeTeXpicfile Resources/Images/IMG_2206.JPG width \hsize \relax \XeTeXpicfile Resources/Images/TAR-2.pdf width \hsize \relax \vfil \eject Problem 1 (work-aroundable) : the \vfill \eject has no effect, and the image appears above the \halign that follows. D.E. Knuth, The TeXbook: Chapter 15: How TeX Makes Lines into Pages: | Whenever TeX is moving an item from the top of the recent | contributions to the bottom of the current page, it discards | a discardable item (glue, kern, or penalty) if the current | page does not contain any boxes. Solution, for example: put \XeTeXpicfile ... in an \hbox. That's what I wrote about discardable items but it does not explain why \XeTeXpicfile is discarded. It is not discarded. Only the glue and penalty of \vfil\eject. The picture is still there. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 04:47:30PM +, Philip TAYLOR wrote:
Heiko Oberdiek wrote:
It's your choice to use low level internals. Higher level interfaces
are already written and some can also be used with plain TeX:
...
\input graphicx.sty
...
\includegraphics[width=\hsize]{s1.png}
...
Thus there is no need to know the difference between the low level
commands \XeTeXpicfile and \XeTeXpdffile for the end user.
I choose to write in TeX
because I understand TeX, I like TeX, and I very much appreciate
the control that TeX gives me. But when TeX (or, in this case,
XeTeX) causes problems, and will continue to cause problems for
others in the future, then I believe that it is important to
discuss (and, hopefully, resolve) those problems rather than
simply sweeping them under the counter by saying Why not use
existing packages ?.
Because they are solving those problems for you and others now
and in the future. That is one of the main reasons for a package,
providing an easier interface for tricky low level stuff.
I do not use existing packages because
I prefer not to, just as I prefer to drive a manual car rather
than an automatic : I want to be /in control/ of the typesetting,
That comes with the price that you have to deal with the
tricky low level stuff. And as we have seen, old TeX
is even able to surprise much experienced Gurus.
not dependent on someone else's work (DEK/JK excepted).
You are forgetting the e-TeX people (Peter Breitenlohner et. al.),
xdvipdfmx (Jin-Hwan Cho et. al.), the predecessor dvipdfm(x)
(Mark A. Wicks et. al.), the font people, the people that make
the TeX distribution, ...
Back to the problems:
* non-effective \vfill\eject: documented in The TeXbook:
| Whenever TeX is moving an item from the top of the
| recent contributions to the bottom of the current page,
| it discards a discardable item (glue, kern, or penalty)
| if the current page does not contain any boxes.
Remark: This should be fixed:
any boxes. - any boxes or rules.
* \XeTeXpicfile cannot load PDF files: documentd in
The XeTeX reference guide by Will Robertson:
| 6 Graphics
| ...
| \XeTeXpicfile ...
| Insert an image. ...
|
| \XeTeXpdffile ...
| Insert (pages of) a PDF. ...
Remark: It could be improved by saying
* that both commands insert a whatsit and
* that they should be used inside a \hbox to avoid trouble
with discarded items at the top of a page.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 05:38:04PM +0100, Zdenek Wagner wrote:
2011/12/1 Heiko Oberdiek heiko.oberd...@googlemail.com:
On Thu, Dec 01, 2011 at 04:51:14PM +0100, Zdenek Wagner wrote:
2011/12/1 Philip TAYLOR p.tay...@rhul.ac.uk:
Heiko Oberdiek wrote:
No, it's a whatsit. It is *not* discarded, but it isn't a box.
Right, so why isn't the \eject honoured ?
If I remember it well, whatsit is dimensionless, thus if \XeTeXpicfile
reserves a space, it cannot be just whatsit. Anyway, discardable items
are discarded at the break. They must not be discarded after whatsit.
Knuth has decided otherwise. Discardable items are discarded at
top of a new page unless there is a box. I have already quoted
The TeXbook.
Not exactly, it is important that whatsit is not a discardable item.
If if occurs at the top of the page, all following discardable items
should be included in the page.
Donald E. Knuth is the address to complain.
I have not tried your example but I
think it \vfil\eject will be ignored. There is no \immediate,
Yes this is important, with \immediate the \write would be executed
immediately and vanish. Without \immediate the delayed \write is
stored in a node at the top of the page.
thus
\write will be stored and executed on \shipout. \vfil\eject are still
on the top of the page,
No, the first element is a whatsit (\write).
\vfil is discardable and will be discarded,
Yes, because there isn't a box before.
\eject will do nothing because there is no page to be ejected.
The \penalty of \eject that forces the page break is discarded, too.
\showboxdepth1
\showboxbreadth1
\tracingonline=1
\scrollmode
\parindent=0pt
\kern1pt
\penalty2
\write16{Hello World}
\special{foobar}
\kern3pt
\penalty4
\showlists
\vfil\eject
ABC
\bye
Result of \showlists:
### vertical mode entered at line 0
### current page:
\write*{Hello World}
\special{foobar}
prevdepth ignored
! OK.
l.14 \showlists
A box or rule (!) is needed to stop discarding discardable items.
(The rule is not meantioned in the already quoted sentence from
The TeXbook).
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX, XeTeXpicfile, and counter-intuitive behaviour
On Thu, Dec 01, 2011 at 06:06:13PM +, Philip TAYLOR wrote:
Heiko Oberdiek wrote:
Because they are solving those problems for you and others now
and in the future. That is one of the main reasons for a package,
providing an easier interface for tricky low level stuff.
I don't /want/ an easier interface, Heiko : I /hate/ LaTeX,
Then use a ConTeXt module or whatever.
And the syntax of graphicx' \includegraphics:
\includegraphics[key value list]{image file}
is not very special that this can only be used in LaTeX.
with its Nanny knows best mentality, and I want to /understand/
the tricky low level stuff because it is (a) the most interesting,
(b) the most powerful, and (c) because there is nothing between
me and it to stop me from making it do exactly what I want.
Then, please, don't surprise me, that you are suprised that TeX
has surprised you. ;-)
Back to the problems:
* non-effective \vfill\eject: documented in The TeXbook:
| Whenever TeX is moving an item from the top of the
| recent contributions to the bottom of the current page,
| it discards a discardable item (glue, kern, or penalty)
| if the current page does not contain any boxes.
Remark: This should be fixed:
any boxes. - any boxes or rules.
The problem is, there is still (as far as I can see) no formal
definition of what sort of thing \XeTeXp{df|ic}file inserts.
If there were such a definition, tracking down such bugs would
be very much simpler.
Yes, I don't know a complete, comprehensive documentation of XeTeX.
I am aware of:
* Mark A. Wicks: Dvipdfm User's Manual (dvipdfm.pdf)
* Jin-Hwan Cho: DVI specials for PDF generation;
TUGboat, Volume 30 (2009), No. 1 (dvipdfmx-special.pdf)
* Will Robertson: The XeTeX reference guide (XeTeX-reference.pdf)
* \XeTeXpicfile cannot load PDF files: documentd in
The XeTeX reference guide by Will Robertson:
| 6 Graphics
| ...
| \XeTeXpicfile ...
| Insert an image. ...
|
| \XeTeXpdffile ...
| Insert (pages of) a PDF. ...
Remark: It could be improved by saying
* that both commands insert a whatsit and
* that they should be used inside a \hbox to avoid trouble
with discarded items at the top of a page.
That would indeed be a great help.
Can you rephrase this in understandable words
and in excellent English of course :-)
and send the result to Will that he can update
the reference guide?
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color
On Wed, Nov 30, 2011 at 05:10:07AM +0200, Khaled Hosny wrote:
A\textcolor{red}{0308}\\ % (3)
It seems Charis SIL composes accented glyphs, try Gentium Basic instead
(GenBasR.ttf).
Thanks, the result is correct, the box contents after luacolor's
processing is:
\EU2/GentiumBasic(0)/m/n/100 A
\pdfliteral direct1 0 0 rg 1 0 0 RG
\EU2/GentiumBasic(0)/m/n/100 Ì
The part in the PDF with/without color:
% without color:
1 0 0 1 72 590.679 Tm [0024]TJ
1 0 0 1 126.191 606.246 Tm [0301]TJ
% with color:
1 0 0 1 72 491.053 Tm [0024]TJ
1 0 0 rg 1 0 0 RG
1 0 0 1 126.191 506.619 Tm [0301]TJ
In case of XeTeX:
.\EU1/GentiumBasic(0)/m/n/100 A
.\special{color push rgb 1 0 0}
.\EU1/GentiumBasic(0)/m/n/100 Ì210
.\special{color pop}
The PDF stuff:
% without color:
0 -99.63 Td[0024]TJ
54.19 15.57 Td[0301]TJ
% with color:
-54.19 -115.2 Td[0024]TJ
ET 1 0 0 RG 1 0 0 rg BT /F1 99.626 Tf
59.3 -278.84 Td[0301]TJ
% with color via \special{pdf:code ...}:
0 -378.46 Td[0024]TJ
ET 1 0 0 rg 1 0 0 RG BT /F1 99.626 Tf
59.3 -378.46 Td[0301]TJ
It seems that in XeTeX the color cannot be inserted without
breaking the PDF text sections (BT...ET). \special{pdf:literal direct ...}
(or short \special{pdf:code ...}) is not equivalent to
\pdfliteral direct{...} but rather to \pdfliteral page{...}
that ends a text section in the PDF output.
If someone want's this issue fixed, make a feature request
for XeTeX/xdvipdfmx to provide a real \pdfliteral direct/
direct mode for colors without breaking text sections.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Detect, whether a font contains a certain character
On Tue, Nov 29, 2011 at 07:40:13AM +, Jonathan Kew wrote:
On 28 Nov 2011, at 08:06, Heiko Oberdiek wrote:
\catcode`\{=1
\catcode`\}=2
\catcode`\^=7
\showboxdepth=1
\showboxbreadth=1
\tracingonline=1
\font\rm=cmr10\relax
\rm
\setbox0=\hbox{\kern1pt018e}
\showbox0
\csname @@end\endcsname\end
And where is the inserted .notdef glyph?
There won't be one with cmr10: that's a TFM font, so missing chars get
dropped, just like in standard TeX. But if \rm is a native truetype/opentype
font, it'll be there:
\catcode`\{=1
\catcode`\}=2
\catcode`\^=7
\showboxdepth=1
\showboxbreadth=1
\scrollmode
\tracingonline=1
\font\rm=Trebuchet MS
\rm
\setbox0=\hbox{\kern1pt018e}
\showbox0
\showthe\wd0
\end
--
This is XeTeX, Version 3.1415926-2.3-0.9997.5 (TeX Live 2011)
restricted \write18 enabled.
entering extended mode
(./x.tex
Missing character: There is no ?? in font Trebuchet MS!
\box0=
\hbox(5.45789+0.0)x6.0
.\kern 1.0
.\rm ??
! OK.
l.11 \showbox0
6.0pt.
l.12 \showthe\wd0
)
Which tells us that the width of .notdef in Trebuchet MS is 5pt, but tells
us nothing (from within the document - the Missing character message
tells us externally, of course) about the presence or absence of U+018E in
this font.
Thanks for clarifying.
I try to summarize, state of the art for testing the existence
of a glyph is the following algorithm, implemented in the
macro \IfXeTeXTextCharExists. I have added a local
\tracinglostchars=0 to get rid of the warning in the .log file.
\catcode`\{=1
\catcode`\}=2
\catcode`\#=6
\catcode`\^=7
\showboxdepth=1
\showboxbreadth=1
\scrollmode
\tracingonline=1
%%% Begin %%%
\def\IfXeTeXTextCharExists#1{%
\begingroup
\long\def\next##1##2{##2}%
% or in LaTeX: \let\next\@secondoftwo
\ifnum\XeTeXfonttype\font0 %
\ifnum\XeTeXcharglyph`#10 %
\long\def\next##1##2{##1}%
% or in LaTeX: \let\next\@firstoftwo
\fi
\else
\setbox0=\hbox{%
\tracinglostchars=0 %
\kern1sp#1%
\expandafter
}%
\ifnum\lastkern=1 %
\else
\long\def\next##1##2{##1}%
% or in LaTeX: \let\next\@firstoftwo
\fi
\fi
\expandafter\endgroup
\next
}
%%% End %%%
\def\Test#1#2{%
\begingroup
\font\test=#1\relax
\test
\IfXeTeXTextCharExists{#2}{%
\immediate\write16{YES (\detokenize{#1/#2})}%
}{%
\immediate\write16{NO (\detokenize{#1/#2})}%
}%
\endgroup
}
\Test{Trebuchet MS}{A}
\Test{cmr10}{A}
\Test{Trebuchet MS}{018e}
\Test{cmr10}{018e}
\end
the problem is rather that a existing glyph can have width zero
(not likely in your case)
The algorithm doesn't look for the width, that avoids that problem.
and that there is a warning in the .log file.
Solved by a local setting of \tracinglostchars=0.
Or what do you suggest for a general test of glyph existence?
For native Unicode fonts, as I said, use \XeTeXcharglyph.
I agree, see above.
For TFM fonts, I
don't think the question is particularly interesting or worthwhile.
TFM fonts do not have a standard encoding, so querying them for a
particular character code is meaningless - you have to know the encoding
of the font you're using in order to do anything useful with it, in which
case you should already know what characters it supports.
If TFM fonts are used, then the encoding and character code has to
be known. But that does not answer the question whether the character
is available in the font. There are incomplete fonts, see the
subencodings of TS1.
Testing this revealed another general glyph test problem: A font might
not support a glyph, but provide a funny replacement instead,
thus at TeX level this cannot be detected, because the glyph exists.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color
Hi Ross,
On Wed, Nov 30, 2011 at 06:23:54AM +1100, Ross Moore wrote:
Hi Heiko,
On 29/11/2011, at 9:29 AM, Heiko Oberdiek wrote:
The same also works in XeLaTeX:
\documentclass{minimal}
\usepackage{fontspec}
\usepackage{color}
\pagestyle{empty}
\begin{document}
\fontsize{100pt}{100pt}\selectfont
\noindent
00e4\\
a0308\\
a\textcolor{red}{0308}
\end{document}
stream
q 1 0 0 1 72 769.89 cm 0 G 0 g 0 G 0 g 0 G 0 g BT /F1 99.626 Tf 0 -63.86
Td[00a0]TJ 0 -99.63 Td[001c00ee]TJ 0 -99.62 Td[001c]TJ ET 1 0 0 RG 1
0 0 rg BT /F1 99.626 Tf 45.73 -263.11 Td[00ee]TJ ET 0 G 0 g 0 G 0 g 0 G
0 g Q
endstream
Yes, this is OK with lower-case letters.
But try with uppers:
\begin{document}
\fontsize{100pt}{100pt}\selectfont
\noindent
00e4\\
a0308\\
a\textcolor{red}{0308}\a
U\textcolor{red}{0308}\U
\end{document}
or
00c4\\
A0308\\
A\textcolor{red}{0308}
As you can see, this problem is not related to color,
both XeTeX and LuaTeX fail:
Both the vertical and horizontal position are now wrong.
The Unicode input neither seems to be normalized in XeTeX or LuaTeX
nor the accent seems to know its base letter. Manual fixing
of the accent position remains as (only?) option.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color
On Wed, Nov 30, 2011 at 10:58:23AM +1100, Ross Moore wrote:
On 30/11/2011, at 10:32 AM, Heiko Oberdiek wrote:
or
00c4\\
A0308\\
A\textcolor{red}{0308}
As you can see, this problem is not related to color,
both XeTeX and LuaTeX fail:
With this font (Latin Modern) yes. I noticed this too.
But try switching the font:
\documentclass{minimal}
\usepackage{fontspec}
\usepackage{color}
\pagestyle{empty}
\setmainfont{Charis SIL}
\begin{document}
\fontsize{100pt}{100pt}\selectfont
\noindent
00e4\\
a0308\\
a\textcolor{red}{0308}\a
\hbox{U0308} U\textcolor{red}{0308}\U
00c4\\
A0308\\
A\textcolor{red}{0308}
\end{document}
Now it *does* depend upon having the color commands.
\documentclass{minimal}
\usepackage{ifluatex}
\usepackage{fontspec}
\ifluatex
\usepackage{luacolor}
\pdfobjcompresslevel=0
\pdfcompresslevel=0
\else
\usepackage{color}
\fi
\pagestyle{empty}
\setmainfont{CharisSIL-R.ttf}
\begin{document}
\fontsize{100pt}{100pt}\selectfont
\noindent
00c4\\ % (1)
A0308\\ % (2)
A\textcolor{red}{0308}\\ % (3)
A\textcolor{red}{\hbox{0308}} % (4)
\end{document}
* LuaTeX: A + U+0308 gets combined to one glyph U+00C4, the
color attribute of the diaeresis vanishes and the result is
black (3). In the last line (4) \hbox prevents the recombination
and the diaeresis is red, but misplaced.
* XeTeX: The color special prevents the glyph recombination and
U+0308 is processed separately without knowing the base character
(3 and 4).
Thus the workaround would be to prevent the recombination and
to fix the placement manually.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Detect, whether a font contains a certain character
On Mon, Nov 28, 2011 at 07:19:48AM +, Jonathan Kew wrote:
On 28 Nov 2011, at 06:59, Heiko Oberdiek wrote:
On Mon, Nov 28, 2011 at 03:07:07PM +1030, Andrew Moschou wrote:
2011/11/28 Zdenek Wagner zdenek.wag...@gmail.com
Put it into an \hbox and measure its width (\wd). If the width is
zero, the glyph does not exist.
If the required glyph doesn't exist, wouldn't this measure the .notdef
glyph?
No,
Yes, it would (and .notdef may of course have non-zero width).
\catcode`\{=1
\catcode`\}=2
\catcode`\^=7
\showboxdepth=1
\showboxbreadth=1
\tracingonline=1
\font\rm=cmr10\relax
\rm
\setbox0=\hbox{\kern1pt018e}
\showbox0
\csname @@end\endcsname\end
And where is the inserted .notdef glyph?
the problem is rather that a existing glyph can have width zero
(not likely in your case) and that there is a warning in the .log file.
See my examples.
Assuming the OP is interested in native truetype/opentype fonts, not
.tfm-based fonts, \XeTeXcharglyph is the simple answer.
In case of \ifnum\XeTeXfonttype0 there is a better test.
Or what do you suggest for a general test of glyph existence?
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Diacritics in color (was Re: XETEX cannot access OpenType features in PUA?)
On Mon, Nov 28, 2011 at 02:18:56PM -0500, Aleksandr Andreev wrote:
Jonathan Kew writes:
Making this work in xetex would require a different approach to
implementing color.
I have been able to get it to work (the base glyph in black and the
diacritic in red) in LuaTeX using the luacolor package.
Here's a minimal example:
\documentclass{minimal}
\usepackage{fontspec}
\usepackage{xcolor}
\usepackage{luacolor}
\newfontface\moo{MezenetsUnicode}
\begin{document}
\moo
\textcolor{red}{}
\end{document}
I'm not much of an expert in the inner workings of TeX and I know
absolutely nothing about Lua (is that a derivative of LISP?) so I
can't comment on whether the luacolor package could be ported to
XeTeX.
No. Package luacolor uses LuaTeX's attributes and LuaTeX's ability
to process node lists.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Detect, whether a font contains a certain character
On Sun, Nov 27, 2011 at 11:35:29PM +0100, Zdenek Wagner wrote:
2011/11/27 Tobias Schoel liesdieda...@googlemail.com:
Hi,
I know, this question has been raised several times on this list. But I'm
bad at searching, so I'm just asking:
How can I detect, whether a font contains a certain character (let's say
u2103=Degree Celsius symbol) from within XeTeX?
Put it into an \hbox and measure its width (\wd). If the width is
zero, the glyph does not exist.
There are chars with zero width, e.g. \not (in math mode).
Partially the test can be done (e.g. for 018E) by:
\ifnum\XeTeXfonttype\font0
\ifnum\XeTeXcharglyph018E0
% == char exists
\fi
\fi
For the other cases, the \hbox method can be combined with \lastkern,
for example:
\begingroup
\setbox0=\hbox{\kern1sp018e\expandafter}%
\expandafter\endgroup
\ifdim\lastkern=1sp
\immediate\write16{glyph does not exist}%
\else
\immediate\write16{glyph does exist}%
\fi
\csname @@end\endcsname\end
Disadvantage: There is a warning in the .log file for missing glyphs:
| Missing character: There is no ... in font cmr10!
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Detect, whether a font contains a certain character
On Mon, Nov 28, 2011 at 03:07:07PM +1030, Andrew Moschou wrote: 2011/11/28 Zdenek Wagner zdenek.wag...@gmail.com Put it into an \hbox and measure its width (\wd). If the width is zero, the glyph does not exist. If the required glyph doesn't exist, wouldn't this measure the .notdef glyph? No, the problem is rather that a existing glyph can have width zero (not likely in your case) and that there is a warning in the .log file. See my examples. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] aligning characters at their centers
On Wed, Nov 16, 2011 at 11:28:33AM +0800, Daniel Greenhoe wrote:
Is there a way to align characters at their centers instead of at
their baselines?
Take for example
{\scshape Ee}.
This will produce one big uppercase E and one little uppercase E;
and their lower horizontal bars will be aligned. But is there any way
I can make them aligned at their centers (center horizontal bars
aligned) without using \raisebox?
\documentclass{article}
\begin{document}
\scshape
$\vcenter{\hbox{E}}\vcenter{\hbox{e}}$
or
\valign{\vfill\hbox{#}\vfill\cr E\cr e\cr}
\end{document}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Trouble with the new Xetex
On Sun, Nov 06, 2011 at 11:37:08AM +0100, Peter Dyballa wrote:
Am 06.11.2011 um 02:15 schrieb Andrew Gollan:
The Invalid glyph is
actually the result of a \=V in one place, but the \=y is being printed as
a spiral in the PDF if that is remove
V with macron does not exist in Unicode (but U with macron does, so it
looks bad, until you invent a good macro to position the macron on the V),
ȳ does not exist in Palatino Linotype.
And U+0304 COMBINING MACRON is missing.
But the missing glyphs can be constructed manually:
\DeclareTextCompositeCommand{\=}{EU1}{V}{%
\leavevmode
\begingroup
\sbox0{012a}%
\sbox2{02c9}%
\sbox4{V}%
\rlap{%
\hbox to \wd4{%
\hfill
\raisebox{\dimexpr\ht0-\ht2\relax}{02c9}%
\hfill
}%
}%
V%
\endgroup
}
\DeclareTextCompositeCommand{\=}{EU1}{y}{%
\leavevmode
\begingroup
\sbox0{016b}%
\sbox2{02c9}%
\sbox4{y}%
\rlap{%
\hbox to \wd4{%
\hfill
\raisebox{\dimexpr\ht0-\ht2\relax}{02c9}%
\hfill
}%
}%
y%
\endgroup
}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Anchor names
On Sat, Nov 05, 2011 at 02:45:32PM +, Jonathan Kew wrote:
On 5 Nov 2011, at 10:24, Akira Kakuto wrote:
Dear Heiko,
Conclusion:
* The encoding mess with 8-bit characters remain even with XeTeX.
I have disabled to reencode pdf strings to UTF-16 in xdvipdfmx: TL trunk
r24508.
Now
/Dc3a46e6368c3b872
and
/Names[c3a46e6368c3b8727 0 R]
Thanks Akira. But caution, it could break bookmark strings that
currently works more or less accidently, sometimes with warnings.
Perhaps the problem can be solved with a syntax extension, see below.
Unfortunately, I have not had time to follow this thread in detail or
investigate the issue properly, but I'm concerned this may break other
things that currently work, and rely on this conversion between the
encoding form in \specials, and the representation needed in PDF.
However, by way of background: xetex was never intended to be a tool for
reading and writing arbitrary binary files.
The PDF file format is a binary file format. To some degree us-ascii
can be used, but at the cost of flexibility and some restrictions.
It is a tool for processing
text, and is specifically based on Unicode as the encoding for text, with
UTF-8 being its default/preferred encoding form for Unicode, and (more
importantly) the ONLY encoding form that it uses to write output files.
It's possible to READ other encoding forms (UTF-16), or even other
codepages, and have them mapped to Unicode internally, but output is
always written as UTF-8.
Now, this should include not only .log file and \write output, but also
text embedded in the .xdv output using \special. Remember that \special
basically writes a sequence of *characters* to the output, and in xetex
those characters are *Unicode* characters. So my expectation would be that
arbitrary Unicode text can be written using \special, and will be
represented using UTF-8 in the argument of the xxxN operation in .xdv.
That means that arbitrary bytes can't be written using \special,
a restriction that is not available in vanilla TeX.
If
that \special is destined to be converted to a fragment of PDF data by the
xdv-to-pdf output driver (xdvipdfmx), and needs a different encoding form,
I'd expect the driver to be responsible for that conversion.
Suggestions for some of PDF's data structures:
* Strings: It seems that both (...) and the hex form ... can be
used. In the hex form spaces are ignored, thus a space right
after the opening angle could be used for a syntax extension.
In this case the driver unescapes the hex string to get the
byte string without reencoding to Unicode.
Example:
\special{pdf:dest c3a46e6368c3b872 [...]}
The destination name would be änchør as byte string in UTF-8.
\special{pdf:dest e46e6368f872 [...]}
The destination name would be änchør as byte string in latin1.
\special{pdf:dest c3a46e6368c3b872 [...]}
The destination name would be the result of the current
implementation.
* Streams (\special{pdf: object ..stream...endstream}):
Instead of the keyword stream hexstream could be introduced.
The driver then takes a hex string, unhexes it to get the byte
data for the stream, also without reencoding to Unicode.
What I would NOT expect to work is for a TeX macro package to generate
arbitrary binary data (byte streams) and expect these to be passed
unchanged to the output. I suspect that's what Heiko's macros probably do,
and it worked in pdftex where tex character == byte, but it's
problematic when tex character == Unicode character.
Yes, that's the problem. PDF is a binary format, not a Unicode text format.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Anchor names
On Sun, Nov 06, 2011 at 12:57:12AM +0900, Akira Kakuto wrote:
I have disabled to reencode pdf strings to UTF-16 in xdvipdfmx: TL
trunk r24508.
Now
/Dc3a46e6368c3b872
and
/Names[c3a46e6368c3b8727 0 R]
We can choose that both of the above are UTF16BE with BOM,
by reencoding both of them. Which do you think is beter?
The main problem is that arbitrary byte strings are needed.
Example with a reference to a destination in another file:
\catcode`\{=1
\catcode`\}=2
\pdfpagewidth=100bp
\pdfpageheight=200bp
\shipout\vbox{%
\kern-1in\relax
\hbox{%
\kern-1in\relax
\vrule width0pt height200bp depth0pt\relax
% Link annotation at (150bp,50bp)
\raise130bp\hbox to 0pt{%
\kern70bp %
\kern-2bp
\special{%
pdf:ann width 4bp height 2bp depth 2bp%
/Type/Annot%
/foo/ab#abc
/Subtype/Link%
/Border[0 0 1]%
/C[0 0 1]% blue border
/A%
/S/GoToR%%
/F(t.tex)%
/D66f6f8%
% Result: 66f6f8, but ** WARNING ** Failed to convert input
string toUTF16...
% /Dc3a46e6368c3b872%
% Result: feff00e4006e0063006800f80072
%
%
}%
\vrule width4bp height2bp depth2bp\relax
\hss
}%
}%
}
\end
It seems that *all* literal strings are affected by the
unhappy reconversions. But the PDF specification lets no choice,
there are various places for byte strings.
In the example, if a file name has byte string XY and the destination Z,
then the file name is XY and the file name Z and nothing else. Otherwise
neither the file or the destination will be found.
Thus either (XeTeX/)xdvipdfmx finds a way for specifying arbitrary
byte strings (at least for PDF strings(/streams)) -- it is a
requirement of the PDF specification. Or we have to conclude
that 8-bit is not supported and that means US-ASCII.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Synching PDF paper size with typesetting size
On Sat, Nov 05, 2011 at 02:06:43PM -0400, Karljurgen Feuerherm wrote:
Usually, I need to use US letter paper size--but for one document I'm
working on, I want B5. I'm using Memoir for this one, and have set B5
accordingly.
Memoir is already capable to tell the media size to XeTeX and
it does it automatically:
\newcommand*{\fixpdflayout}{%
\pdfpageheight=\the\stockheight
\pdfpagewidth=\the\stockwidth
\ifxetex\else
\ifdim\pdfvorigin=0pt\pdfvorigin=1in\fi
\ifdim\pdfhorigin=0pt\pdfhorigin=1in\fi
\fi}
\newcommand*{\fixdvipslayout}{%
\AtBeginDvi{\special{papersize=\the\stockwidth,\the\stockheight}}}
\AtBeginDocument{%
\ifxetex
\fixpdflayout
\else
\ifpdf
\ifnum\pdfoutput\@ne
\fixdvipslayout
\else
\fixpdflayout
\fi
\else
\fixdvipslayout
\fi
\fi}
Therefore you do *not* need:
* setting the media size manually using \pdfpagewidth and \pdfpageheight,
* using package geometry,
* command line options for XeTeX/xdvipdfmx.
A minimal example shows that memoir indeed sets the correct
paper size:
% File: test.tex
% Command line: xelatex test.tex
\listfiles
\documentclass[b5paper]{memoir}
\begin{document}
Hello World
\end{document}
*File List*
memoir.cls2011/03/06 v3.6j configurable book, report, article
document class
ifpdf.sty2011/01/30 v2.3 Provides the ifpdf switch (HO)
ifxetex.sty2010/09/12 v0.6 Provides ifxetex conditional
ifluatex.sty2010/03/01 v1.3 Provides the ifluatex switch (HO)
etex.sty1998/03/26 v2.0 eTeX basic definition package (PEB)
mem10.clo2008/01/30 v0.3 memoir class 10pt size option
mempatch.sty2009/07/24 v6.0f Patches for memoir class v1.6180339
***
Media size of the generated PDF file is 498.9bp x 708.66bp
or 176mm x 250mm that is the correct size for B5.
If your memoir comes from the stone age (before XeTeX and its support),
then update. Otherwise a minimal example and the command line call
help in finding the cause of your problem.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] XeTeX/TeX Live : Setting the default language
On Fri, Nov 04, 2011 at 10:52:37AM +, Philip TAYLOR (Webmaster, Ret'd)
wrote:
Mojca Miklavec wrote:
Now imagine that you send your document to a friend to make some final
corrections submit PDF for printing ... and that friend has set
French or Russian as his default/preferred language, so the printing
house will print the document typeset with Russian hyphenation
patterns. Wouldn't that be nice?
A document for export can contain Khaled's recommended :
\uselanguage {whatever}
A document solely for internal use does not require one,
nor should one need to be added : the installer should
ask the user whether it should respect his or her regional
settings (locale, in Unix-speak, I believe).
And if the British author visits Germany he happily uses
\BenutzedieSprache{Englisch}
No, wait, without spaces???
\Befehlsnamensstart Benutze die Sprache\Befehlsnamenende{Englisch}
;-))
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Anchor names
On Sat, Nov 05, 2011 at 11:59:29AM +1100, Ross Moore wrote:
Conclusion:
* The encoding mess with 8-bit characters remain even with XeTeX.
Well, surely it is manifest only in the driver part: xdvipdfmx
No, the problem are both parts. XeTeX can only write UTF-8,
the death for binary data.
But the bytes need to be encoded anyway, as hexadecimal.
So why cannot this be done before writing out the resulting string?
See my example file, it get's reencoded.
Then I tried to be clever and a workaround by using
/Dc3a46e6368c3b872 for the link name in the source.
But it got converted and the PDF file still contains:
/Dfeff00e4006e0063006800f80072
Only the other way worked:
\special{pdf:dest feff00e4006e0063006800f80072 ...}
\special{pdf:ann ... /D(änchør) ...}
... as this seems to be doing.
I'd vote for *always* doing pdf:dest this way.
Then for consistency, do pdf:ann as if UTF-16BE also.
It might be an accident that this way has worked. If the
bug is fixed, then it might only work the other way or
none way at all or ...
Also instead of http://.../test.pdf#Introduction; you
would have to write something like
http://.../test.pdf#%FE%FF%49%6E%74%72%6F%64%75%63%74%69%6F%6E
Somehow I missed to see that as improvement?
OK.
Glad you did this test.
It shows two things:
1. that such text strings may well be valid for Names,
and that the PDF spec. is unclear about this;
I can't follow. Both string representations are covered
by the PDF specification, a literal string can be
specified in parentheses with an escaping mechanism (backslash)
or given as hex string in angle brackets. Unclear is the
syntax of the argument for \special{pdf:dest ...}.
Agreed.
Can we standardise on the way that *looks like* UTF-16BE with BOM.
That's a higher level and it's an artificial restriction of such a kind
that started the thread.
Already the lower syntax level is unclear. The best solution would be,
if a syntax could be specified/implemented/
supported that allows byte strings. That means someone has to
dig into the sources and do some work, write some documentation ...
2. these UTF16-BE strings are *not* equivalent to other
ways of encoding Name objects, after all.
This is something that should be reported as a bug to Adobe.
There is no problem with the PDF specification. A destination
name is a byte string. You can use UTF-16BE, invalid UTF-8,
a mixture of UTF-32BE with us-ascii, ... all are valid byte strings.
The problem is with xdvipdfmx that recodes the UTF-8 string
provided by XeTeX's specials in different ways.
Then convert the UTF-8 to the encoded HeX of the corresponding UTF16-BE,
before passing it to xdvipdfmx .
Surely that is feasible?
Except that the behaviour of 8-bit characters in destination strings
are unspecified and undocumented. It makes more sense to address
the problem upstream first.
pdfTeX is fine, because it doesn't reencode the strings.
Also \pdfescapestring, \pdfescapename, \pdfescapehex
are available for syntactically correct literal strings.
I've not used these primitives.
Didn't you used to do such conversions within hyperref ?
Of course hyperref uses such conversions, these are required
by the PDF specification.
Or with other utility packages in the 'oberdiek' bundle?
If a package misses such a necessary escaping make a bug
report.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] Anchor names
Hello,
to get more to the point, I start a new thread.
As we have learned, the PDF specification uses byte strings
for anchor names. And there is a wish to use normal characters
in anchor names. Let's make an example:
xetex --ini --output-driver='xdvipdfmx -V4' test
%%% test.tex %%%
\catcode`\{=1
\catcode`\}=2
\pdfpagewidth=100bp
\pdfpageheight=200bp
\shipout\vbox{%
\kern-1in\relax
\hbox{%
\kern-1in\relax
\vrule width0pt height200bp depth0pt\relax
% Destination at (30bp,150bp)
\raise150bp\hbox to 0pt{%
\kern30bp %
\special{pdf:dest (änchør) [@thispage /XYZ @xpos @ypos null]}%
\kern-1bp
\vrule width2bp height1bp depth1bp\relax
\hss
}%
% Link annotation center at (70bp,50bp),
% rectangle at [68bp 48bp 72bp 52bp]
\raise50bp\hbox to 0pt{%
\kern70bp %
\kern-2bp
\special{%
pdf:ann width 4bp height 2bp depth 2bp%
/Type/Annot%
/Subtype/Link%
/Border[0 0 1]%
/C[0 0 1]% blue border
/A%
/S/GoTo%
/D(änchør)%
%
%
}%
\vrule width4bp height2bp depth2bp\relax
\hss
}%
}%
}
\end
%%% test.tex %%%
The link is not working. Looking into the PDF file we can find
the link annotation:
4 0 obj
/Type/Annot
/Subtype/Link
/Border[0 0 1]
/C[0 0 1]
/A
/S/GoTo
/Dfeff00e4006e0063006800f80072
/Rect[68 48 72 52]
endobj
and the destination:
7 0 obj
[3 0 R/XYZ 30 150 null]
endobj
8 0 obj
/Names[c3a46e6368c3b8727 0 R]
endobj
The positions of both the link annotation and the destination are perfect.
The name for änchør is given both times as hexadecimal string.
That's ok, too. But the names are different:
Destination: c3a46e6368c3b872 == UTF-8
Link annot.: feff00e4006e0063006800f80072 == UTF-16BE with BOM
Conclusion:
* The encoding mess with 8-bit characters remain even with XeTeX.
Then I tried to be clever and a workaround by using
/Dc3a46e6368c3b872 for the link name in the source.
But it got converted and the PDF file still contains:
/Dfeff00e4006e0063006800f80072
Only the other way worked:
\special{pdf:dest feff00e4006e0063006800f80072 ...}
\special{pdf:ann ... /D(änchør) ...}
Result:
* Even for nice short names the size is doubled and increased
by two bytes.
* Assymetrical behaviour of \special commands.
* No documentation.
* Unfair, arbitrary byte strings can't be written.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] bann...rule...eann == noann?
Hello,
I don't get an annotation using bann...eann:
% xetex --ini --output-driver='xdvipdfmx -V4' test
\catcode`\{=1
\catcode`\}=2
\pdfpagewidth=100bp
\pdfpageheight=200bp
\font\tenrm=cmr10\relax
\tenrm
\shipout\vbox{%
\kern-1in\relax
\hbox{%
\kern-1in\relax
\vrule width0pt height200bp depth0pt\relax
% Destination at (30bp,150bp)
\raise150bp\hbox to 0pt{%
\kern30bp %
\special{pdf:dest (foobar) [@thispage /XYZ @xpos @ypos null]}%
\kern-1bp
\vrule width2bp height1bp depth1bp\relax
\hss
}%
% Link annotation at (70bp,50bp)
\raise50bp\hbox to 0pt{%
\kern70bp %
\kern-2bp
\special{%
pdf:bann%
/Type/Annot%
/Subtype/Link%
/Border[0 0 1]%
/C[0 0 1]% blue border
/A%
/S/GoTo%
/D(foobar)%
%
%
}%
% ABC%
\vrule width4bp height2bp depth2bp\relax
\special{pdf:eann}%
\hss
}%
}%
}
\end
The annotation apperas, if there are characters inbetween (ABC).
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Anchor names
On Fri, Nov 04, 2011 at 07:31:02AM +1100, Ross Moore wrote:
On 04/11/2011, at 1:58 AM, Heiko Oberdiek wrote:
Hello,
to get more to the point, I start a new thread.
Yes. very good idea.
As we have learned, the PDF specification uses byte strings
for anchor names. And there is a wish to use normal characters
in anchor names.
Within the (La)TeX source, yes!
Of course it needs to be encoded to be safe within the PDF.
That's the problem, the anchor names could also be used as
official part of the PDF file, because it could be referenced, e.g.:
mybeautifuldocument.pdf#Introduction
Let's make an example:
xetex --ini --output-driver='xdvipdfmx -V4' test
\special{pdf:dest (änchør) [@thispage /XYZ @xpos @ypos null]}%
\special{%
pdf:ann width 4bp height 2bp depth 2bp%
/Type/Annot%
/Subtype/Link%
/Border[0 0 1]%
/C[0 0 1]% blue border
/A%
/S/GoTo%
/D(änchør)%
The link is not working. Looking into the PDF file we can find
the link annotation:
4 0 obj
/Type/Annot
/Subtype/Link
/Border[0 0 1]
/C[0 0 1]
/A
/S/GoTo
/Dfeff00e4006e0063006800f80072
In my reading of the PDF Spec. I came to the conclusion
that this UTF-16BE based format is not supported for Name objects.
But maybe I'm wrong here.
My understanding is that it does not matter, whether the byte
string could be interpreted in some encoding. The characters
are just bytes. Also there are keys in the /Dests name tree
and are compared at the byte level. Thus a name encoded as
UTF-8, ISO-8859-1 or UTF-16BE are different strings and thus
different names.
Destination: c3a46e6368c3b872 == UTF-8
Link annot.: feff00e4006e0063006800f80072 == UTF-16BE with BOM
The spec reads that differences in Literal strings are allowed,
provided that they convert to the same thing in Unicode.
So there must be an internal representation that Adobe uses,
but is not visible to us, as builders of PDF documents.
Where, which section?
A literal string can be written different ways at syntax level:
(test) = 74657374 = (\164\145\163\164) = (\164e\163t)
Probably you are referring the Text String Type used for
the text in the bookmarks, the document information and other
places. These strings can be encoded either in PDFDocEncoding
or UTF-16BE with BOM.
Conclusion:
* The encoding mess with 8-bit characters remain even with XeTeX.
Well, surely it is manifest only in the driver part: xdvipdfmx
No, the problem are both parts. XeTeX can only write UTF-8,
the death for binary data.
Then I tried to be clever and a workaround by using
/Dc3a46e6368c3b872 for the link name in the source.
But it got converted and the PDF file still contains:
/Dfeff00e4006e0063006800f80072
Only the other way worked:
\special{pdf:dest feff00e4006e0063006800f80072 ...}
\special{pdf:ann ... /D(änchør) ...}
OK.
Glad you did this test.
It shows two things:
1. that such text strings may well be valid for Names,
and that the PDF spec. is unclear about this;
I can't follow. Both string representations are covered
by the PDF specification, a literal string can be
specified in parentheses with an escaping mechanism (backslash)
or given as hex string in angle brackets. Unclear is the
syntax of the argument for \special{pdf:dest ...}.
2. these UTF16-BE strings are *not* equivalent to other
ways of encoding Name objects, after all.
This is something that should be reported as a bug to Adobe.
There is no problem with the PDF specification. A destination
name is a byte string. You can use UTF-16BE, invalid UTF-8,
a mixture of UTF-32BE with us-ascii, ... all are valid byte strings.
The problem is with xdvipdfmx that recodes the UTF-8 string
provided by XeTeX's specials in different ways.
Can you produce a set of 3 or more PDFs that show the different
behaviours ?
Better still: a single PDF that illustrates the (non-)working
of hyperlinks according to the encodings of the Name objects
and Destinations.
Save my example as test.tex and run
xetex --ini --output-driver='xdvipdfmx -V4' test
(I miss an easy switch for XeTeX to set the PDF version).
With PDF-1.4 object stream compression is not available
and the PDF file can be analyzed directly using a simple
text viewer. (Otherwise the destination and annotation
objects are compressed).
Do it both with XeTeX and pdfTeX (with appropriate inputenc,
to handle the UTF8 input), to test whether there are any
differences.
pdfTeX is fine, because it doesn't reencode the strings.
Also \pdfescapestring, \pdfescapename, \pdfescapehex
are available for syntactically correct literal strings.
I've not tested pdfTeX yet, because of the extra macro layer
required. Does hyperref handle the required conversions then?
It depends on which part of hyperref you are looking.
Yours sincerely
Heiko Oberdiek
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, Nov 02, 2011 at 10:24:11AM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Zdenek Wagner wrote: No, it won't be that easy. Syntax (string) in links is in AdobeStandardEncoding and some of these characters are not valid in UTF-8. OK. But could a PDF reader not use the same detection algorithm as (say) the Microsoft C# Compiler -- No BOM : ASCII; BOM : UTF-8 ? Example: Destination names in PDF are just byte strings. Thus you could put arbitrary rubbisch in there. The string is used as id label to identify a destination/anchor. Regarding hyperref: an anchor name has similar restrictions as a \label name. Letters and digits are safe. The rest might work or does not. (There is some support for babel shorthands, thus they should work.) Regarding XeTeX: AFAIK, it's asymmetriacl it can read many encodings, but can't write arbitrary bytes. Anchor names go into the .aux file, are reread from there and go into the .pdf file. It would be fatal if the names changes (active characters, reencodings, ...) or all uses of that name must undergo the same changes. If the OP needs funny stuff as labels, because they are generated automatically, then the it can be made safe by converting to hex strings (package pdfescape and others), for example. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, Nov 02, 2011 at 11:14:54AM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Heiko Oberdiek wrote: If the OP needs funny stuff as labels Heiko, you are, I believe, a native German speaker (please correct me if I am mistaken). In your personal opinion, are the following letters, arbitrary rubbisch, or funny stuff ? ä, ö, ü, ß, ??, ?? Then try ä, ö, ü, ß \bye in plain TeX. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, Nov 02, 2011 at 11:42:38AM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Heiko Oberdiek wrote: On Wed, Nov 02, 2011 at 11:14:54AM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Heiko Oberdiek wrote: If the OP needs funny stuff as labels Heiko, you are, I believe, a native German speaker (please correct me if I am mistaken). In your personal opinion, are the following letters, arbitrary rubbisch, or funny stuff ? ä, ö, ü, ß, ??, ?? Then try ä, ö, ü, ß \bye in plain TeX. But we're not discussing Plain TeX, Heiko : this is the XeTeX list, You are free to use plain XeTeX. where the world has moved on, where UTF-8 is the norm, and where ASCII is no more than a bad dream. Are you really suggesting that in Plain XeTeX, ä, ö, ü, ß \bye is anything other than a normal, everyday, document ? The mail header of your posting, send by the list server contains: Content-Type: text/plain; charset=iso-8859-1; Format=flowed Then I must have received a quite abnormal mail out of norm? From the last mails I found 477 lines with: Content-Type: text/plain; charset=... us-ascii: 237 UTF-8: 114 ISO-8859-1: 60 ISO-8859-2: 44 windows-1252: 21 windows-1256: 1 I have just processed it here, and with the addition of just two lines to change the default font to a Unicode-compatible one, it generates exactly what one would hope for and expect in the 21st century. Of course, also a font in T1, ... encoding can be used. Or the input encoding might differ from the font encoding by mapping via macros, ... Back to XeTeX: Byte string means that the string consists of bytes 0-255 (or 1..255). Can you write them with XeTeX in a file or use as destination names without using a different encoding? Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, Nov 02, 2011 at 12:21:49PM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Ross Moore wrote: My advice is simply that if you restrict yourself to ASCII letters, then you will not face any difficulties. This is pure pragmatism; nothing less. As was Knuth's decision to base TeX on US-ASCII. Fortunately, FMi and others were able to convince him that he was wrong, whence TeX 3. Now we clearly need to start on Adobe (and Heiko !). Why? For destinations the data type is byte string that covers much more encodings than you can think of. But the tools inbetween apply restrictions (plain TeX, LaTeX, XeTeX, xdvipdfmx, ...). And for example, XeTeX adds the restriction that arbitrary 8-bit bytes cannot be written. A severe restriction when dealing with binary formats and arbitrary data. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, Nov 02, 2011 at 01:11:04PM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Byte string means that the string consists of bytes 0-255 (or 1..255). Can you write them with XeTeX in a file or use as destination names without using a different encoding? I do not understand the question. There /is/ no encoding in a byte string; it is a byte string, by definition. What am I missing ? That XeTeX can't write byte strings. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Hyperref \hyperlink and \hypertarget not working with accented characters
On Wed, Nov 02, 2011 at 01:30:53PM +, Philip TAYLOR (Webmaster, Ret'd) wrote: Heiko Oberdiek wrote: XeTeX can't write byte strings. Is this a XeTeX or an (x)dvipdfmx limitation, Heiko? AFAIK both. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Missing char, missing footnote
On Wed, Oct 12, 2011 at 12:02:21PM +1100, Vafa Khalighi wrote: Without floating environment \caption will not work. There are tricks Provided in the minimal package `capt-of'. The feature is also available in the maximal package `caption'. The danger in mixing floats and non-floats is that the numbering might get out of order, because the floating algorithm does not know about the non-floats. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] HELP! ** ERROR ** Page number 65536l too large!
On Thu, Sep 29, 2011 at 09:00:21PM +0100, Jonathan Kew wrote:
Note that the DVI file format postamble includes a two-byte field for the
total number of pages present, so if you try to put more than 64K pages in
a DVI file, the postamble (at least) will necessarily be incorrect, even
if the file is otherwise well-formed.
TeX or pdfTeX generate such a file (I have tried a file with 7 pages).
But the DVI drivers behave different:
* dvitype is ok, it reports
| there are really 7 pages, not 4464!
and lists all pages.
* dvi2tty prints all 7 pages.
* dvips only prints 4464 pages, but reports in the header:
| %%Pages: 7
* dvipdfmx only prints 4464 pages.
* XeTeX aborts with
| ** ERROR ** Page number 70001l too large!
Perhaps dvips could be fixed, it already knows the correct
number of pages?
And if someone wants to play:
% iniTeX
\catcode`\{=1 %
\catcode`\}=2 %
\catcode`\#=6 %
\countdef\C=0 %
\C=1 %
\countdef\X=255 %
\X=7 %
\chardef\I=1 %
\let\A=\advance
\let\S=\shipout
\let\H=\hbox
\let\N=\ifnum
\let\F=\fi
\def\P{%
\S\H{}%
\A\C\I
\N\C\X
\let\P\relax
\F
\P
}
\P
\end
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Polyglossia broken?
On Wed, Sep 21, 2011 at 02:04:51PM +0200, Pander wrote:
On 2011-09-21 13:58, Arash Zeini wrote:
On Wednesday 21 September 2011, Zdenek Wagner wrote:
2011/9/21 Arash Zeini arash.ze...@gmail.com:
Hello,
See the previous thread open by Alex Hamann
Thanks for your prompt response. I am unable to locate a recent and
relevant
thread started by Alex Hamann.
Vafa's suggestion of loading xkeyval before polyglossia reduces the number
of
errors drastically but brings up new ones related to exaccent, which I load
after xkeyval and polyglossia.
Perhaps both packages should generate a warning if they detect a
usepackage order which is dangerous?
You are quoting *three* packages (xkeyval, polyglossia, exaccent),
which of them do you mean with *both*?
It is a bug in polyglossia that xkeyval has to be loaded manually
before polyglossia, because polyglossia has
forgotten \RequirePackage{xkeyval}.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Polyglossia broken?
On Wed, Sep 21, 2011 at 02:34:41PM +0200, Zdenek Wagner wrote:
That's right. \RequirePackage and \usepackage maintain internally a
list of already loaded packages. There is one potential problem, you
are not specified a different list of options. Thus if you use
\RequirePackage{something} without any options, it is harmless. If a
user needs something with some options, he or she must load it
explicitely with these options in advance.
The option lists may differ. But the requirement of LaTeX is that
the option list of the first load request is the superset of
the options in all load requests.
(load request: \RequirePackage, \usepackage, (\PassOptionsToPackage))
\usepackage[foo,bar,xyz]{something}
\usepackage[bar,foo,xyz]{something}
\usepackage[bar]{something}
\usepackage{something}
is ok, but any new option given later
\usepackage[foo,bar,xyz]{something}
\usepackage[new]{something}% throws an error
If there is an option clash, the user can press h to get
the exented help text of the error and LaTeX shows the options.
Then the user can resolve it by calling the package earlier with
the option superset as option list. And the package documentation
needs to be checked, if options of this package might overwrite
each other.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Polyglossia broken?
On Wed, Sep 21, 2011 at 10:21:46PM +1000, VAFA KHALIGHI wrote:
It is a bug in polyglossia that xkeyval has to be loaded manually
before polyglossia, because polyglossia has
forgotten \RequirePackage{xkeyval}.
Not really. fontspec used to load xkeyval and polyglossia loaded fontspec so
there was no need for polyglossia to load xkeyval again.
No, packages *MUST* add packages for *all* required packages.
The use of xkeyval for fontspec was an *implementation* detail
that can change *any* time, like it has now happened.
AFAIK, the use of xkeyval was never part of the official interface
for fontspec. This would not make any sense, because fontspec deals
with fonts and is not a package for providing key value parsers.
Therefore it is a very clear bug of polyglossia, not to load
xkeyval. A package can be loaded many times using \usepackage
or \RequirePackage. LaTeX only loads the package at the first
request. At the later requests it only checks the date and options
of the request.
It is also good style to add a date, if a package must not be too old:
\RequirePackage{foo}[2010/04/20]
Then LaTeX will complain, if the loaded packages is too old.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Polyglossia broken?
On Wed, Sep 21, 2011 at 03:19:29PM +0200, Zdenek Wagner wrote:
Agreed. What I meant was if package anything contains
\RequirePackage{something} without any options but user needs
something with some option, then the correct way is
\usepackage[options]{something}
\usepackage{anything}
I am not sure whether the same effect can be achieved by giving the
option in \documentclass, probably yes but I would have to check it.
Usually yes.
There is an alternative way, that does not change package
loading order:
\PassOptionsToPackage{options}{something}
\usepackage{anything}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Defining ExtGState objects
On Wed, Sep 07, 2011 at 01:02:38PM +0200, Zdenek Wagner wrote:
\documentclass{article}
\special{pdf: object @opoff /Type /ExtGState /op false /OP false /OPM 0 }
\special{pdf: object @opon /Type /ExtGState /op true /OP true /OPM 1 }
\special{pdf: object @extgs /GSko @opoff 0 R /GSop @opon 0 R }
\special{pdf: put @resources /ExtGState @extgs 0 R }
\begin{document}
A
\end{document}
The requested output (achieved by pdftex) is
% 1 0 obj
/Type /ExtGState /op false /OP false /OPM 0
% 3 0 obj
/Type /ExtGState /op true /OP true /OPM 1
% 4 0 obj
/GSko 1 0 R /GSop 3 0 R
However, xdvipdfmx reports this error:
$ xdvipdfmx -vv -z0 test-xetex
FONTMAP:pdftex.mapFONTMAP:cid-x.mapDVI Comment: XeTeX output
2011.09.07:1234
test-xetex.xdv - test-xetex.pdf
AGL:texglyphlist.txt[1
** WARNING ** Could not find a name object.
** WARNING ** Could not find a key in dictionary object.
** WARNING ** Could not find an object definition for extgs.
...
The references are different from pdfTeX, in pdfTeX you
specify the number followed by 0 R. But in dvipdfm(x)/XeTeX the
objects are referenced by name without 0 R:
\special{pdf: object @extgs /GSko @opoff /GSop @opon }
\special{pdf: put @resources /ExtGState @extgs }
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] analogues of \pdfobj?
On Tue, Aug 30, 2011 at 12:19:51PM +0200, Oleg Parashchenko wrote:
Hello again,
On Fri, 26 Aug 2011 12:32:14 +0200
Heiko Oberdiek heiko.oberd...@googlemail.com
wrote:
...
* \pdfobj useobjnum/pdfobj: Objects can be constructed by
\special{pdf:object ...}
\special{pdf:put ...}
\special{pdf:close ...}
\special{pdf:stream ...} (dvipdfmx)
\special{pdf:fstream ...} (dvipdfmx)
My idea was to implement one-pass part K of N functionality for
multipage tables. With pdftex it is easy, at least the test code works:
%%%
\pdfobj reserveobjnum {}
\mathchardef\num\pdflastobj
\edef\ppp{\noexpand\pdfliteral{BT [\the\pdflastobj\space 0 R]TJ ET}}
\def\para{Counter++. The final value is \ppp\par}
\para
\para
\immediate\pdfobj useobjnum\num {(test)}
%%%
And you need code for:
* that ensures, that the used glyphs are made known for pdfTeX,
otherwise glyphs might be missing;
* that ensures, that the right font is active;
* that takes care of coordinate synchronization between
pdfTeX's coordinate system and the user code at PDF level.
Thanks to your suggestions, I thought that I could make a similar trick
with DVIPDFMx,
\pdfliteral is available as \special{pdf:content ...},
\special{pdf:literal direct ...} and \special{pdf:code ...}.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] analogues of \pdfobj?
On Tue, Aug 30, 2011 at 03:27:40PM +0200, Oleg Parashchenko wrote:
\pdfliteral is available as \special{pdf:content ...},
\special{pdf:literal direct ...} and \special{pdf:code ...}.
Unfortunately, these commands are of no use for referring to other
objects. The TeX level just doesn't aware of exact numerical values of
created objects, and it seems DVIPDFM-literals do not resolve @-names.
Also, I forgot, you can't use references with \pdfliteral with your
text drawing operator either, from the PDF specification:
| Note in particular that content streams, which define the visible contents
| of the document, may not contain indirect references (see Section 3.7.1,
| Content Streams).
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Xelatex - Beamer and transition effects
On Thu, Aug 18, 2011 at 06:11:05PM +0300, snvv wrote:
Is it possible to have transition effects using xelatex?
I have try different things but I haven???t find a solution yet.
Add the following special to the page, where you want to have
the effect:
\special{pdf: put @thispage /Trans/S/Dissolve}
See the PDF specification for the contents of dictionary /Trans.
It works in AR5/Linux. In AR7/Linux and AR8/Linux the effects
are active in full screen mode only.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] Writing binary data in \special
Hello,
I want to use \special with arbitrary binary data, e.g.:
\special{pdf: object @my /Hello/WorldstreamXYZäFOOendstream}^1
However 8bit characters are recorded and written in UTF-8.
\XeTeXinputencoding bytes is only a very partial solution:
* It doesn't work without --etex
* \XeTeXoutputencoding is missing.
Is there a way to write arbitrary binary data in files
and \special commands? Or is this limited to 7bit or UTF-8?
Yours sincerely
Heiko Oberdiek
^1 For the example the workaround would be using the
filter ASCII85Decode (or ASCIIHexDecode). But that blows
the stream contents and increases the final PDF file size.
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xdvipdfmx, page subsets, pgf, transparency
, but both for interested readers and to forestall You shouldn't want to do that, do something else that won't meet your needs instead! responses: The small PDFs will be used with the pdfpages package in a second run of XeLaTeX to generate PDFs for printing the large document as a multi-volume set of books. The purpose of the second step is not clear to me: The final result consists of several PDF files, one for each book? And the first XDV file is just the contents of the books and perhaps some pages are reused for each book, thus that the second run is only used for putting pages together? It's preferable to use many small intermediate PDFs instead of using pdfpages to take pages directly from the original large document, because pdfpages seems to take a time *per page* proportional to the size of the document it is examining; thus the overall process is quadratic without splitting into small PDFs, and linear with splitting. It's a difference of several hours processing time at the moment and likely to become a difference of a few days per run at some point in the future, because the large document is planned to grow to three or four times its current size (i.e. 5000 to 7000 pages) within the scope of the project that it's part of. Then I would suggest writing a program that deals with the XDV file: a) splitting the single master .xdv file into the book .xdv files b) analyzing the specials to add the missing ones to the .xdv file. If I have understood the second XeTeX run, then this step wouldn't be necessary, saving you much time. Item a) is much easier for .dvi/.xdv files than for .tex, .ps, .pdf files, because the .dvi/.xdv files are easy to parse. One difficulty could be the additions of XDV to the DVI format, if they are not documented. Then the specification must be guessed from the sources. The DVI format is well documented by Knuth (see sources of dvitype, ...). Item b) need some knowledge of PDF internals. At least the implementing for a known limited set of specials should be not to difficult. But supporting it for more general cases can increase the work to the work of a large software project. For example, the set of specials for page 4 of the example should consist of 2.1, 3.2, 4.1. In this case 2.2 and 3.1 do not harm, because the values of the same dict key are the same. bit 3.2 adds an additional value in the dict that is not needed. In this case it might be tolerable. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] xdvipdfmx, page subsets, pgf, transparency
On Mon, May 16, 2011 at 07:57:14AM -0500, msk...@ansuz.sooke.bc.ca wrote: On Mon, 16 May 2011, Heiko Oberdiek wrote: take some actions arising specials. But these actions might have effects on the whole document. Sometimes this is good to avoid missing object declarations and other things. But sometimes extra stuff or wrong stuff is added because of pages that the user has explicitly excluded. Thanks for investigating this. It's a complicated and pretty obscure problem that would only affect a few users, so I appreciate your paying attention. I excluded the *page*. I didn't exclude the *special*. Not the special is part of the page. Thus you are excluding the page with the special. I think it's a bug because A. It's a bug in the documentation. Unhappily quite many dvi drivers that allow the selection of page don't tell that this might not work if specials are involved. the software detects that it is writing incorrect output, and B. it gives me no way to get correct output. There's no way to include the special except by including the page. The problem is that the special does not tell if it belongs to the page only, to this and the following pages or the whole document. This does not matter, if the whole document is set. The contents of the special is arbitrary user stuff. Therefore it is not possible for the DVI/XDV program to classify the specials in general. that won't meet your needs instead! responses: The small PDFs will be used with the pdfpages package in a second run of XeLaTeX to generate PDFs for printing the large document as a multi-volume set of books. The purpose of the second step is not clear to me: The final result consists of several PDF files, one for each book? And the first XDV file is just the contents of the books and perhaps some pages are reused for each book, thus that the second run is only used for putting pages together? The second run of XeTeX also adds some additional graphics, most notably thumb-tabs along the sides of the pages, and it changes the page size to accomodate that, so that the tabs will bleed all the way off the paper edge when printed and trimmed. It's not purely a page-subsetting operation. And I'd rather not make it purely a page-subsetting operation (by adding the thumb-tabs and changed size to the original large file) because that would mean generating two large files (one with thumb-tabs and one without; I also have a use for the large file in its current form) and the generation of the large file can't be parallelized (it's three long XeTeX runs that must be done sequentially on a single CPU). The way I'm currently doing it means much of the work can be performed simultaneously on multiple CPUs and I can do at least some of the testing on just a single volume without having to generate the whole thing every time. Then I would suggest writing a program that deals with the XDV file: a) splitting the single master .xdv file into the book .xdv files b) analyzing the specials to add the missing ones to the .xdv file. I'll do this if forced to, but since xdvipdfm is documented as being able to generate a page subset, I'd like to use it for its documented behaviour. The documentation can be fixed. Nevertheless it will not help you. If I have understood the second XeTeX run, then this step wouldn't be necessary, saving you much time. Unfortunately, I don't think it'll be trivial to eliminate the recombining step, because it does more than pasting the small PDFs together. It would habe been a bonus, if the result of the tool would have get the result of the final recombination step. But that's not mandatory. The tool only must write a page range of a .xdv file into a new .xdv file with the selected page range and specials fixed. I'll continue playing with it, though; there may be a way to either eliminate the pasting step or use something faster than the pdfpages package. Right now the pdfpages package seems to be the real trouble spot for speed. I don't think, pdfpages is the problem. You can verify it by using the low level stuff for including a PDF page. At low level you can only specify a pdf file and a page. Thus perhaps the whole pdf file is read again and again for each included page. There is no interface to specify and open a pdf file and to reference pages from it without rereading the file. If there is something similar to it that could take pages from an XDVI file then I could eliminate the intermediate run of xdvipdfm, but then I'd still need to either do the page subsetting outside of XeTeX, or have the thing that pastes together the XDVI files also do page subsetting and not have the same problem with specials that xdvipdfm has. I proceeded with the dummy image on an early page workaround and that seems to work pretty well. I wouldn't rely on it. In case of transparency the dummy graphics should include all used opacity values. See
Re: [XeTeX] [luatex] [fontspec] outline fonts?
On Wed, May 11, 2011 at 12:44:25PM +0200, Martin Schröder wrote: is there a way to switch a font to outline rendering with OTF/fontspec? I know I can hack this in PDF, but a fontspec feature would be nicer. :-) Without fontspec, see package `pdfrender'. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Inlined images?
On Tue, Apr 12, 2011 at 09:30:57AM +0100, Jérôme Etévé wrote:
Of course if you just want to include the files as attachments to the PDF
document, without any preview, then you can certainly do this using LaTeX.
(But then you would probably have asked a different question.)
Nice, so how do we do that? Is it possible to do something along the
lines of (fantasy code):
\attachBase64{ID,'image/png', base64 encoded data}
and refer it in includegraphics:
\includegraphics{cid:ID}
Of course, a converter for base64 and others could be written
in TeX^1. But the result would have to be written in temporary
external files and be input as image via \includegraphics.
But I don't see the point of this exercise, you have such
a converter already in a much more efficient programming
language than TeX.
Yours sincerely
Heiko Oberdiek
^1 Some conversions already are written, e.g. for encoding and
decoding hex dumps: package `pdfescape'.
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Inlined images?
On Tue, Apr 12, 2011 at 11:01:57AM -0700, Mike Pomax Kamermans wrote: On 4/12/2011 6:31 AM, Jérôme Etévé wrote: I'm using LaTeX (XeTeX) to produce documents programmatically and some of them include images gathered from a database, so I'm looking for a way to embed those images in my document without having to write them to temporary files whilst I'm processing my LaTeX. To follow up on Heiko's comment, a question: whether you are writing the images to temp files yourself, and pointing to those images in your LaTeX source, or whether you include them as some binary data in the .tex file, which is then decoded and written to temporary files by LaTeX so that it can include them, the intermediate result is the same: temporary files are going to be written to disk. From an editorial point of view it would be much safer to stay the course you are on now, making sure your code generates the .tex source as well as writing the images as temporary files, with a cleanup once LaTeX is done compiling to get rid of all the temporary files that were necessary during the run. LaTeX is going to generate quite a number of temporary files anyway (.aux, .log, .toc, etc. etc.) that need to be cleaned up after the compilation run, and your system is clearly capable of writing to disk, so I don't quite understand why writing the images to temp files is undesirable. Images are usually binary files. But TeX can only write text files, especially it adds a new line marker at the line end (\write). Also it depends on the TeX executable and its option settings, how non-printable characters are put into the file. (You don't want to have a notation like ^^@, ^^A, ... in the file). Is there a benefit to only writing a single .tex file and calling TeX over writing a .tex file + image files, calling TeX and then performing cleanup when it completes without errors? You can include the base64/hex/... images in the TeX file, different methods are available, e.g.: * Enviroment/package `filecontents' * docstrip Then the encoded text image files are converted to the binary image files. It can be done by TeX only if the TeX engine knows the `shell escape' feature and if this feature is enabled. Cleanup: TeX can't delete files. Thus again the `shell escape' feature is needed. But depending on the driver the image files must not be deleted. For example, DVI driver usually only embed the image file name references, but not the images. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Bidi, memoir and footnotes
On Thu, Feb 10, 2011 at 08:07:26PM +, Arash Zeini wrote:
! No room for a new \count .
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=noroom
No room for a new `thing'
In short: \usepackage{etex}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Running out of memory in XeSearch while trying to XeIndex on largish latex files.
On Wed, Feb 09, 2011 at 10:17:54PM +0100, Paul Isambert wrote:
Le 09/02/2011 20:52, Michael Joyner a écrit :
We are trying to use XeIndex/XeSearch on what we consider to be
some medium/small documents and are getting the following error:
! TeX capacity exceeded, sorry [save size=8].
\pdfstringdef ... \let \GenericError \@gobblefour
\let
\GenericWarning \@gob...
l.5671
Here is how much of TeX's memory you used:
26308 strings out of 494522
458137 string characters out of 503842
738532 words of memory out of 300
29310 multiletter control sequences out of 15000+20
9330 words of font info for 51 fonts, out of 300 for 9000
670 hyphenation exceptions out of 8191
40i,7n,43p,500b,80001s stack positions out of
5000i,500n,1p,20b,8s
Output written on 02944.pdf (79 pages).
I have tried increasing the 'save size' above 8, but it
doesn't seem to go any higher. :(
This occurs when the package is loaded, regardless as to whether
we specify words to index or not.
We tested with just XeSearch loading, and the same error occurred.
We would really appreciate any advice on this.
Without a minimal example, there isn't much I can do. But possible
loops are described on page 5 of the doc. Are you sure you're not in
such a case?
\documentclass{article}
\usepackage{xesearch}
\begin{document}
\tracingassigns=1
Hello World
\tracingassigns=0
\end{document}
The example shows that each word creates two command sequences,
example for Hello:
{changing \Hello@cs@xs@words=undefined}
{into \Hello@cs@xs@words=\relax}
{changing \hello@ncs@xs@words=undefined}
{into \hello@ncs@xs@words=\relax}
I don't know the internals of xesearch.sty, but do you really need
the meaning \relax? Or it is just the usual side effect of TeX's
\csname?
In \xs@@F@Test you are using:
\expandafter\ifx\csname\xs@String @cs@xs@words\endcsname\relax
Perhaps you can replace it by \ifcsname ...\endcsname?
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] wrong page labels in slides with hyperref
On Sat, Feb 05, 2011 at 11:25:42PM +0100, Pablo Rodríguez wrote:
\documentclass{slides}
\usepackage{hyperref}
\begin{document}
\begin{slide}
first
\end{slide}
\begin{slide}
second
\end{slide}
\end{document}
if I compile it without hyperref, page labels in PDF are fine, but
all page labels are set to zero when compiled with hyperref.
Could someone confirm whether this is a bug in hyperref?
It was not supported by hyperref, because class `slides'
doesn't use \thepage but a complicate combination of counters
slide, note, overlay and page. In 2011/02/05 v6.82a I have now
implemented some support for class `slides' for options
`pdfpagelabels' and `pageanchor'.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] pdf_link_obj(): passed invalid object.
On Wed, Dec 22, 2010 at 04:42:30PM +0100, Ulrike Fischer wrote: Am Wed, 22 Dec 2010 13:29:16 + schrieb Jérôme Etévé: See doc.tex , flu.pdf (it works) and matrix.pdf (including it breaks). $ xelatex doc.tex ... use matrix.pdf page37 use matrix.pdf page37 [38] (./doc.aux) ** WARNING ** Could not find any valid object. ** WARNING ** Could not find a value in dictionary object. ** WARNING ** Didn't find endobj. ** ERROR ** pdf_link_obj(): passed invalid object. I can reproduce the problem with a current miktex. I could process the file by including matrix.pdf with pdflatex in a matrix2.pdf and this including this in the main document processed by xelatex (I had to use the option --output-driver=xdvipdfmx -V5 as pdflatex generated a 1.5.-pdf). xelatex itself (with option --no-pdf) worked fine. It was xdvipdfmx which complained. So I would at first make a bug report to the xdvipdfmx maintainer. (My first suspect would be the object number: The problematic pdf start with 0 0 obj, the other (also the new matrix2.pdf) have a number different from zero). But I don't know much about pdf. This could also be irrelevant.) Indeed, matrix.pdf is utterly broken. And your suspicion with object number 0 is correct, the problem is the crossref table: The first object number 0 in the xref table is reserved as start of a linked list with free objects, from the PDF spec.: | The first entry in the table (object number 0) is always free | and has a generation number of 65,535; it is the head of | the linked list of free objects. The last free entry | (the tail of the linked list) links back to object number 0. | (In addition, the table may contain other free entries | that link back to object number 0 and have a generation | number of 65,535, even though these entries are not in | the linked list itself.) The first entry in matrix.pdf is: 000323 0 n It should be 000323 65536 f Rationale: * Type f and the generation part 65536 is a requirement of the PDF specification. * 323 is not a valid file position of a PDF object, but 323 is free object. Also the entry for object number 2 is wrong: 16 f * 16 is not a free object, as last entry of the linked list of free objects, it must point back to entry 0: 00 f The starting 0 0 obj ... is not a valid PDF object, the ... looks like a trailer dictionary. But this part of the PDF file is not referenced, thus it's just garbage that is usually ignored. xdvipdfmx is correct if it does not like the broken PDF file. If the very first entry of the xref table is already totally wrong, what else might be broken. The PDF file says that the producer is: www.adlibsoftware.com:EXS3190-Windows 2003:TNG If this is the producer and you have paid for the software, than try to get a fixed version or to get your money back. The file matrix.pdf seems fixable if at least the first entry of the xref table is fixed: * Replace 0 n by 65536 f in the line 000323 0 n. That already makes xetex/xdvipdfmx happy. * Or run the file through pdftk to generate a fixed pdf file: pdftk matrix-broken.pdf cat output matrix-fixed.pdf Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Unicode Arabic hyperlinks
On Tue, Dec 14, 2010 at 11:16:00AM +, Juan Acevedo wrote:
I wonder if anyone can help me have Arabic hyperlinks. I started trying with
polyglossia + hyperref, as per the following minimal file (I have left the
actual Arabic characters out of this sample for ease of testing):
-
%!TEX TS-program = xelatex
%!TEX encoding = UTF-8 Unicode
\documentclass{book}
\usepackage[xetex,unicode=true]{hyperref}
\usepackage{fontspec,xltxtra,xunicode}
\usepackage{polyglossia}
\setdefaultlanguage{arabic}
\newfontfamily\arabicfont[Script=Arabic]{Scheherazade}
\begin{document}
\tableofcontents
\part{mypart}
\chapter{linkhere}\chapter{ajksfhak;j}
\section{naskdgfklh}\section{2naskdgfklh}
\end{document}
-
Can someone rewrite the example using fonts that are
available on TeX Live 2010, please?
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Unicode Arabic hyperlinks
On Tue, Dec 14, 2010 at 12:12:07PM +, Philip Taylor (Webmaster, Ret'd) wrote: Scheherazade is freely downloadable from SIL, Heiko, if that helps ? I am not familiar with Arabic typesetting/fonts at all. Thus I can spend my time in looking for alternatives and/or installing the fonts. But then there is no time left for analyzing/fixing the problem. If TL 2010 provides alternatives, then I think it's probably a very easy and fast job to provide a `more minimalized' example. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Unicode Arabic hyperlinks
On Tue, Dec 14, 2010 at 01:03:23PM +, Juan Acevedo wrote:
Can someone rewrite the example using fonts that are
available on TeX Live 2010, please?
For our current case, it may be easier to use whatever Arabic font is your
system's default, but actually, since I have not used Arabic text in my
sample, you can run it with any Roman font, as below, and you will only
need to ignore the warning about Arabic script not being there. The
problem persists, i.e., the hyperlinks don't work, and for that your help
is most appreciated.
--
%!TEX TS-program = xelatex
%!TEX encoding = UTF-8 Unicode
\documentclass{book}
\usepackage[xetex,unicode=true]{hyperref}
\usepackage{fontspec,xltxtra,xunicode}
\usepackage{polyglossia}
\setdefaultlanguage{arabic}
\newfontfamily\arabicfont[Script=Arabic,ExternalLocation]{texgyrepagella-regular}
\begin{document}
\tableofcontents
\part{mypart} \chapter{linkhere}\chapter{ajksfhak;j}
\section{naskdgfklh}\section{2naskdgfklh}
\end{document}
--
Many thanks, very helpful. And thanks to Michiel for only using fontspec.
Analysis: polyglossia/arabic redefines \...@arabic. For destination names
the original version is the better choice, because it is expandable
and generates ASCII digits.
Thus I have fixed hyperref in this sense (2010/12/14 v6.81x).
Update is on its way (see README).
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX and beamer
On Tue, Dec 14, 2010 at 01:02:41PM +0100, Yves Codet wrote:
With LaTeX the attached file compiles, but with XeLaTeX I get the
following error:
./essai.tex:28: Undefined control sequence.
argument \pdfmark
[{\box \...@tempboxa
}]{pdfmark=/ANN,Subtype=/Movie,Movie=...
l.28 \end{frame}
?
What am I doing wrong?
Nothing.
Package `multimedia' does not support dvipdfm(x)/XeTeX.
Either pdfTeX or pdfmark based drivers are supported.
dvipdfm(x)/XeTeX is a different class of drivers.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] \textsuperscript and \textsubscript size
On Sat, Nov 06, 2010 at 08:08:24PM +0100, BPJ wrote:
Is it an optical illusion, or is the size of \textsuperscript and
\textsubscript rather like \tiny than like \scriptsize?
It depends on the font size context, thus the size can even
be larger than \normalsize:
\documentclass{article}
\begin{document}
X\textsuperscript{A}{\scriptsize A}{\tiny A}
Normalsize: A
{\Huge
X\textsuperscript{A}{\scriptsize A}{\tiny A}
}
\end{document}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Several apostrophe-related problems (kerning, mapping)
On Mon, Nov 01, 2010 at 09:39:35PM -, John Was wrote:
However, by reading (ahem) the hyperref manual, I noticed the
existence of the command \texorpdfstring which does just what I want
:
I just have to replace apostrophes by \texorpdfstring{?}{'} (first
one is curly, second one is straight), and voilà !
Tedious, but it works !
If your ? is active, then you can redefine it using
\pdfstringdefDisableCommands:
\usepackage[unicode]{hyperref}
% make your ? active
\pdfstringdefDisableCommands{%
\def?{'}%
}
Then the conversion is done automatically without the need for
manual uses of \texorpdfstring{?}{'}.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] File name bug when using \includegraphics
On Thu, Oct 07, 2010 at 10:14:42PM -0500, Herbert Schulz wrote:
On Oct 7, 2010, at 8:28 PM, Akira Kakuto wrote:
Hi,
I found a bug related to \includegraphics. If the file name includes
, it stops the compiling and does not show any useful information. I
also found out that there was no problem with in the file name when
using pdflatex.
On windows, there was no error with xelatex for an
example:
\includegraphics[width=0.8\textwidth]{mm.eps}
There does seem to be a problem with ghostscript 8.71, at least on Mac.
That seems to be where it's dying.
I can confirm the bug under Linux for files in \special{PSfile=...}.
The problem is located in xdvipdfmx. Using the configuration
file dvipdfmx.cfg it constructs a command line for conversion to PDF.
The command line is then passed to the *shell* and the shell interprets
some characters in a special way.
I strongly recommend to change the D option of dvipdfmx.def
by adding single quotes around arguments with user input, e.g.:
D rungs ... -sOutputFile=%o %i -c quit
to
D rungs ... '-sOutputFile=%o' -f '%i' -c quit
Unhappily single quotes will not work in Windows, AFAIK.
At least double quotes can/should be used:
D rungs ... \-sOutputFile=%o\ -f \%i\ -c quit
However double quotes aren't sufficient for Linux, because they
still allow the special interpretion of some characters.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] hyperref broken??
On Sun, Oct 03, 2010 at 12:12:40AM -0400, David Perry wrote:
I just updated MiKTeX; I noticed that both hyperref and memoir were
included in the update. Now my book (which uses memoir) won't
compile.
The following lines have been in my preamble for months without change:
\usepackage[hypertex,
Now I get this:
! Package hyperref Error: Wrong DVI mode driver option `hypertex',
(hyperref)because XeTeX is running.
This is correct. XeTeX is used to generate PDF, `hypertex' is
a driver for DVI mode. You can easily omit the option, because
XeTeX is automatically detected.
If you want to process the file without XeTeX in DVI mode
without changing options, you can use
driverfallback=hypertex
Then this driver setting is ignored, if XeTeX, pdfTeX in PDF mode,
VTeX are detected.
So I read the latest hyperref doc. I saw the section about the
various drivers and so forth, but it's not clear to me how to fix
this. hyperref is obviously detecting that xetex is running, which
the manual says it will do. I tried removing the reference to
'hypertex' in the hope that it could find the right driver, but that
just gave a lot more meaningless (to me) errors.
In your option list you have forgotten several commas.
Also breaklinks is more an internal option that reflects the
abilities of the driver. It can't enable properly broken
links, if the driver does not support it.
I don't get any errors:
\documentclass{article}
\usepackage[
pdfpagemode=UseOutlines,
bookmarks,
bookmarksopen,
pdfstartview=FitH,
linktocpage=false,
% colorlinks,
% linkcolor=black,
% citecolor=black,
% urlcolor=black,
pdfborder={0 0 0},
plainpages=false,
pdfpagelabels=true,
]
{hyperref}
\hypersetup{
pdftitle={Document Preparation for Classical Languages},
pdfauthor={David J.Perry},
pdfsubject={Creating text in classical, biblical, and medieval studies},
pdfkeywords={Latin, Greek, Hebrew, classics, medieval, biblical,
fonts, Unicode, OpenType},
}
\begin{document}
\end{document}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Extra trailing space in IPA font with xltxtra
On Tue, Sep 21, 2010 at 03:30:20PM +0200, Heiko Oberdiek wrote: After an update of TL, the example breaks with lots of errors and warnings: Sorry false alarm, an old fontspec.sty in the scratch directory was found first. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with Polyglossia's \aemph command
On Sat, Sep 18, 2010 at 11:29:22AM +1000, Vafa Khalighi wrote:
On the attached minimal example I get the following error when I use the
Polyglossia command \aemph to place an overline over text.
* ! Undefined control sequence.
** \aemph #1-$\overline {\hboxR
The control sequence \hboxR is undefined which means you have an old
version of the bidi package. Update your bidi to the latest version
(v1.1.4c).
Because of that, the \RequirePackage command knows an optional
argument that specifies the version date that the loaded package
should at least have. Otherwise LaTeX prints a warning, that
an old package is used, but a newer one is requested.
In case of \aemph:
\atendpreambl...@ifpackageloaded{bidi}{\newcommand*{\aemph}[1]{$\overline{\hboxr{#1}}$}}{}}
Guards can be used:
* \...@ifpackagelater to ensure a appropriate version of package bidi
* checking for \hboxR.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
[XeTeX] PDF minor version
Hello, for debugging purposes I need a lower PDF minor version number for the PDF file generated by XeTeX. * Unhappily neither xetex nor a \special are able to change the PDF minor version number. Thus take this as feature request. * The only way I know is using xetex -no-pdf, followed by xdvipdfmx -V number. xdvipdfmx --help shows: ... -V number Set PDF minor version [4] However xdvipdfmx generates PDF-1.5 by default. Thus this is a bug report. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] PDF minor version
On Thu, Sep 16, 2010 at 07:00:40AM -0700, Michiel Kamermans wrote: Heiko, for debugging purposes I need a lower PDF minor version number for the PDF file generated by XeTeX. Wait, do you just need a lower version number, or a PDF built to a lower version specification? I want to read the dictionaries in uncompressed form. Therefore I need a PDF without object compression of PDF-1.5. Thus correctly I must make another feature request: * Turning object compression on and off. xdvipdfmx only provides: -z number Set zlib compression level (0-9) [9] Because the first is a job for GhostScript, not for the output driver. However, if you need a PDF built to 1.4 or 1.3 or even lower spec, then I'd agree it would be good to have a way to make XeTeX tell the output driver to generate a lower version style PDF. There is another communication problem: Suppose, there is a package that can generate PDF code for different PDF versions (probably mostly by enabling/disabling features), then the package does not know the output pdf version. Therefore, support for pdfTeX's \pdfminorversion, \pdfcompressionlevel, \pdfobjcompressionlevel would be nice. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Inactive citation links with hyperref and natbib
On Thu, Sep 16, 2010 at 10:50:55AM +0200, Pierre Morel wrote:
- Babel when set to French does something to the colon character (spacing
around colon is different in French), which interferes with the colon
separator used for in my references
The next hyperref version 6.81p will address this issue and
sanitze all anchor names for \hy...@anchor and \hy...@anchorstart.
- When using pdftex, it produces an error, stopping at the first reference
of the first French part
With my test file I don't get an error message:
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[frenchb]{babel}
\usepackage{natbib}
\usepackage[debug]{hyperref}
\begin{document}
\cite{au:yp}
\begin{thebibliography}{}
\bibitem[Mustermann, 2010]{au:yp}
Mustermann, H. (2010).
\newblock Test.
\end{thebibliography}
\end{document}
- With Xetex, it doesn't say anything, it just messes with hyperref
All drivers should be fixed in 6.81p.
My quick and dirty fix is to deactivate what babel does with the colon
with \shorthandoff{:}, but I get incorrect spacing around the colon (not
that bad).
Babel has \...@safe@activestrue and \...@safe@activesfalse to switch
the behaviour of shorthands. Hyperref 6.81p uses \...@safe@activestrue
inside a group to sanitize the anchor names only.
Switching to polyglossia makes things worse: xetex stops at the
first reference of the first French part.
I can't reproduce it using
hyperref 6.81m and polyglossia 2010/07/27 v1.2.0a
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{polyglossia}
\setdefaultlanguage{french}
\usepackage{natbib}
\usepackage[debug]{hyperref}
\begin{document}
\cite{au:yp}
\begin{thebibliography}{}
\tracingmacros=1
\bibitem[Mustermann, 2010]{au:yp}
Mustermann, H. (2010).
\newblock Test.
\end{thebibliography}
\end{document}
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] PDF minor version
On Thu, Sep 16, 2010 at 02:17:34PM -0400, Andy Lin wrote: I thought you could simply edit dvipdfmx.cfg? If I would have known it ;-) I couldn't find any docu about it. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Inactive citation links with hyperref and natbib
On Wed, Sep 15, 2010 at 04:14:07PM +0200, Pierre Morel wrote:
I'm writing my thesis using xetex, and use natbib for the bilbiography and
hyperref to get links inside the PDF. Everything is supposed to work
together, but the links of citations (which are supposed to get me to the
actual reference when I click on a citation) are not active. They appear
as links (color, cursor change on hover), but nothing happens when I click
on them. The other intra-document links work well (TOC, figures,
equations), and I get no feedback about my problem in the log. It looks
like the (unsolved) problem this guy had with Lyx :
http://www.mail-archive.com/lyx-us...@lists.lyx.org/msg60393.html
I made sure that I use the xetex option with hyperref, and that all
citations are in natbib formats. For info I use multiple files with
\input{} as well as multiple .bib files.
Any ideas on how to solve that ?
Make a minimal example (few lines, but complete) that shows the problem.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeXpdffile media box etc
On Thu, Sep 09, 2010 at 09:03:55AM +0200, Paul Isambert wrote:
\pdfpagesattr{
/CropBox [llx lly urx ury]
/MediaBox ...
...
}
NO, don't add /MediaBox. It's set by pdfTeX and can be configured
by \pdfpagewidth and \pdfpageheight.
The other boxes can be set this way (or using \pdfpageattr).
However dealing with \pdfpageattr(s) is very nasty in general.
* Previous contents should be included.
* Setting the same key twice should be avoided.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeXpdffile media box etc
On Wed, Sep 08, 2010 at 12:06:59PM +0930, Will Robertson wrote: I'm writing up the syntax of \XeTeXpdffile and \XeTeXpicfile and I'd like someone who knows better than I do to explain the optional argument to \XeTeXpdffile to control the bounding box of the graphic: [ crop | media | bleed | trim | art ] Also, is there a way to access this functionality through \includegraphics? As maintainer for pdftex.def I have done in the new version v0.05a: | Update from v0.04r to v0.05a: | * New options for PDF images: | * pagebox=(media|crop|bleed|trim|art)box | * New options for bitmap images: |Details, see PDF specification and ChangeLog. | * interpolate=(true|false) | * decodearray=... | * maskarray=... | * intent=... | * New options for bitmap and PDF images: | * ocobjnum=positive integer | * ocobjref=object reference | Both options specify an optional content dictionary | as object reference, see PDF specification and | ChangeLog. Who are the maintainers of xetex.def? Can they add the option `pagebox' as well? Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX documentation? (from Checking if a font exists)
On Wed, Sep 01, 2010 at 01:37:56PM +0930, Will Robertson wrote: On 2010-08-31 00:02:43 +0930, Heiko Oberdiek heiko.oberd...@googlemail.com said: However it's quite incomplete, two examples: * \suppressfontnotfounderror is missing * For the correct syntax of \XeTeXpdffile I had to look into the sources of XeTeX. I've added \suppressfontnotfounderror to the source: http://github.com/wspr/xetexref Will update to CTAN sooner or later. (I have trouble doing so from behind the proxy at uni.) I don't know the syntax of \XeTeXpdffile either, so contributions accepted. \XeTeXpdffile filename [page int] [crop|media|bleed|trim|art] [scaled int|xscaled int|yscaled int |width dimen|height dimen |rotated decimal]* The first two options are specific for PDF files (\XeTeXpdffile), thus the syntax of \XeTeXpicfile is \XeTeXpicfile filename [scaled int|xscaled int|yscaled int |width dimen|height dimen |rotated decimal]* filename is the usual file name argument of \input, \openin, ... It must not terminated by \relax if options are given. int and dimen are the usual integer or dimen specifications of vanilla TeX. However decimal is introduced by XeTeX and needs more investigating. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XeTeX documentation? (from Checking if a font exists)
Hi, On Wed, Sep 01, 2010 at 01:21:38AM -0700, Michiel Kamermans wrote: \XeTeXpdffile filename [page int] [crop|media|bleed|trim|art] [scaledint|xscaledint|yscaledint |widthdimen|heightdimen |rotateddecimal]* The first two options are specific for PDF files (\XeTeXpdffile), thus the syntax of \XeTeXpicfile is \XeTeXpicfilefilename [scaledint|xscaledint|yscaledint |widthdimen|heightdimen |rotateddecimal]* Are you sure scale takes int and not decimal? Scaling in integer steps sounds like it might be a problem. No, it's TeX scaling, the unit is per thousand. It's the same scaling specification as for \font: Scale factor 1000 means no scaling at all. Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Checking if a font exists
On Sun, Aug 29, 2010 at 10:55:10PM +0100, Philip Taylor (Webmaster, Ret'd)
wrote:
Grzegorz Murzynowski wrote:
And when the 18th output is on (writing to shell), you can put
\immediate\write 18{fc-list Myriad Pro fontcheck.tex}
\newread\fontcheck
\immediate\openin\fontcheck=fontcheck.tex
\ifeof \fontcheck ???
Is the \immediate necessary before the \openin at line 3 ?
No. (But it doesn't any harm either.)
There are lots of other problems (apart from the question,
whether fc-list is the correct test):
* \write18 might be disabled, then the write line isn't executed.
At least this can be tested by \pdfshellescape
(0 is disabled, 1 is unrestricted enabled, 2 is restricted enabled)
* \write18 can be enabled, but restricted (\pdfshellescape is 2).
The command might not be part of the allowed program list.
There is no way to test it except trying the feature.
* fontcheck.tex is generated in the current directory.
However it can be read from a different directory, depending
on the TeX configuration (TEXINPUTS, ...).
Especially problematic if \write18 is not enabled and the
existence of the file is used as check, whether the \write18
line has worked.
This can be cured by the pipe feature:
\openin\fontcheck |fc-list 'Myriad Pro'
Does it (especially the single quotes) work in Windows?
* A first line is also read, if the file is empty.
The macro that stores the line contains the character,
configured by \endlinechar and is empty if \endlinechar=-1.
* ...
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Checking if a font exists
On Mon, Aug 30, 2010 at 08:22:53AM +0100, Jonathan Kew wrote:
On 30 Aug 2010, at 05:56, Wilfred van Rooijen wrote:
The (more dificult) solution could be to make a shell script which will run
the compilation of the xelatex source and detect whether or not the run was
succesfull - if not, change the input file to the other font and retry.
I'm surprised no-one has suggested the straightforward, pure-xetex approach:
something along these lines (untested).
\def\myfont{Myriad Pro}
\def\myfallback{Arial}
\count255=\interactionmode
\batchmode
\font\foo=\myfont\space at 10pt
\ifx\foo\nullfont
\font\foo = \myfallback\space at 10pt
\ifx\foo\nullfont
\errorstopmode
\errmessage{no suitable font found}
\else
\let\myfont=\myfallback
\fi
\fi
\interactionmode=\count255
% and now proceed to use \myfont.
* It takes lots of time if the font cannot be found.
* kpsathea complains Invalid fontname `Myriad Pro', contains ' '
* The error code is set because of the error message, if the
font cannot be found.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Checking if a font exists
On Mon, Aug 30, 2010 at 09:58:20AM +0100, Philip Taylor (Webmaster, Ret'd) wrote: Heiko Oberdiek wrote: On Mon, Aug 30, 2010 at 08:22:53AM +0100, Jonathan Kew wrote: I'm surprised no-one has suggested the straightforward, pure-xetex approach: something along these lines (untested). snip * It takes lots of time if the font cannot be found. * kpsathea complains Invalid fontname `Myriad Pro', contains ' ' * The error code is set because of the error message, if the font cannot be found. None the less, it still seems to be the philosophically correctly approach (IMHO, of course). What kind of philosophy? An error as part of normal behaviour? ;-) Yours sincerely Heiko Oberdiek -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] xelatex crashes with this document
On Sat, Jun 26, 2010 at 12:03:32AM +0200, Pablo Rodríguez wrote:
The text-anonymized can be found at
http://www.ousia.tk/xelatex-crasher.tex. Now it crashes on page 13.
Minimal examples:
LaTeX:
\documentclass{book}
\pagestyle{plain}
\textheight10pt
\begin{document}
\footnote{a\\b}
\end{document}
plainTeX:
\def\plainoutput{\shipout\vbox{\pagebody}}
\vsize15pt
\hsize10pt
\insert\footins{ab cd}
\end
The problem is the footnote broken across pages.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem: Beamer+xelatex+\XeTeXdefaultencoding
On Tue, Jun 22, 2010 at 09:49:26AM +1000, Ross Moore wrote:
On 22/06/2010, at 9:26 AM, Heiko Oberdiek wrote:
When reading the input stream, a single line-end character might
be generated at the start ?
But that still leaves open the question of how it picks up
the character string '@s...@act' .
Maybe it all happens internally and there is a buffer overrun?
I came to the same conclusion, see my answer to Josephs mail.
The problem is not related to hyperref:
\documentclass{article}
\XeTeXdefaultencoding UTF-8
\AtBeginDocument{%
\InputIfFileExists{t003.out}{}{}
}
\begin{document}
\end{document}
It shows the string OT1/cm.
OK.
The problem is perhaps really within LaTeX's
\IfFileExists command.
It doesn't use TeX's \immediate qualifier
when calling \openin and \closein for the preliminary
check to see whether the file exists or not.
The need for this primitive is discussed in the TeXbook ,
and surely the preliminary check is precisely a place
where it should be used.
You mean \openout/\write/\closeout?
\openin, \read, \closein are always \immediate.
Yours sincerely
Heiko Oberdiek
PS: my e-mail address has changed, the old one will stop working
in near future.
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem: Beamer+xelatex+\XeTeXdefaultencoding
Hi Ross,
On Tue, Jun 22, 2010 at 09:49:26AM +1000, Ross Moore wrote:
The problem is perhaps really within LaTeX's
\IfFileExists command.
No:
\documentclass{minimal}
\XeTeXdefaultencoding UTF-8
\makeatletter
\AtBeginDocument{%
\@@input t003.out %
}
\begin{document}
\end{document}
LaTeX saves the primitive command \input in \@@input.
Output is d...@ot1m
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem: Beamer+xelatex+\XeTeXdefaultencoding
On Tue, Jun 22, 2010 at 12:24:29PM +0200, Heiko Oberdiek wrote:
\documentclass{minimal}
Now I have an even more minimal test file for iniXeTeX:
\tracinglostchars=1
\tracingcommands=2
\catcode`\{=1
\catcode`\}=2
\XeTeXdefaultencoding UTF-8
\def\document{%
\input test.aux % contents: \relax
\edef\x{\csname relax\endcsname}%
\input test.out % size: 0
}
\document
\end
xetex -etex -ini test
The text of the file test.out is relaxx , not visible in
the PDF file because there isn't a real font set, but
the .log file shows the characters.
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem: Beamer+xelatex+\XeTeXdefaultencoding
On Mon, Jun 21, 2010 at 10:01:12PM +0100, Joseph Wright wrote:
On 21/06/2010 21:34, ?? wrote:
I don't know what is happening there but the default encoding for xetex is
UTF-8 so there is no need to set the encoding.
Yes, I know.
Actually, I need cp1251 encoding, but got this problem.
This problem I reproduce with both cp1251 and UTF-8
so I try to ask about more startard encoding.
I attached all test files (source, logs, aux, ???) zipped???
See my post on the LaTeX Community website. The issue is not beamer,
but hyperref, and only shows up with Windows (LF-CR) line endings.
Minimal example for me is
\documentclass{article}
\XeTeXdefaultencoding UTF-8
\usepackage{hyperref}
\begin{document}
\end{document}
(when saved LF-CR: fine with LF-only line endings).
No, I also get @s...@act @s...@act with LF line endings.
It happens during \ReadBookmarks when the .out file
is read (this happens twice in \ReadBookmarks for XeTeX):
{\input}
\...@filef@und -t003.out
(./t003.out
{the character @}
{horizontal mode: the character @}
{blank space }
)
However the .out file is empty (size is zero).
Therefore I think it's a strange bug in XeTeX:
* @s...@act is only used in strings/macros ending in
@s...@actives, @s...@activestrue, and @s...@activesfalse.
* The problem disappears, if the .out file contains at least
one byte (space, line ending, percent).
* The problem disappears, if a \show command (\show\x, \showlists)
is inserted after the first \begingroup of \ReadBookmarks
(hxetex.def).
Yours sincerely
Heiko Oberdiek
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
