[XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
Hi Khaled, Jiang, I found that r34804 of dvipdfmx could not create a pdf for a simple vertical text by using SourceHanSansJP, while r34711 of dvipdfmx could create a fine pdf for the same text. I attach a file dvipdfmx-test.tar.gz which contains (1) UniSourceHanSansJP-UTF16-H (2) UniSourceHanSansJP-UTF16-V (3) r34711-message.txt (4) r34804-message.txt (5) sample.dvi (6) sample.pdf (7) sample.tex (8) test.map (1),(2): CMap files written by Y. Terada (3): message by r34711 for dvipdfmx -f test.map sample (4): message by r34804 for dvipdfmx -f test.map sample (5): a dvi file made by uplatex sample (6): a pdf file created by r34711, which is fine. (7): a source file (8): a map file for the test Thanks, Akira dvipdfmx-test.tar.gz Description: GNU Zip compressed data -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
On Sun, Aug 3, 2014 at 11:26 AM, Akira Kakuto kak...@fuk.kindai.ac.jp wrote: Hi Khaled, Jiang, I found that r34804 of dvipdfmx could not create a pdf for a simple vertical text by using SourceHanSansJP, while r34711 of dvipdfmx could create a fine pdf for the same text. I attach a file dvipdfmx-test.tar.gz which contains (1) UniSourceHanSansJP-UTF16-H (2) UniSourceHanSansJP-UTF16-V (3) r34711-message.txt (4) r34804-message.txt (5) sample.dvi (6) sample.pdf (7) sample.tex (8) test.map (1),(2): CMap files written by Y. Terada (3): message by r34711 for dvipdfmx -f test.map sample (4): message by r34804 for dvipdfmx -f test.map sample (5): a dvi file made by uplatex sample (6): a pdf file created by r34711, which is fine. (7): a source file (8): a map file for the test OK, I vaguely remembered that I added vertical support to XeTeX and xdvipdfmx with help from JK several years ago, that might have regressed during the XETEX code removal. I can take a look. - Jiang -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
On Sun, Aug 3, 2014 at 11:28 AM, Jiang Jiang gzjj...@gmail.com wrote: On Sun, Aug 3, 2014 at 11:26 AM, Akira Kakuto kak...@fuk.kindai.ac.jp wrote: Hi Khaled, Jiang, I found that r34804 of dvipdfmx could not create a pdf for a simple vertical text by using SourceHanSansJP, while r34711 of dvipdfmx could create a fine pdf for the same text. Oh, for dvipdfmx it might be for a totally different reason, I can still do a bisect though. - Jiang -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
On Sun, Aug 3, 2014 at 11:55 AM, Jiang Jiang gzjj...@gmail.com wrote: Hi, On Sun, Aug 3, 2014 at 11:36 AM, Jiang Jiang gzjj...@gmail.com wrote: On Sun, Aug 3, 2014 at 11:28 AM, Jiang Jiang gzjj...@gmail.com wrote: On Sun, Aug 3, 2014 at 11:26 AM, Akira Kakuto kak...@fuk.kindai.ac.jp wrote: Hi Khaled, Jiang, I found that r34804 of dvipdfmx could not create a pdf for a simple vertical text by using SourceHanSansJP, while r34711 of dvipdfmx could create a fine pdf for the same text. Oh, for dvipdfmx it might be for a totally different reason, I can still do a bisect though. bisect shows that r34757 is the culprit. be060316813525c1243951a1612500aa85c830bf is the first bad commit commit be060316813525c1243951a1612500aa85c830bf Author: hosny hosny@c570f23f-e606-0410-a88d-b1316a301751 Date: Mon Jul 28 16:27:05 2014 + Support getting glyph names from OpenType/CFF fonts git-svn-id: svn://tug.org/texlive/trunk/Build/source@34757 c570f23f-e606-0410-a88d-b1316a301751 Possible fix: https://gist.github.com/jjgod/88bb45f2cc7711bf3fd0 - Jiang -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
Hi Jiang, I have committed a better fix as r34805. Thanks a lot, Jiang. It works fine for the example. Thanks, Akira -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
On Sun, Aug 3, 2014 at 3:59 PM, Akira Kakuto kak...@fuk.kindai.ac.jp wrote: Hi Jiang, I have committed a better fix as r34805. Thanks a lot, Jiang. It works fine for the example. Anyone feel like trying out the following patches? https://gist.github.com/jjgod/0d4b6339d761a5423f82 Patch 1 will fix the ToUnicode generation for all non-subst glyphs in a non-XeTeX generated dvi. In our case, non-subst glyphs are the glyphs that are *NOT* changed by applying OpenType vertical layout features. To fix this I merely applied the same strategy I used to fix XeTeX generated PDF documents. It's a small change and should be safe to commit. In patch 2 I tried out a more interesting approach and it supersedes the efforts in patch 1: this patch utilize the cmap we provided in the map file to do CID - Unicode lookup. In your test case the cmap is UniSourceHanSansJP-UTF16-V. To do this reverse lookup I have to extend CMap structure a little bit to store reverse mapping information, with that it's quite easy to simply generate ToUnicode stream with all used cids. The commit message has more details. Since these patches are relatively experimental I'm hesitate to commit them right away, would be nice if any of you can try it out or review them. With my limited testing it doesn't show any problem and we can produce perfectly copyable PDF from the sample.dvi in this test case. - Jiang -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On Aug 3, 2014, at 6:27 PM, Gildas Hamel gwel...@ucsc.edu wrote:
% !TEX TS-program = xelatexmk
% !TEX encoding = UTF-8 Unicode
\documentclass[12pt]{article}
\usepackage{fontspec}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}
\lipsum
\begin{figure}[h]
\includegraphics[scale=0.25]{tombe.jpg}
\caption{Tombe}
\end{figure}
\end{document}
Howdy,
Note: this compiles fine with pdflatex. It appears to either be a scaling
problem involving xelatex and/or xdvpdfmx.
Good Luck,
Herb Schulz
(herbs at wideopenwest dot com)
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
Hi Jiang,
Anyone feel like trying out the following patches?
https://gist.github.com/jjgod/0d4b6339d761a5423f82
Patch 1 will fix the ToUnicode generation for all non-subst glyphs in
a non-XeTeX generated dvi. In our case, non-subst glyphs are the
glyphs that are *NOT* changed by applying OpenType vertical layout
features. To fix this I merely applied the same strategy I used to fix
XeTeX generated PDF documents. It's a small change and should be safe
to commit.
In patch 2 I tried out a more interesting approach and it supersedes
the efforts in patch 1: this patch utilize the cmap we provided in the
map file to do CID - Unicode lookup. In your test case the cmap is
UniSourceHanSansJP-UTF16-V.
To do this reverse lookup I have to extend CMap structure a little bit
to store reverse mapping information, with that it's quite easy to
simply generate ToUnicode stream with all used cids. The commit
message has more details.
Since these patches are relatively experimental I'm hesitate to commit
them right away, would be nice if any of you can try it out or review
them. With my limited testing it doesn't show any problem and we can
produce perfectly copyable PDF from the sample.dvi in this test case.
Hi Jiang,
Please commit both of patch1 and patch2!! I think that is great.
Users of W32TeX know that it is always experimental.
BTW, there is late declaration of a variable in c99
around line 1123 in tt_cmap.c:
for (j = 0; j 8; j++) {
unsigned int cid;
gid = 8 * i + j;
if (!is_used_char2(used_glyphs, gid))
continue;
cid = cff_charsets_lookup_inverse(cffont, gid);
int ch = CMap_reverse_decode(cmap_loaded, cid);
---
for (j = 0; j 8; j++) {
unsigned int cid;
int ch;
gid = 8 * i + j;
if (!is_used_char2(used_glyphs, gid))
continue;
cid = cff_charsets_lookup_inverse(cffont, gid);
ch = CMap_reverse_decode(cmap_loaded, cid);
Thanks,
Akira
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On 4 Aug 2014, at 00:48, Herbert Schulz he...@wideopenwest.com wrote:
On Aug 3, 2014, at 6:27 PM, Gildas Hamel gwel...@ucsc.edu wrote:
% !TEX TS-program = xelatexmk
% !TEX encoding = UTF-8 Unicode
\documentclass[12pt]{article}
\usepackage{fontspec}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}
\lipsum
\begin{figure}[h]
\includegraphics[scale=0.25]{tombe.jpg}
\caption{Tombe}
\end{figure}
\end{document}
Howdy,
Note: this compiles fine with pdflatex. It appears to either be a scaling
problem involving xelatex and/or xdvpdfmx.
Good Luck,
Herb Schulz
(herbs at wideopenwest dot com)
I can reproduce your overlap. I had something like this happen to me once. It
was a corrupt jpg. So I pushed your tombe.jpg through GraphicConverter (Mac OS
X) making it 1 pixel narrower and it now scales properly and does not overlap
the text. I think I'm using pdflatex too.
(whatever comes out of the box with 2014 and Auctex))
I guess it would be interesting to discover why XeTeX thought it was corrupt,
since GraphicConverter was fine with it.
Elliott Roper
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] r34804 fails to typeset a vertical Japanese, for which r34711 works fine
Hi Jiang , I have committed a better fix as r34805. Thanks a lot, Jiang. It works fine for the example. However, unfortunately, invalid toUnicode problem for non-CJK fonts, fixed by Khaled, has reappeared. I attach a sample.tex. Thanks, Akira sample.tex Description: Binary data -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On Aug 3, 2014, at 17:48, Elliott Roper elli...@yrl.co.uk wrote:
On 4 Aug 2014, at 00:48, Herbert Schulz he...@wideopenwest.com wrote:
On Aug 3, 2014, at 6:27 PM, Gildas Hamel gwel...@ucsc.edu wrote:
% !TEX TS-program = xelatexmk
% !TEX encoding = UTF-8 Unicode
\documentclass[12pt]{article}
\usepackage{fontspec}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}
\lipsum
\begin{figure}[h]
\includegraphics[scale=0.25]{tombe.jpg}
\caption{Tombe}
\end{figure}
\end{document}
Howdy,
Note: this compiles fine with pdflatex. It appears to either be a scaling
problem involving xelatex and/or xdvpdfmx.
Good Luck,
Herb Schulz
(herbs at wideopenwest dot com)
I can reproduce your overlap. I had something like this happen to me once. It
was a corrupt jpg. So I pushed your tombe.jpg through GraphicConverter (Mac
OS X) making it 1 pixel narrower and it now scales properly and does not
overlap the text. I think I'm using pdflatex too.
(whatever comes out of the box with 2014 and Auctex))
I guess it would be interesting to discover why XeTeX thought it was corrupt,
since GraphicConverter was fine with it.
Elliott Roper
I tested with a number of jpg images, a bit at random. They all scale as
expected with pdftex and fail to scale for every photo with xelatex.
I use Lyn to manage photos (i.e. folder management, no editing of photos),
could that be a problem?
—Gildas
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] jpg image and text overlapping
On Aug 3, 2014, at 17:48, Elliott Roper elli...@yrl.co.uk wrote:
On 4 Aug 2014, at 00:48, Herbert Schulz he...@wideopenwest.com wrote:
On Aug 3, 2014, at 6:27 PM, Gildas Hamel gwel...@ucsc.edu wrote:
% !TEX TS-program = xelatexmk
% !TEX encoding = UTF-8 Unicode
\documentclass[12pt]{article}
\usepackage{fontspec}
\usepackage{lipsum}
\usepackage{graphicx}
\begin{document}
\lipsum
\begin{figure}[h]
\includegraphics[scale=0.25]{tombe.jpg}
\caption{Tombe}
\end{figure}
\end{document}
Howdy,
Note: this compiles fine with pdflatex. It appears to either be a scaling
problem involving xelatex and/or xdvpdfmx.
Good Luck,
Herb Schulz
(herbs at wideopenwest dot com)
I can reproduce your overlap. I had something like this happen to me once. It
was a corrupt jpg. So I pushed your tombe.jpg through GraphicConverter (Mac
OS X) making it 1 pixel narrower and it now scales properly and does not
overlap the text. I think I'm using pdflatex too.
(whatever comes out of the box with 2014 and Auctex))
I guess it would be interesting to discover why XeTeX thought it was corrupt,
since GraphicConverter was fine with it.
Elliott Roper
Further testing of my photos: many of my photos have a 300dpi resolution. Those
with 72dpi work fine with xelatex and pdftex. Photos with 300dpi resolution
scale only in pdftex.
—Gildas
--
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
