Xprint observations
Using sid, I installed mozilla-browser-snapshot and xprint. 1. Printing web pages is not 'wysiwig'; the default text (without font tags in the HTML) which is printed is not the same as it is on the screen. Mostly it is some kind of sans-serif font. R. Chandrasekhar mentioned the same problem a few months ago; in his case everything was printed in Courier. 2. Following R. Chandrasekhar, I downloaded Mozilla from mozilla.org and installed it in /usr/local. That version does print whatever text is on the screen completely 'wysiwig', by constructing Postscript files with lots of bitmaps. Often the bitmaps look awful when viewed in gv, but they look fine on paper. However, Mozilla from mozilla.org does not display anti-aliased fonts in the browser screen. R. Chandrasekhar mentioned this also. 3. By some tweaking (setting font.FreeType2.enable to true in /usr/local/mozilla/defaults/pref/unix.js), it is possible to get anti-aliased fonts also in the mozilla.org version. The anti-aliasing is much less beautiful than in Debian mozilla-snapshot, but anti-aliased it is. In the mozilla.org version, in preferences/appearance/fonts, the names of AA fonts start with a capital letter, the non-AA versions with a lowercase letter. 4. But if you select AA fonts for display in the mozilla.org version, xprint no longer prints 'wysiwig'. Just like in the Debian version. So there seems to be some incompatibility between AA display and 'wysiwig' printing through xprint. This could be a fundamental problem; if so, it would seriously limit the usefulness of xprint. But I wonder if anyone has been able to set it up in such a way as to have AA display and 'wysiwig' printing at the same time. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xprint observations
Dear Jan, I have an interesting footnote to add to your observations. If you install mozilla-browser_1.5-3 and include mozilla-xft_1.5-3 from unstable, and in Mozilla, under Edit/Preferences/Appearance/Fonts, select the fonts serif, sans-serif and monospace, without foundry affiliation (probably from Xft?) you can see rather impressive anti-aliased fonts on-screen and also get good looking serif, sans-serif and monospace printout from Xprint under Mozilla. However, if you change to any other fonts such as, for instance, verdana, the Xprint output will default to courier. My suspicion is that the re-direction activated by the mozilla-xft package in some way (through the default preferences, or perhaps through GTK?) affects the ability of Xprint to locate all truetype anti-aliased fonts other than those called serif, sans-serif and monospace (from Xft?), even though these other fonts are obviously recognized by both Mozilla and the system. I hope someone responsible and more knowledgeable in these matters will clean this up. Thanks. --Chandra 07 Dec 03 Jan Willem Stumpel wrote: Using sid, I installed mozilla-browser-snapshot and xprint. 1. Printing web pages is not 'wysiwig'; the default text (without font tags in the HTML) which is printed is not the same as it is on the screen. Mostly it is some kind of sans-serif font. R. Chandrasekhar mentioned the same problem a few months ago; in his case everything was printed in Courier. 2. Following R. Chandrasekhar, I downloaded Mozilla from mozilla.org and installed it in /usr/local. That version does print whatever text is on the screen completely 'wysiwig', by constructing Postscript files with lots of bitmaps. Often the bitmaps look awful when viewed in gv, but they look fine on paper. However, Mozilla from mozilla.org does not display anti-aliased fonts in the browser screen. R. Chandrasekhar mentioned this also. 3. By some tweaking (setting font.FreeType2.enable to true in /usr/local/mozilla/defaults/pref/unix.js), it is possible to get anti-aliased fonts also in the mozilla.org version. The anti-aliasing is much less beautiful than in Debian mozilla-snapshot, but anti-aliased it is. In the mozilla.org version, in preferences/appearance/fonts, the names of AA fonts start with a capital letter, the non-AA versions with a lowercase letter. 4. But if you select AA fonts for display in the mozilla.org version, xprint no longer prints 'wysiwig'. Just like in the Debian version. So there seems to be some incompatibility between AA display and 'wysiwig' printing through xprint. This could be a fundamental problem; if so, it would seriously limit the usefulness of xprint. But I wonder if anyone has been able to set it up in such a way as to have AA display and 'wysiwig' printing at the same time. Regards, Jan -- -- Dr R (Chandra) Chandrasekhar Australian Research Centre for Medical Engineering (ARCME) Murdoch University South Street, Murdoch, WA 6150, AUSTRALIA Phone: +61-(8)-9360-2783Fax: +61-(8)-9360-6304 email: [EMAIL PROTECTED] The Murdoch University CRICOS Provider Code is 00125J -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xprint observations
R (Chandra) Chandrasekhar wrote:
Dear Jan,
I have an interesting footnote to add to your observations.
If you install mozilla-browser_1.5-3 and include mozilla-xft_1.5-3 from
unstable, and in Mozilla, under Edit/Preferences/Appearance/Fonts,
select the fonts serif, sans-serif and monospace, without foundry
affiliation (probably from Xft?) you can see rather impressive
anti-aliased fonts on-screen and also get good looking serif, sans-serif
and monospace printout from Xprint under Mozilla.
However, if you change to any other fonts such as, for instance,
verdana, the Xprint output will default to courier.
My suspicion is that the re-direction activated by the mozilla-xft
package in some way (through the default preferences, or perhaps through
GTK?) affects the ability of Xprint to locate all truetype anti-aliased
fonts other than those called serif, sans-serif and monospace (from
Xft?), even though these other fonts are obviously recognized by both
Mozilla and the system.
I hope someone responsible and more knowledgeable in these matters will
clean this up.
I am not the responsible and more knowledgeable one, but can add two
more obscuring (to me) items:
I install mozilla's latest (e.g. 1.5 and 1.6a) from their source or cvs
and then compile them with xft and gtk enabled. I admit that all I get
with this over using sid mozilla-xft is the ability to change the boot
splash, but in my search for xft this idea occurred to me first before
searching for an xft enabled Debian package.
I do that also when I install Debian from scratch (i.e. 3.0r2 boot disks
and then apt-get)
A curious thing will happen. At first the characters on Mozilla will
look terrible (sorry about this extremely subjective term, meaning Xft
appears enabled, but there is lost of courier-like very small text in
the menus and toolbars). Then when I install *cupsys* and all its
dependencies, all the fonts straighten themselves out and I end up
with more fonts in the preferences, e.g. URW Bookman L, that I now use.
I think that is GTK? Because I can add .gtkrc in the ~home dir of where
mozilla runs and affect yet more font changes. I attach the file.
That responsible and more knowledgeable one is needed ;-)
An addendum: I use a modified X 4.3.0 because of Backstreet Ruby
mult-seat Debian and its xprt is broken and I have to apt-get the
version from xprt.org. It's broken because nothing prints from Mozilla.
I don't think it is the changes for Ruby because those do not affect
printing, merely separation of video cards I/O. So it is wherever that
version came from. ( http://www.schuldei.org/debian/bruby/ )
Hugo.
Thanks.
--Chandra
07 Dec 03
Jan Willem Stumpel wrote:
Using sid, I installed mozilla-browser-snapshot and xprint.
1. Printing web pages is not 'wysiwig'; the default text (without
font tags in the HTML) which is printed is not the same as it
is on the screen. Mostly it is some kind of sans-serif font. R.
Chandrasekhar mentioned the same problem a few months ago; in
his case everything was printed in Courier.
2. Following R. Chandrasekhar, I downloaded Mozilla from
mozilla.org and installed it in /usr/local. That version does
print whatever text is on the screen completely 'wysiwig', by
constructing Postscript files with lots of bitmaps. Often the
bitmaps look awful when viewed in gv, but they look fine on
paper. However, Mozilla from mozilla.org does not display
anti-aliased fonts in the browser screen. R. Chandrasekhar
mentioned this also.
3. By some tweaking (setting font.FreeType2.enable to true in
/usr/local/mozilla/defaults/pref/unix.js), it is possible to
get anti-aliased fonts also in the mozilla.org version. The
anti-aliasing is much less beautiful than in Debian
mozilla-snapshot, but anti-aliased it is. In the mozilla.org
version, in preferences/appearance/fonts, the names of AA
fonts start with a capital letter, the non-AA versions with
a lowercase letter.
4. But if you select AA fonts for display in the mozilla.org
version, xprint no longer prints 'wysiwig'. Just like in the
Debian version.
So there seems to be some incompatibility between AA display and
'wysiwig' printing through xprint. This could be a fundamental
problem; if so, it would seriously limit the usefulness of xprint.
But I wonder if anyone has been able to set it up in such a way
as to have AA display and 'wysiwig' printing at the same time.
Regards, Jan
style xeno_default {
font = -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1
fg[NORMAL] = #00
fg[PRELIGHT]= #00
fg[ACTIVE] = #00
fg[SELECTED]= #00
fg[INSENSITIVE] = #00
bg[ACTIVE] = #eddcff
bg[NORMAL] = #eddcff
bg[PRELIGHT]= #eddcff
bg[SELECTED]= #eddcff
bg[INSENSITIVE] = #eddcff
base[NORMAL] = #eddcff
base[PRELIGHT]= #eddcff
base[ACTIVE] =
Re: Xprint observations
R (Chandra) Chandrasekhar wrote: Dear Jan, I have an interesting footnote to add to your observations. If you install mozilla-browser_1.5-3 and include mozilla-xft_1.5-3 from unstable, and in Mozilla, under Edit/Preferences/Appearance/Fonts, select the fonts serif, sans-serif and monospace, without foundry affiliation (probably from Xft?) you can see rather impressive anti-aliased fonts on-screen and also get good looking serif, sans-serif and monospace printout from Xprint under Mozilla. However, if you change to any other fonts such as, for instance, verdana, the Xprint output will default to courier. I think I know more or less what is the matter now. I also tried the version you mentioned (mozilla-browser_1.5.3) and found the same. Very good anti-aliasing; wysiwig printing, but only as long as you do not touch the default fonts. If you change only *one* of the defaults to something else, xprint changes everything to some large sans-serif font, I believe URW Gothic L; for some reason in your case it is Courier. In fact you do not have to *change* anything. Open the preferences, appearance, font dialog and close it again with 'OK', and you have permanently lost good print behaviour of xprint. OK.. I did some more experiments and this is what I found. This is fairly complicated and long, I am sorry! -- In my case Mozilla from Debian 1.5_3 starts up with Bitstream Vera Serif as the serif font for *display* because that is its default. B.V. Serif is *called* just serif; Mozilla finds the correct font through fontconfig. -- The user has a settings directory for Mozilla (Debian 1.5_3) called ~/.mozilla. -- The Mozilla.org version (from mozilla-i686-pc-linux-gnu-1.5-sea.tar.gz) uses that same settings directory. Before trying Debian Mozilla 1.5_3, I had set the serif font in the Mozilla.org version to Bitstream Vera Serif. So there was *already* a line in prefs.js: user_pref(font.name.serif.x-western, bitstream-bitstream vera serif-iso8859-1); -- Because of that, Mozilla (Debian 1.5_3) printed Bitstream Vera and so I thought it printed 'wysiwig'. But then after touching the font settings, it printed URW Gothic. -- If I do the experiment again after rm -Rf ~/.mozilla, Mozilla (Debian 1.5_3) starts with a blank prefs.js file. Now it prints (the first time) serif in a Times Roman-like font. I think this is what you saw; you did not mention 'wysiwig' but only printing serif, sans, and mono. And of course after touching the font settings it becomes URW Gothic (in your case Courier) again. -- In the Debian versions (mozilla-browser 1.5_3 and mozilla-snapshot [=1.6a] behave exactly the same in this respect), after touching the font settings there is a line in prefs.js saying either things like (a) user_pref(font.name.serif.x-western, serif OR an explicit font name if you set it, e.g.: (b) user_pref(font.name.serif.x-western, Bitstream Vera Serif -- Now I think everything can be explained by assuming that xprint does not understand either (a) or (b). And if it does not understand it, it does some random thing like printing Courier or URW Gothic. The only two things it does understand are (c) user_pref(font.name.serif.x-western, bitstream-bitstream vera serif-iso8859-1); in which case it prints bitstream vera, and (d) nothing, in which case it prints a default serif font (=Times new roman). -- In other words, xprint understands only more or less raw font names, such as found in fonts.dir files. It already chokes on names beginning with a capital letter. Of course I do not know how to fix this. It must have something to do with fontconfig. At the moment in Debian, Mozilla's display function is cleverer at understanding font names than xprint is. The non-Debian version is not so clever but forces you to use these raw names for the display, which automatically also makes xprint work. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Xprint] Re: Xprint observations
R (Chandra) Chandrasekhar wrote: [snip] So there seems to be some incompatibility between AA display and 'wysiwig' printing through xprint. This could be a fundamental problem; if so, it would seriously limit the usefulness of xprint. But I wonder if anyone has been able to set it up in such a way as to have AA display and 'wysiwig' printing at the same time. I have an interesting footnote to add to your observations. If you install mozilla-browser_1.5-3 and include mozilla-xft_1.5-3 from unstable, and in Mozilla, under Edit/Preferences/Appearance/Fonts, select the fonts serif, sans-serif and monospace, without foundry affiliation (probably from Xft?) you can see rather impressive anti-aliased fonts on-screen and also get good looking serif, sans-serif and monospace printout from Xprint under Mozilla. However, if you change to any other fonts such as, for instance, verdana, the Xprint output will default to courier. This may be possible... I am not an Xft expert but AFAIK the font naming conventions between Xft and XLFD differ a lot... I've CC:'ed [EMAIL PROTECTED] who wrote recently a patch for Mozilla's PostScript module which solved similar issues... jshin: Would it be possible to write a similar patch (AFAIK the Xft/PS one was http://bugzilla.mozilla.org/show_bug.cgi?id=219060 (Freetype printing does not work for Xft build)) for the GTK+/Xlib gfx code in Mozilla (e.g. that font prefs from Xft-based Mozilla will work for normal XLFD-based Mozilla's, too) ? Bye, Roland. -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Xprint] Re: Xprint observations
On Mon, 8 Dec 2003, Roland Mainz wrote: R (Chandra) Chandrasekhar wrote: [snip] So there seems to be some incompatibility between AA display and 'wysiwig' printing through xprint. This could be a fundamental problem; if so, it would seriously limit the usefulness of xprint. But I wonder if anyone has been able to set it up in such a way as to have AA display and 'wysiwig' printing at the same time. I have an interesting footnote to add to your observations. If you install mozilla-browser_1.5-3 and include mozilla-xft_1.5-3 from unstable, and in Mozilla, under Edit/Preferences/Appearance/Fonts, select the fonts serif, sans-serif and monospace, without foundry affiliation (probably from Xft?) you can see rather impressive anti-aliased fonts on-screen and also get good looking serif, sans-serif and monospace printout from Xprint under Mozilla. However, if you change to any other fonts such as, for instance, verdana, the Xprint output will default to courier. This may be possible... I am not an Xft expert but AFAIK the font naming conventions between Xft and XLFD differ a lot... I've CC:'ed [EMAIL PROTECTED] who wrote recently a patch for Mozilla's PostScript module which solved similar issues... jshin: Would it be possible to write a similar patch (AFAIK the Xft/PS one was http://bugzilla.mozilla.org/show_bug.cgi?id=219060 (Freetype printing does not work for Xft build)) for the GTK+/Xlib gfx code in Mozilla (e.g. that font prefs from Xft-based Mozilla will work for normal XLFD-based Mozilla's, too) ? Actually, bug 219060 was just to fix the 'infinite-loop' problem in FT2 printing module in Xft+FT2 build. I didn't make any fundamental change in that bug. (there's another bug I have a patch for that makes a more significant change in Mozila-FT2's font selection mechanism [1]). In Xft build with FT2 enabled, two different font selection algorithms are used for the screen rendering and printing. For the screen rendering, fontconfig is used while for printing with FT2, XLFD-based font selection mechanism *augmented* with direct access to truetype fonts via freetype library is used. The result is not a very faithful WYSWYG but nonetheless we can get a pretty good result. In case of Xprint, its font selection mechanism is entirely based on XLFD so that it's not easy to get a faithful replica of the screen rendering by Xft. However, there's a possibility. See bug 211763 ( http://bugzilla.mozilla.org/show_bug.cgi?id=211763). This is to regard Xprint server as an Xserver with a very high resolution to which Xft can send its 'rendered' result. In summary, at the moment, the closest thing possible to WYSWYG print-out (with Xft build) is to enable freetype printing in Xft build. Jungshik [1] http://bugzilla.mozilla.org/show_bug.cgi?id=208213 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
