Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
Hi, I've told the dvipdfmx people, that some programs from dvipdfm are missing, like ebb. I didn't got an answer until now: i.e. if it will be implemented or if it is available as dvipdfmx command line switch or else. I am confident that ebb doesn't need any special ebbx treatment - it just looks at JPEG, PNG, and PDF files and extracts the bounding box. I'm using ebb with dvipdfmx without problems. It's just a program to tell bounding box information in tex-dvi phase, not much restricted to dvi-pdf conversion, right? regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
A Lee [EMAIL PROTECTED] wrote: If updmap-sys is used to for such fonts, it MUST NOT modify the map file of dvipdfm because dvipdfmx also read it. Therefore it would make things much easier if upstream (i.e. the TeXlive people and Thomas Esser) would decide to drop the unmaintained dvipdfm completely and use dvipdfmx instead. As far as i know dvips and ps2pk does not support truetype font. If it is true, updmap-sys must not modify their map files, either. I don't understand this - it of course does modify, or rather create, map files for dvips and ps2pk. It just doesn't include information how to create slanted versions etc., and it must not change this behavior. I guess you simply can't use these fonts with dvips - or is there an other trick? Furthermore, some fonts like Adobe's OTFs included in acroread are supported by only dvipdfmx. In this case, updmap-sys must not touch fontmap files for all the other programs. I think using updmap-sys for dvipdfmx is not a good idea. I don't understand why you think that. The whole point of updmap is that there should be one central place for font configuration (updmap.cfg, in Debian a generated file), and one program that knows about the syntax of the map files for all TeX-related programs, and created the correct map file for each. AFAIK, it currently includes the all fonts in all generated map files, but it already drops some information about a particular font if it is not needed and/or understood by the target program. Why not simply extend this behavior to not include lines for fonts that have this how-to-generate-slanted feature, or instead to keep only the information for the base font? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
On 07.02.06 Frank Küster ([EMAIL PROTECTED]) wrote: A Lee [EMAIL PROTECTED] wrote: Hi, If updmap-sys is used to for such fonts, it MUST NOT modify the map file of dvipdfm because dvipdfmx also read it. Therefore it would make things much easier if upstream (i.e. the TeXlive people and Thomas Esser) would decide to drop the unmaintained dvipdfm completely and use dvipdfmx instead. I've told the dvipdfmx people, that some programs from dvipdfm are missing, like ebb. I didn't got an answer until now: i.e. if it will be implemented or if it is available as dvipdfmx command line switch or else. H. -- If we spoke a different language, we would perceive a somewhat different world. -- Wittgenstein http://www.hilmar-preusse.de.vu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
Hilmar Preusse [EMAIL PROTECTED] wrote: On 07.02.06 Frank Küster ([EMAIL PROTECTED]) wrote: A Lee [EMAIL PROTECTED] wrote: Hi, If updmap-sys is used to for such fonts, it MUST NOT modify the map file of dvipdfm because dvipdfmx also read it. Therefore it would make things much easier if upstream (i.e. the TeXlive people and Thomas Esser) would decide to drop the unmaintained dvipdfm completely and use dvipdfmx instead. I've told the dvipdfmx people, that some programs from dvipdfm are missing, like ebb. I didn't got an answer until now: i.e. if it will be implemented or if it is available as dvipdfmx command line switch or else. I am confident that ebb doesn't need any special ebbx treatment - it just looks at JPEG, PNG, and PDF files and extracts the bounding box. I would be surprised if it wouldn't simply be possible to take ebb.c and its Makefile.in snippets and put them into dvipdfmx. If dvipdfmx upstream are reluctant to do this, it might be because they don't need and use it. AFAIK, there are other programs to do this (one from context?). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
Frank Küster wrote: Why not simply extend this behavior to not include lines for fonts that have this how-to-generate-slanted feature, or instead to keep only the information for the base font? I thought updmap supports the different slanting syntax of different drivers, but this seems not to be the case. I have to investigate this further and will open a separate bug against tetex-bin. Anyway, I don't think that how to artificially slant fonts is the real issue here. IMHO the main problem is that updmap is Type1 centric. Let's review what updmap does: Based on a central configuration file it creates map files for different applications, taking care of the different syntax understood by those programs. It can do a number of useful things here. Switch between Metafont and Type1 fonts for dvips, change downloading of Base35 and Base14 fonts, and the naming of the Base35 fonts. All this is nice and well, but it is difficult to extend it to present needs. Nowadays, we have not only Type1 fonts but also TrueType and OpenType fonts. Different applications have different levels of support for these formats. For example, pdftex and dvipdfmx can use TTFs directly, with dvips one has to jump through one of several possible hoops (ttf2pk, Type42, ttf2pt1, let ps2pdf do the font embedding). Incorporating such things into updmap is difficult. IMHO the right approach would be to let updmap configure the different base fonts etc, which it does very well. For other font packages, pdftex shows the right way with its \pdfmapfile primitive. The style file used for loading the font would not only change things like \rmdefault, but would also load the appropriate map file using ifpdf.sty and suitable options. Of course, dvips, dvipdfmx etc would have to be extended to support some sort of 'map file special', but that should be doable. Of course, all this is way beyond the scope of Debian packaging. cheerio ralf
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
Ralf Stubner [EMAIL PROTECTED] wrote: Of course, all this is way beyond the scope of Debian packaging. Which is why I suggested in my first post to bring together dvipdfmx and texlive (i.e. updmap's) upstream developers. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
Junichi Uekawa [EMAIL PROTECTED] wrote: The ideal situation is: 1. updmap-sys should handle dvipdfmx map files (can't it do that? I need confirmation on this) It has no special treatment for dvipdfmx, and therefore it cannot handle the entries with @ properly. We would need a different output file for dvipdfmx and a special treatment of these entries, which may not end up in pdftex's or dvips' font map files. On the other hand, it has been discussed whether texlive and teTeX should drop dvipdfm completely in favor of dvipdfmx. In this case the change to updmap would be a little easier. 2. have a directory of configuration files that dvipdfmx can read. (doesn't it already do that? need to check) 3. or failing that, implement update-dvipdfmx, which does something similar to what ptex-jisfonts is trying to do. It should probably write to /var/lib/ rather than /etc/texmf/dvipdfm/ I think the best approach would be to bring together the dvipdfmx and texlive developers, and implement a general solution that can be used independently of Debian. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
1. updmap-sys should handle dvipdfmx map files (can't it do that? I need confirmation on this) It has no special treatment for dvipdfmx, and therefore it cannot handle the entries with @ properly. We would need a different output file for dvipdfmx and a special treatment of these entries, which may not end up in pdftex's or dvips' font map files. In theory, we don't need to add fontmap entries for dvipdfmx because dvipdfmx also read dvipdfm's map file. The problem is CJK truetype fonts. Most of them does not contain oblique or slanted (sometimes also bold) glyphs, and therefore dvipdfmx and ttf2pk use special symbols on their map file to know how to generate oblique/slanted letters from normal font. The map files can't be generated automatically because the best-looking slanted angles are different for each font. Therefore the upstream font package's author usually provides the individual map files for pdftex, ttf2pk and dvipdfmx with the font. If updmap-sys is used to for such fonts, it MUST NOT modify the map file of dvipdfm because dvipdfmx also read it. As far as i know dvips and ps2pk does not support truetype font. If it is true, updmap-sys must not modify their map files, either. Furthermore, some fonts like Adobe's OTFs included in acroread are supported by only dvipdfmx. In this case, updmap-sys must not touch fontmap files for all the other programs. I think using updmap-sys for dvipdfmx is not a good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
Package: dvipdfmx Version: 1:20050831-0.2 Hi, I'm opening a fresh bugreport. I'd like to discuss how to properly implement support for multiple map files with dvipdfmx. Current situation is : 1. dvipdfmx provides cid-x.map file containing most of the basic info 2. if other packages want to add new fonts to dvipdfmx, it writes to /etc/texmf/dvipdfm/fontmapsx file, which is not under dpkg control. (cf. ptex-jisfonts implementation.) The ideal situation is: 1. updmap-sys should handle dvipdfmx map files (can't it do that? I need confirmation on this) 2. have a directory of configuration files that dvipdfmx can read. (doesn't it already do that? need to check) 3. or failing that, implement update-dvipdfmx, which does something similar to what ptex-jisfonts is trying to do. It should probably write to /var/lib/ rather than /etc/texmf/dvipdfm/ regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
On Sun, Feb 05, 2006 at 11:31:28PM +0900, Junichi Uekawa wrote: Package: dvipdfmx Version: 1:20050831-0.2 Hi, I'm opening a fresh bugreport. I'd like to discuss how to properly implement support for multiple map files with dvipdfmx. Current situation is : 1. dvipdfmx provides cid-x.map file containing most of the basic info 2. if other packages want to add new fonts to dvipdfmx, it writes to /etc/texmf/dvipdfm/fontmapsx file, which is not under dpkg control. (cf. ptex-jisfonts implementation.) The ideal situation is: 1. updmap-sys should handle dvipdfmx map files (can't it do that? I need confirmation on this) updmap-sys add configurations to dvips, pdftex, xdvi, ps2pk, gsftopk and dvipdfm at a time. But most of them does not support CJK TrueType font. The current version of updmap-sys can't handle dvipdfmx's map file. 2. have a directory of configuration files that dvipdfmx can read. (doesn't it already do that? need to check) No. It doesn't yet. 3. or failing that, implement update-dvipdfmx, which does something similar to what ptex-jisfonts is trying to do. It should probably write to /var/lib/ rather than /etc/texmf/dvipdfm/ regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351525: dvipdfmx: how to properly implement map files support for dvipdfmx
3. or failing that, implement update-dvipdfmx, which does something similar to what ptex-jisfonts is trying to do. It should probably write to /var/lib/ rather than /etc/texmf/dvipdfm/ I think update-dvipdfmx have to create /etc/texmf/dvipdfm/dvipdfmx.cfg file by merging configuration files on /etc/texmf/dvipdfmx.d directory like update-modules. Other packages may place the configuration files to /etc/texmf/dvipdfmx.d directory and invoke update-dvipdfmx on postinst script. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
