Drew Parsons wrote: > OK, this is where the interesting work starts. Ultimately it's > going to come down to me (if not someone else) rolling my > sleeves up and getting my arms grubby deep within the bowels of > the Xprint internals.
Yecch. But "sacrifices must be made" for progress, as Otto Lilienthal said .. > We'll have to mark out exactly what it's doing, font by font, > glyph by glyph, postscript directive by postscript directive. > Unfortunately it's a long term project since I'm no expert in > font or postscript internals. I have some limited knowledge of font internals, so if I could help.. > For reference, while I have been able to verify the problems, > especially with the spacing problem, most of the way along, > that problem has now disappeared from my system with the full > installation of X11R7.1. Print quality (measured by print to > paper and print to PDF) is now comfortably acceptable for me. > The spacing problem on www.debian.org, for instance, just > disappeared the other week after we finished the 7.1 > transition. That's without any of the font or css tweaking you > mentioned. Hmm.. maybe I tested it too soon. I'll reinstall xprint and try. > The only odd behaviour I'm seeing at the moment is that font > types sometimes get switched around. For instance at the moment > firefox displays the cyrillic links at the bottom (Bulgarian, > Russian) in serif, but Xprint prints them using a Typewriter > (courier) font for some reason. In my case (but I use the css hack and removed xprint's own fonts) the Bulgarian and Russian are (correctly) rendered in serif by xprint. > Other pages print similarly for me, printing fine apart from > sometimes switching serif for sans-serif. I suspect solving > this glitch will also solve the other problems we've been > seeing. What is curious to me is that the glitch is acceptably > "small" in this way for me, while its manifestation on your > system is much larger. Yes, it is strange. Maybe results depend on (the interaction between) the fonts that a user has installed. >> And whatever I do, Mozilla and Firefox still cannot print >> MathML on Linux correctly. Strange, because MathML printing >> is supposed to be one of the 'selling points' of xprint. > This problem is subtle. I tested some MathML on the new > "working" Xprint, e.g. > http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml . > Now firefox itself renders mathml defectively, even after > manually installing Mathematica fonts as directed on the > mozilla.org pages, the pages are not rendered satisfactorily on > screen, with some symbols missing, and superscripts > misaligned. This "MATHML display bug" seems to be a fairly well-known bug of Firefox (not Mozilla); see bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361183 which is quite old, and unresolved. It has to do with Pango. There is a workaround: disable Pango. You have to start Firefox with MOZ_DISABLE_PANGO=1 firefox, otherwise MATHML display becomes a complete mess. Printing with xprint in Mozilla/Firefox works "somewhat", but not well. The biggest problems are (in my case): -- mathematics is usually printed in Italic style (well, the variables are). In my case everything is Roman (upright). -- "large" symbols (like multi-line brackets and root signs) are always printed only one line high, and often in the wrong location (too high). The horizontal bar of root signs usually becomes a fat black block. I have no experience of how the "old" (pre-7.1) xprint performed; I only recently became interested in MATHML. But on http://www.mozilla.org/projects/xprint/samples/ there are some impressive samples. It says they were generated on Linux. If you look closely, these examples are also not really perfect (look, e.g., at the rendering of the "minus" and "plusminus" signs in the yellow highlighted section). But they are much better than what I can get on Debian now, so it seems xprint's MATHML capabilities have actually gotten poorer over the years. Grr. On Windows, both IE6 and Firefox print MATHML perfectly. > I think we can still sustain the claim that Xprint deals with > MathML better than "default printing". Perhaps. I have to re-test this. Due to another bug in Firefox it is not exactly easy to switch between xprint and postscript/default in Firefox -- see bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344401 (I added some comments to this; the problem is unresolved to this day). However I seem to recall that if you want to print a MATHML coded mathematical expression like a c - = - b d the "native" Firefox printing method misplaces the "equals" sign. You get something like a = c - - b d while xprint renders it correctly. So I would agree with qualifications to this statement.. a qualification being that "better than very bad" is not really good enough for actual use. To experiment with MATHML, you could use ASCIIMathML.js. See my MATHML test page http://jw-stumpel.nl/bounce.html. It it *much* easier to generate MATHML formulas through ASCIIMathML than to laboriously code MATHML by hand. IMHO Linux will never "make it to the desktop" until system-wide functions like display and print "just work", as they do in Windows. Anyway, thanks for your efforts, as always! Maintaning a package without upstream activity cannot be very easy. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
