Re: [XeTeX] XeTeX release notes ?

[Hironobu Yamashita]

Hi Phil,

I guess the change in TeX Live svn r44964:
https://www.tug.org/svn/texlive?view=revision=44964
along with xdvipdfmx change in r44963:
https://www.tug.org/svn/texlive?view=revision=44963
started to support /Rotate in PDF inclusion.

According to the ChangeLog,
this change was done between 0.8 and 0.9.

Best,
Hironobu

2019-11-04 1:27 GMT+09:00, Taylor, P :
> Could anyone please tell me where I may find the release notes for XeTeX ?
> I ask because the behaviour of \XeTeXpdffile changed somewhere between
> \XeTeXrevision = 0.6 and \XeTeXrevision = 0.9 (see code fragment
> below) and I would like to ensure that my code behaviour is correct for
> intermediate versions.
>
> Philip Taylor
> 
> \def \menus
> {%
> \begingroup
> \def \menufile { "Appendix D/Appendix-D.pdf" }%
> \def \doit
> {%
> \setbox 0 = \hbox {\XeTeXpdffile \menufile page \count 0
> \transformed}%
> \sb 0
> }%
> \count 0 = 1
> \loop
> \ifnum \count 0 = 10
> \ifdim \XeTeXrevision pt < 0.9pt
> \def \transformed {  width \vsize height \hsize rotated
> 90}%
> \else
> \def \transformed {  width \hsize height \vsize}%
> \fi
> \else
> \def \transformed {  width \hsize height \vsize}%
> \fi
> \doit
> \ifnum \count 0  < \XeTeXpdfpagecount \menufile
> \advance \count 0 by 1
> \repeat
> \endgroup
> }
>


-- 

山下 弘展 (Hironobu Yamashita)
e-mail: h.y.acetaminop...@gmail.com

[XeTeX] e-TeX \lastnodetype initialization problem

[Hironobu Yamashita]

Hi,

e-TeX primitive \lastnodetype is not working as documented at the start of 
programs
on WEB2C implementation of pdfTeX, XeTeX and e-pTeX/e-upTeX.
(Only LuaTeX is ok.)
When the current list is empty, \lastnodetype should return -1 instead of 0.

%#!pdftex
\tracingonline1
\showthe\lastnodetype % => 0 ??
\showlists % => empty
\bye


Hironori Kitagawa found the following issue:

etexdir/etex.ch modifies `@` by

@x [45] m.991 l.19353 - e-TeX last_node_type
last_glue:=max_halfword; last_penalty:=0; last_kern:=0;
@y
last_glue:=max_halfword; last_penalty:=0; last_kern:=0;
last_node_type:=-1;
@z

However, tex.ch (WEB2C change file) overrides it so the change has no effect;

@x [16.215] l.4344 - remove mem[] reference from initialize.
prev_graf:=0; shown_mode:=0;
@;
@y
prev_graf:=0; shown_mode:=0;
@/{The following piece of code is a copy of module 991:}
page_contents:=empty; page_tail:=page_head; {|link(page_head):=null;|}@/
last_glue:=max_halfword; last_penalty:=0; last_kern:=0;
page_depth:=0; page_max_depth:=0;
@z

A patch for
* etexdir/tex.ech
* pdftexdir/pdftex.ch
* xetexdir/xetex.ch
is attached.

Best regards,
Hironobu Yamashita



20180323-etex_init_lastnodetype.patch
Description: Binary data




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

Re: [XeTeX] error: can't allocate region with xelatex

[Hironobu Yamashita]

2017-02-01 13:59 GMT+09:00 Akira Kakuto <kak...@fuk.kindai.ac.jp>:
>
> In r43113 in TeX Live SVN, I have changed texmfmp.c a little:
>
> in order to avoid the crash. The change must not give bad effects.
> It is not a fix but a stopgap for the problem.
>

I confirmed the fix after rebuild. Thank you.


2017-02-01 23:18 GMT+09:00 Philip Taylor <p.tay...@rhul.ac.uk>:
>
>> $ echo x | xelatex \\showthe\\everyjob
>
> I was able to replicate it under TeX Live 2016 but only after de-duplicating 
> the back-slashes.
>

You are right. On windows a back-slash don't need to be escaped.
The MWE I posted was for my Mac OS ;-)

Hironobu Yamashita


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

[XeTeX] error: can't allocate region with xelatex

[Hironobu Yamashita]

Hello,

I encountered the following situation with xelatex.

$ echo x | xelatex \\showthe\\everyjob

This is XeTeX, Version 3.14159265-2.6-0.6 (TeX Live 2016)
(preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
LaTeX2e <2017/01/01> patch level 1
Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.
> \typeout {\fmtname \space <\fmtversion > patch level \patch@level }\typeout {
Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.}.
<*> \showthe\everyjob

? xelatex(45131) malloc: *** mmap(size=18446744073636376576) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
fatal: memory exhausted (xmalloc of 18446744073636373502 bytes).
No pages of output.

I also tested with the latest TeX Live svn (2017/dev), and
it gave the same result. On Windows, the message
"xelatex.exe has stopped working" appeared.

I'm not sure if this is really a problem, but just in case...

Regards,
Hironobu Yamashita


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

Re: [XeTeX] Support request for /Rotate in pdf

[Hironobu Yamashita]

Dear Andreas,

> With help of -shell-escape I think this can be done in a
> graphicx driver:

Thank you for the good suggestion. But pdfinfo can be found both
in poppler and xpdf, and the outputs are different from each
other; thus parsing info file would be difficult.

And now I've come up with another macro-based workaround.
I can use rungs for "pre-treatment" when -shell-escape is allowed:

 \immediate\write18{rungs -sDEVICE=pdfwrite -dBATCH -dNOPAUSE
 -dAutoRotatePages=/None -sOutputFile=\basename-pdf-rotated-to.pdf
 -c .setpdfwrite -f \basename.pdf}

This will convert \basename.pdf to \basename-pdf-rotate-to.pdf.
Then I can include \basename-pdf-rotate-to.pdf without worrying
about /Rotate parameter. Of course this could be done in the driver
file without notice and interaction of the user.

The disadvantage of method above can be:
- slow conversion process
- shell-escape required
- dependency on macros (LaTeX, plain TeX, etc)
Some of these problems may be reduced by running rungs only when
/Rotate really exists in the pdf. Fortunately, extractbb can
examine the value of /Rotate; this may help reducing run of rungs.

However, it would be more helpful if /Rotate is supported in XeTeX
and xdvipdfmx natively. If not, is there any chance of adding rungs
to shell_escape_commands list? Any suggestions are appreciated.

Thanks,
Hironobu


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

Re: [XeTeX] Support request for /Rotate in pdf

[Hironobu Yamashita]

> > If not, is there any chance of adding rungs
> > to shell_escape_commands list?
> 
> I think there is no chance.

I understand. Thank you Akira-san.

Regards,
Hironobu

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

Re: [XeTeX] Support request for /Rotate in pdf

[Hironobu Yamashita]

Dear Zdenek,

> There are official guidelines how to insert EPS, I do
> not know whether such guidelines exist for inclusion
> of PDF. If so, the guidelines should be followed.
Yes, I agree. That's the most important thing to be
considered. But unfortunately I don't know where I
could find such guidelines for pdf either.

Dear Philip,

> For a "normal" user, the simplest way to rotate a PDF
> is to open it in Adobe Acrobat, ask the latter to
> "Document / rotate pages", select the appropriate
> options and then save the modified file under a new
> name.
I think so, and many "normal" users behind this list will
agree with you.

And if there are no official guidelines for inclusion of PDF,
one has to "set a standard"; and pdfTeX has already done:
pdfTeX can be regarded as having  determined "how TeX-
related programs should behave when pdf figure inclusion".

Currently pdfTeX and XeTeX behave in different way, which
is confusing. PdfTeX's behavior is easy to understand for
"normal" users, so XeTeX will become more user-friendly
if it follows the pdfTeX "standard".

Another important perspective is the possibility of /Rotate
support. When it comes to supporting /Rotate, there seems
to be a great technical difficulty as Zdenek notes, right?
> the difference is that pdftex does everything in one step,
> xetex prepares a \special for xdvipdfmx. In order to
> implement /Rotate you have to read the page directory ...
Is there any chance for XeTeX and xdvipdfmx to overcome
the difficulty?

Thank you in advance.
Hironobu

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

Re: [XeTeX] [tex-live] -dAutoRotatePages=/None in the distiller_template

[Hironobu Yamashita]

Dear Reinhard,

> Dear Hironobu,
> what do you want to rotate?  An included graphic file or the whole
> document?

> Hironobu, can you tell my why xdvipdfmx has to understand /Rotate?

I meant:
"User-intended pdf figure rotation" is suppressed in xdvipdfmx.
That's a big problem.

> And I'm convinced that /Rotate (with uppercase "R") should be avoided
> because it's not mentioned in the "PostScript language reference",
> third edition, ISBN 0-201-37922-8.  PostScript is an excellent
> programming language, if there were not these annoying Adobe TechNotes.

No, I didn't mean PostScript /rotate but PDF /Rotate. It's natural
that /Rotate (uppercase) does not appear in PostScript Teference,
but it appears in PDF Reference. Many pdf utilities (adobe acrobat,
preview.app, pdftk, etc.) insert /Rotate, and many viewers understand it.

pdfTeX and LuaTeX can understand /Rotate, based on PDF Reference.
Rotating pdf figures is the only correct way of understanding /Rotate.
Current XeTeX and xdvipdfmx simply ignores it.

> Well, at TeX level there is no need to *read* a PDF file, you just
> have to tell what you intend.  Rotating an included graphic file (for
> instance by \includegraphics in LaTeX) means to change the
> transformation matrix first, insert the graphic file, and finally
> restore the matrix.  You have to know the size of the graphic, of
> course.  If you rotate something counterclockwise by 90 degrees, all
> x-coordinates become negative and you have to shift the graphic to the
> right by its height (before rotation) or its width (after rotation).

Of course I know, and pdfTeX and LuaTeX are doing exactly the same
thing as you are saying. They understand /Rotate in PDF correctly.
I wonder why XeTeX does not.

-
Hironobu


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

Re: [XeTeX] [tex-live] -dAutoRotatePages=/None in the distiller_template

[Hironobu Yamashita]

> ... It would seem, from what Hironobu-san
> has said, that neither XeTeX not (x)dvipdfm(x) support the /rotate (or
> /Rotate) primitive that Adobe Acrobat inserts when one asks it to rotate
> a PDF ...
> 
> ** Phil.

That's right. And it's not only Adobe Acrobat that inserts /Rotate (uppercase)
in PDF rotation: for example,
pdftk in.pdf cat 1-endsouth output out.pdf
inserts /Rotate 90. Mac OS X Preview.app is similar.

When pdf tool developers implement pdf rotation, addition of /Rotate may
be the easiest way: there is no need to interpret pdf completely! And also
it is reasonable that users choose rotating pdf before including it into TeX,
therefore insertion of /Rotate occurs frequently.
Most of pdf viewers can understand /Rotate, so they show pdf in proper
orientation. However, current XeTeX and xdvipdfmx cannot understand
/Rotate in pdf. This is the problem.

Hironobu


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

Re: [XeTeX] [tex-live] -dAutoRotatePages=/None in the distiller_template

[Hironobu YAMASHITA]

> But that is probably a question for the XeTeX list, and not relevant to
> the TeX Live discussion here.
I agree. (removed tex-live list from recipient)

Hmm, actually I'm not very familiar with XeTeX, but at least I can say
that pdf is read by both XeTeX and xdvipdfmx independently.

As far as I guess,
Currently XeTeX engine completely ignores /Rotate command in pdf, so
resulting bbox values are the same as original bbox (rotation not
applied). XeTeX produces intermediate file xdv (usually invisible),
and xdvipdfmx reads it. At this point xdvipdfmx again reads pdf, finds
/Rotate and shows warning.

>From this point,
> What is odd is that it clearly has the ability to cause a figure to be
> rotated, yet it does not look inside the PDF to see if it contains
> /Rotate and then take appropriate action,
XeTeX ignores /Rotate; xdvipdfmx ignores /Rotate too.
This behavior reserves consistency (though unexpected for us).

I
​think
 this
​may be
 some kind of faq in SX:
http://tex.stackexchange.com/questions/79661/pdfs-included-by-xelatex-are-rotated
http://tex.stackexchange.com/questions/66522/xelatex-rotating-my-figures-in-beamer
I hope some expert of XeTeX can answer more clearly.

​Hironobu​


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

Re: [XeTeX] [tex-live] -dAutoRotatePages=/None in the distiller_template

[Hironobu YAMASHITA]

Hi Philip,

2015-11-05 14:03 GMT+09:00 Philip Taylor :

> I don't understand the details of this at all, Akira-san, but would it
> explain why, after I had carefully rotated a PDF figure by 90% in Adobe
> Acrobat, I found that that the rotation was lost when that same
> (rotated) figure was imported using XeTeX's \XeTeXpdffile ?
>

Akira's suggestion is not related to pdf inclusion of dvipdfmx / xdvipdfmx.
(Note that XeTeX's output-driver is xdvipdfmx!)
The addition of -dAutoRotatePages=/None in dvipdfmx.cfg is only for
inclusion
of eps figures: in this case (x)dvipdfmx calls gs to convert eps --> pdf.

Philip's problem is pdf inclusion. Current (x)dvipdfmx does not support
/Rotate at all, so inclusion of pdf with /Rotate command fails.
Yes, Adobe Acrobat (and Preview.app in OS X) adds /Rotate command in PDF
rotation, so these PDFs are out-of-support by (x)dvipdfmx.
​The possible workaround is, as I said previously, 'pretreatment' of
rotated PDFs.
(sorry, in my previous mail there are some miss-spelling in
-dAutoRotatePages)

Hironobu​


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