Created attachment 320387 [details] A patch for adding CMap files dvipdfmx needs CMap files for generating PDF files which includes Japanese font etc.
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].
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(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(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 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(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(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 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
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?
(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"
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
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
(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]
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
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.
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.
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.
(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?
(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
(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.
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.
Created attachment 320986 [details] updated texlive.2007.ls-R.diff
Created attachment 320987 [details] increase robustness of ghostscript cmap treatment Oops. triggerin scriplet runs after post scriplet.
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
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.