Description of problem: Instead of using already presend outline fonts, like any other tool from a TeX suite and xdvi does, evince is causing mktexpk to run and without paying any attention to a configured "mode" at that, and produces instead "modeless" bitmap fonts for its own use. An upshot is that if such bitmap images will be used to produce PDF via "Print to File" then results may be rendered in a substandard way when sent to other systems with different previewers. Hard copy printing results may also vary. In any case this is just a waste of time (but maybe it is somewhat related to bug 547776?). Here is some 'sample.tex' to make that more concrete: \documentclass[12pt]{article} \usepackage{mathpazo} \begin{document} Just some sample. Just some sample. Just some sample. Just some sample. Just some sample. \begin{displaymath} 2 + 2 = 4 \end{displaymath} \end{document} Running that through pdflatex shows in log that /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map is consulted and /usr/share/texmf/fonts/type1/bluesky/cm/cmr10.pfb /usr/share/texmf/fonts/type1/urw/palatino/uplr8a.pfb fonts are used. Similarly when one will produce a dvi file and display it in xdvi. 'pdffonts sample.pdf' shows AHXJGP+URWPalladioL-Roma Type 1 RFLZJB+CMR10 Type 1 An attempt to load sample.dvi into evince results in: kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+120/600 --dpi 720 fplmr mktexpk: Running gsftopk fplmr 720 ..... kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+120/600 --dpi 720 pplr8r mktexpk: Running gsftopk pplr8r 720 ..... kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+150/600 --dpi 750 cmr10 mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+150/600; nonstopmode; input cmr10 So on the top of other things fplmr.720pk and pplr8r.720pk were generated "modeless" but cmr10.750pk "ljfour". Really useful. This will be reproduced separately on every account which will try to run evince in that way as resulting bitmap are stored below ~/.texlive2007/texmf-var/fonts/pk/. Version-Release number of selected component (if applicable): evince-2.29.5-1.fc13 with a dvi plugin (but really any version I looked at) How reproducible: every time.
I guess we need to build evince with --enable-t1lib to fix that. Marek, can you investigate that ?
(In reply to comment #1) > I guess we need to build evince with --enable-t1lib to fix that. My first suspicion would be knots in calls to kpathsea library although I did not attempt to check that. There are some indications that bitmaps are generated and not really used for display. All that needs a somewhat closer look.
Hi, it helps to add "--enable-t1lib" together with "t1lib-devel" build requirement but it doesn't find all fonts. It still generates the pplr8r font (URWPalladioL-Roma font) even if the font is available in /usr/share/fonts/default/Type1/p052003l.pfb. Marek
Those fonts are generated inside of kpathsea's function kpse_find_glyph() (see backend/dvi/mdvi-lib/pk.c:107). Parameters to this function are the same for all those 3 fonts (except name and dpi), so, the decision about mode is not made in evince. Marek
(In reply to comment #4) > so, the decision about mode is not > made in evince. I did not try to figure out how this works, or is supposed to work, but there is this small detail that xdvi does not seem to have trouble finding existing fonts and it appears to use for that the same kpathsea mechanism; so it has to be some niggling difference somewhere.
Created attachment 398072 [details] map lookup patch I have found where the problem is. mdvi library (included in evince) parses its own config file for mapping files but the config file doesn't exist. If it exist, then it doesn't read it correctly (it assume absolute paths which are not in the file - it has to use kpse_find_file() ). And if it reads it correctly then it uses old font name instead of the new one (from the mapping). Now I have to find out where to add the config file. Marek
Created attachment 398073 [details] mdvi-config You need also this to have somewhere in a kpathsea search path.
(In reply to comment #7) > > You need also this to have somewhere in a kpathsea search path. Looking at the code you patched one can find in it this: /* get the name of our configuration file */ config = kpse_cnf_get("mdvi-config"); if(config == NULL) config = MDVI_DEFAULT_CONFIG; /* let's ask kpathsea for the file first */ file = kpse_find_file(config, kpse_program_text_format, 0); where MDVI_DEFAULT_CONFIG is defined in defaults.h as "mdvi.conf" which seems to be more in tune with a general pattern even if not entirely. Also kpse_cnf_get() looks like a wrong function to use here. All in all it appears that mdvi indeed attempts to look for an assorted configuration info but not that correctly and/or successfully. I wonder what other surprises are lurking there? An http://mdvi.sourceforge.net/ project appears to be dormant for a long time.
Hi, since adding of new configuration file is quite a big difference from upstream, I'm not adding it now. I filled an upstream bug leaving this bug opened until upstream fix (https://bugzilla.gnome.org/show_bug.cgi?id=612298). I'm going to add the configuration flag "--enable-t1lib" and the fix for using new fontname instead of the old one now (without the searching for the map file - it depends on the upstream fix). Regards Marek
(In reply to comment #9) > since adding of new configuration file is quite a big difference from upstream, As noted in comment #8 evince already searches for mdvi.conf (cf. a code fragment quoted there). This code is not entirely "symmetric" respective to "mdvi-config" and "mdvi.conf" names but maybe this is OK. A kpathsea documentation alone is far from clear on this point.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I am somewhat confused. This shows up in an evince package changelog: * Tue Mar 09 2010 Marek Kasik <mkasik> - 2.29.91-2 - Use Type 1 fonts when viewing DVI files - Use correct name when the font is mapped - Related: #562648 which may possibly suggest that the issues is resolved. OTOH a status of this bug is NEW and if I am trying the same as in the original report but using evince-2.30.0-6.fc14 then I see: kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+420/600 --dpi 420 phvr8r mktexpk: Running gsftopk phvr8r 420 .... and we are off to generate spurious bitmaps. Is this waiting for an upstream? In the meantime bug zappers "got helpful" (see comment #11) but I have no idea what is a status of this bug for Fedora 13.
Hi Michal, the problem with adding of mdvi.conf still waits at upstream. The sentence "- Use Type 1 fonts when viewing DVI files" means adding of the "--enable-t1lib" flag and the sentence "- Use correct name when the font is mapped" is the third part of the patch in the comment #6. Marek
(In reply to comment #13) > the problem with adding of mdvi.conf still waits at upstream. I am afraid that this is not the only problem. Looking what is reported by strace when trying to use evince-2.30.0-6.fc14.x86_64 mdvi-config is not checked at all. There is a search for mdvi.conf but only in two account specific locations. Namely as ./mdvi.conf and ~/texmf/evince/mdvi.conf. No other kpathsea searched locations will do. Once one of these two is present you will get: "page: Warning: ps2pk.map: could not load fontmap". Again a recourse to strace shows that only ./ps2pk.map and ~/texmf/evince/ps2pk.map are searched for and if missing then we are back to a square one. With one of these two in place finally bitmaps are not generated but I am seeing a long spate of warnings of that sort: ..... page: Warning: ps2pk.map: 1083: [t5d.enc] requested encoding `T5DEncoding' does not match vector `T5Encoding' page: Warning: ps2pk.map: 1084: [t5d.enc] requested encoding `T5DEncoding' does not match vector `T5Encoding' ..... That may be possiby bugs in ps2pk.map or evince going bonkers. I do not know. OTOH if a dvi file contains an embedded Postscipt picture then I am seeing a bunch of fatal internal error -100 ** (evince:2956): WARNING **: Error rendering PS document .... even if a correct PS file is, rather surprisingly at this stage, found. After that none of such graphics is shown. Not that useful after all of this.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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
evince-2.32.0-4.fc14 is as broken here as it used to be. I do not know now how this works with evince-3.0.0-1.fc15 but I would not hold my breath.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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