Bug 467012 - dvipdfmx needs CMap files
dvipdfmx needs CMap files
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: texlive-texmf (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-15 01:41 EDT by Takanori MATSUURA
Modified: 2013-07-02 19:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:16:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A patch for adding CMap files (1.82 KB, patch)
2008-10-15 01:41 EDT, Takanori MATSUURA
no flags Details | Diff
simple platex sample which include Japanese text (charset: ISO-2022-JP) (112 bytes, text/plain;charset=ISO-2022-JP)
2008-10-18 20:20 EDT, Takanori MATSUURA
no flags Details
increase robustness of ghostscript cmap treatment (3.50 KB, patch)
2008-10-20 08:05 EDT, Takanori MATSUURA
no flags Details | Diff
increase robustness of ghostscript cmap treatment (4.19 KB, patch)
2008-10-21 02:53 EDT, Takanori MATSUURA
no flags Details | Diff
updated texlive.2007.ls-R.diff (332 bytes, patch)
2008-10-21 02:54 EDT, Takanori MATSUURA
no flags Details | Diff
increase robustness of ghostscript cmap treatment (4.40 KB, patch)
2008-10-21 03:08 EDT, Takanori MATSUURA
no flags Details | Diff

  None (edit)
Description Takanori MATSUURA 2008-10-15 01:41:08 EDT
Created attachment 320387 [details]
A patch for adding CMap files

dvipdfmx needs CMap files for generating PDF files which includes Japanese font etc.
Comment 1 Jonathan Underwood 2008-10-18 18:33:40 EDT
I don't think that should be needed at all - in the texlive-texmf spec file we already have this:

# ghostscript cmap required for dvipdfmx
if [ -d "%{_datadir}/ghostscript/`gs --version| cut -d . -f 1-2`/Resource/CMap" ] ; then
  cmap_dir="%{_datadir}/ghostscript/"`gs --version| cut -d . -f 1-2`"/Resource/CMap/"
elif [ -d "%{_datadir}/ghostscript/Resource/CMap" ] ; then
  cmap_dir="%{_datadir}/ghostscript/Resource/CMap/"
fi
if [ z"$cmap_dir" != 'z' ]; then
  %{__sed} -i 's?^CMAPFONTS = .*?CMAPFONTS = .;$TEXMF/fonts/cmap//;'"$cmap_dir"'?' texmf/web2c/texmf.cnf
fi

What exactly is the problem that you're seeing?


[Aside: It may be that snippet should be moved to the dvipdfmx spec if *only* dvipdfmx uses those map files, and no other application does].
Comment 2 Takanori MATSUURA 2008-10-18 20:20:34 EDT
Created attachment 320776 [details]
simple platex sample which include Japanese text (charset: ISO-2022-JP)

(In reply to comment #1)
Yes, I know texlive-texmf package sets CMAPFONTS in texmf.cfg.
But it can be seen as a phenomenon.

Could you try to compile the attached file as the following?
$ platex sample.tex
$ dvipdfmx -vv sample.dvi


And you will get the following message.
<FONTMAP:pdftex.map><FONTMAP:cid-x.map>sample.dvi -> sample.pdf
DVI Comment:  TeX output 2008.10.19:0829
<AGL:pdfglyphlist.txt><AGL:glyphlist.txt>[1<cmr10@9.96pt(TFM:cmr10[/usr/share/texmf/fonts/tfm/public/cm/cmr10.tfm])
fontmap: cmr10 -> cmr10.pfb

pdf_font>> Simple font "cmr10.pfb" enc_id=<builtin,-1> opened at font_id=<cmr10,0>.
><min10@9.96pt(TFM:min10[/usr/share/texmf/fonts/tfm/ptex/min10.tfm])(VF:/usr/share/texmf/fonts/vf/ptex/min10.vf(TFM:rml[/usr/share/texmf/fonts/tfm/jp/rml.tfm])<rml@9.59pt
fontmap: rml -> Ryumin-Light(H)
(Encoding:H
** ERROR ** Could not find encoding file "H".

Output file removed.


After linking CMap files from ghostscript to /usr/share/fonts/cmap, you will get the following message.
<FONTMAP:pdftex.map><FONTMAP:cid-x.map>sample.dvi -> sample.pdf
DVI Comment:  TeX output 2008.10.19:0829
<AGL:pdfglyphlist.txt><AGL:glyphlist.txt>[1<cmr10@9.96pt(TFM:cmr10[/usr/share/texmf/fonts/tfm/public/cm/cmr10.tfm])
fontmap: cmr10 -> cmr10.pfb

pdf_font>> Simple font "cmr10.pfb" enc_id=<builtin,-1> opened at font_id=<cmr10,0>.
><min10@9.96pt(TFM:min10[/usr/share/texmf/fonts/tfm/ptex/min10.tfm])(VF:/usr/share/texmf/fonts/vf/ptex/min10.vf(TFM:rml[/usr/share/texmf/fonts/tfm/jp/rml.tfm])<rml@9.59pt
fontmap: rml -> Ryumin-Light(H)
(CMap:H)
pdf_font>> Input encoding "H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for "Ryumin-Light".
(CID:Ryumin-Light)
pdf_font>> Type0 font "Ryumin-Light" cmap_id=<H,2> opened at font_id=<rml,1>.
>)(VF)>](cmr10.pfb[CMR10][built-in][Type1][8 glyphs][1267 bytes])(CID:Ryumin-Light[Ryumin-Light][CIDFontType0])
Compression saved 149 bytes. Try "-V 5" for better compression
3192 bytes written
Comment 3 Jonathan Underwood 2008-10-19 12:35:14 EDT
Yes, the problem is that the entry in /usr/share/texmf/web2c/texmf.cnf is created at package build time, and is versioned according to the ghostscript version at install time. On my system the entry in the file is:

CMAPFONTS = .;$TEXMF/fonts/cmap//;/usr/share/ghostscript/8.62/Resource/CMap/

However, the current ghostscript package is 8.63, and so the map files are at:

/usr/share/ghostscript/8.63/Resource/CMap/

I am not sure what the best long term fix to this is, but one possibility would be:

1) The ghostscript package always creates a symlink
/usr/share/ghostscript/current/ -> /usr/share/ghostscript/8.XX

2) The entry in texmf.cnf is
CMAPFONTS = .;$TEXMF/fonts/cmap//;/usr/share/ghostscript/current/Resource/CMap/

But there may be a better fix, not sure.

Reassigning bug to texlive-texmf - Jindrich, thoughts?
Comment 4 Jonathan Underwood 2008-10-19 12:39:37 EDT
(In reply to comment #3)
> Yes, the problem is that the entry in /usr/share/texmf/web2c/texmf.cnf is
> created at package build time, and is versioned according to the ghostscript
> version at install time. On my system the entry in the file is:
             ^^^^^^^^

That should read "version at BUILD time"
Comment 5 Jonathan Underwood 2008-10-19 13:47:16 EDT
Incidentally, Takanori, in the meantime as root you can run the following command to get around this issue:

ln -s /usr/share/ghostscript/8.63 /usr/share/ghostscript/8.62
Comment 6 Takanori MATSUURA 2008-10-19 21:59:48 EDT
Thank you Jonathan,
I have confirmed to work fine with s/8.62/8.63/.


Hi Jindrich,
Can you set triggerin sciptlet in texlive-texmf?

%triggerin -- ghostscript
sed -e "s,ghostscript/[1-9].*/CMap,ghostscript/`gs --version`/CMap,g" -i %{_texmf_main}/web2c/texmf.cfg
Comment 7 Jonathan Underwood 2008-10-20 06:10:43 EDT
(In reply to comment #6)
> Thank you Jonathan,
> I have confirmed to work fine with s/8.62/8.63/.
> 
> 
> Hi Jindrich,
> Can you set triggerin sciptlet in texlive-texmf?
> 
> %triggerin -- ghostscript
> sed -e "s,ghostscript/[1-9].*/CMap,ghostscript/`gs --version`/CMap,g" -i
> %{_texmf_main}/web2c/texmf.cfg

Is this preferable to the symlink scheme I proposed above? My main worry would be fragility - if for some reason the user had hand edited that line in the texmf.cnf to add other map files, then the %triggerin may fail. I think I prefer the symlink scheme, myself.

[Note also the typo in the above scriplet: texmf.cfg should read texmf.cnf]
Comment 8 Takanori MATSUURA 2008-10-20 07:02:42 EDT
Jonathan,

Sorry for my typos.

Your idea in comment #3 requires the modification in ghostscript.
My idea in comment #6 requires the modification in texlive-texmf.

There is no positive reason that ghostscript should take care of it because other users who need ghostscript is not in trouble now. At least, I don't know. So texlive-texmf should be fixed. Usually, only one version of ghostscript is installed to /usr/share/ghostscript. So symlink to current -> x.xx is nonsense.

If users modified texmf.cnf, THEY should be responsible.

For avoiding the user unintended modification, the following is better.
sed -e "s,/usr/share/ghostscript/[1-9].*/CMap,/usr/share/ghostscript/`/usr/bin/gs --version`/CMap,g" -i %{_texmf_main}/web2c/texmf.cnf
Comment 9 Jonathan Underwood 2008-10-20 07:16:22 EDT
Yes, I can see good arguments for either solution, so I don't have a strong opinion either way. The triggerin script does seem elegant.
Comment 10 Patrice Dumas 2008-10-20 07:20:04 EDT
I'd prefer if we avoided trigger scripts, especially trigger scripts
that modify config files. It seems to me that a symlink in ghostscript
would be much better.
Comment 11 Takanori MATSUURA 2008-10-20 08:05:25 EDT
Created attachment 320866 [details]
increase robustness of ghostscript cmap treatment

(In reply to comment #10)

OK.
How about this patch?

This implementation doesn't change texmf.cnf and more robustness.
Comment 12 Jonathan Underwood 2008-10-20 09:11:03 EDT
(In reply to comment #11)
> Created an attachment (id=320866) [details]
> increase robustness of ghostscript cmap treatment
> 
> (In reply to comment #10)
> 
> OK.
> How about this patch?
> 
> This implementation doesn't change texmf.cnf and more robustness.

This looks like a good approach to me, but surely this part is made redundant by the triggerin script:

 # ghostscript cmap required for dvipdfmx
 if [ -d "%{_datadir}/ghostscript/`gs --version| cut -d . -f 1-2`/Resource/CMap" ] ; then
-  cmap_dir="%{_datadir}/ghostscript/"`gs --version| cut -d . -f 1-2`"/Resource/CMap/"
+  ln -s %{_datadir}/ghostscript/`gs --version| cut -d . -f 1-2`/Resource/CMap texmf/fonts/cmap/ghostscript
 elif [ -d "%{_datadir}/ghostscript/Resource/CMap" ] ; then
-  cmap_dir="%{_datadir}/ghostscript/Resource/CMap/"
-fi
-if [ z"$cmap_dir" != 'z' ]; then
-  %{__sed} -i 's?^CMAPFONTS = .*?CMAPFONTS = .;$TEXMF/fonts/cmap//;'"$cmap_dir"'?' texmf/web2c/texmf.cnf
+  ln -s %{_datadir}/ghostscript/Resource/CMap texmf/fonts/cmap/ghostscript
 fi


Couldn't that whole section be removed?
Comment 13 Takanori MATSUURA 2008-10-20 09:42:30 EDT
(In reply to comment #12)
> Couldn't that whole section be removed?

It's required because %{texmf_main}/fonts/cmap/ghostscript should be owned by texlive-texmf-fonts.
For this purpose, the following command may be enough.

# ghostscript cmap required for dvipdfmx
touch texmf/fonts/cmap/ghostscript
Comment 14 Jonathan Underwood 2008-10-20 09:51:28 EDT
(In reply to comment #13)
> (In reply to comment #12)
> > Couldn't that whole section be removed?
> 
> It's required because %{texmf_main}/fonts/cmap/ghostscript should be owned by
> texlive-texmf-fonts.
> For this purpose, the following command may be enough.
> 
> # ghostscript cmap required for dvipdfmx
> touch texmf/fonts/cmap/ghostscript

Yes, exactly, or use %ghost.
Comment 15 Takanori MATSUURA 2008-10-21 02:53:11 EDT
Created attachment 320985 [details]
increase robustness of ghostscript cmap treatment

(In reply to comment #14)
> Yes, exactly, or use %ghost.

updated my patch for texlive-texmf.spec.
%ghost requires dummy file generated by touch etc. in package building stage.
Comment 16 Takanori MATSUURA 2008-10-21 02:54:48 EDT
Created attachment 320986 [details]
updated texlive.2007.ls-R.diff
Comment 17 Takanori MATSUURA 2008-10-21 03:08:04 EDT
Created attachment 320987 [details]
increase robustness of ghostscript cmap treatment

Oops.
triggerin scriplet runs after post scriplet.
Comment 18 Bug Zapper 2009-06-09 22:58:11 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2009-07-14 10:16:47 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.