You need to have hebrew fonts on your font server to see this. LPR version 0.48 HP-4000 printer on SMB network. 1. Go to www.netvision.net.il 2. Change character set to hebrew-windows1255 3. You should now see the page in (reversed) hebrew. 4. Do File/Print and print the page. Result: The page comes out with gibberish (latin with '', etc) instead of hebrew. Expected: Hebrew characters printed. Some analysis: I believe this problem is common to hebrew printing using postscript. The resulting .ps file is attached

In order to print out postscript hebrew characters.. the hebrew AFM (Adobe Font Metrics) file appropriate for that font has to be installed.. or accessible. Otherwise it will default to the default AFM files. I am not sure where to go from here.. or how to resolve this bug.

The problem is not so much that the font is missing, but the fact that the resulting postscript output contains the "Latin-1" encoding in it. How a hebrew text can be treated as Latin-1? If the font is not available, it should not print, or should render the output as EPS, the same as "print true type as bitmap" setting in windows. but in no way should it put a "Latin-1" patch inside postscript output when the font can not be found. Does it even look for it?, or does it just puts Latin-1 always as the encoding?

To continue on my previous comment; take http://www.walla.co.il for example The page is rendered with hebrew fonts, and the charset is recognized as iso-8859-8, however printing to file produces the file which i will attach. The problem is that this whole .ps file is marked as isolatin1 and %mozilla-charset iso-8859-1. This file also is not viewable in ghostview due to postscript errors.

dcone- you are the PostScript module owner, right ? Do you need help from i18n group to fix Unicode PostScript printing ? Add several mozilla developer who interest about linux printing and bi-di to the cc list.

Maybe Xprt (X print server) can help here. Comments ?

Why M18? Any explanation why international printing is not important enough?

Hmm, as a good answer to my previous question someone changes this to M26?!!! I will ask again, international printing is not a requirement in the only browser available to non windows users throughout the world?

Cc'ing the folks working on the Xprint implementation for comments. See also bug 6312 "Linux: internationalize printing", but the real discussions are currently in news:netscape.public.mozilla.i18n

This bug has been marked future because we have determined that it is not critical for netscape 6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

May i ask what is not important for NS6.0? Is it international printing, or international printing on Linux? How about platform parity? Or is it specifically printing Hebrew on Linux that is not important? Is NS6.0 aimed at english users only?

Not to mention, international printing support is important, so there are discussion in mozilla-i18n newsgroup about this feature. Please look for the posts done under the subject "native encoding Font support in CJK PS printing" and the proposed patch at, http://village.infoweb.ne.jp/~katakai/mozilla/printing.htm. This is under dcone@netscape.com's review. It will be checked in once he gives us the GO and we can get check-in approval from CVS gatekeeper.

<comment> Please excuse me if this comment is written in harsh tone and if it hurts anyone. </comment> What is was so upset about was dcone's comment saying <qoute> This bug has been marked future because we have determined that it is not critical for netscape 6.0 </quote> Ha?! Netscape 6.0? not a particular beta but the actual NS 6.0 release will only print english? now read the page at http://village.infoweb.ne.jp/~katakai/mozilla/printing.htm and i don't get how on earth was it not done this way from the start? I've been talking (yes i know talk is cheap) about this for may be as long as a year, that a user expects for an output Postscript to be in his native encoding and deal with lack of ghostscript fonts later and not be forced into some arbitrary chosen iso-8859-1 encoding, which has nothing to do with the original content of the web page. Now if dcone (sorry, i don't know your real name) is responsible for giving you the green light to include this in the regular builds, we (all international users) are out of luck, cause he thinks that it is not important for NS 6.0. There is only ONE reason that it may be not important for NS 6.0 and it is that Netscape as a company does not see platforms other than windows as important enough to go into trouble of providing descent internationalization for. What's worse than that, is that <i>mozilla</i> as a project is influenced by a purely marketing oriented decision such as this, and completely disregards non windows users on all non-trivial features. This includes international printing, performance, OJI support etc.. I would expect it from netscape, after all they are a company with it's own agenda, but not from a community based project like mozilla.org

Netscape has decided not to include bidi in Netscape 6. That means both on screen and on the printer, and for all platforms (for Netscape 6, that means Windows, Mac and Linux). IBM is working on bidi, and mozilla.org is working with them to get those changes into Mozilla. Some progress has been made, but it is hard to predict when the code will be checked in, and it will probably be in ifdefs initially. We don't know when the ifdefs will be turned on by default in Mozilla, and Netscape doesn't know when bidi will be shipped as part of a Netscape release. Moshev, are you a programmer? Perhaps you would like to help if you are so anxious to see bidi printing support on Unix?

Going back to the original text... If the latin-1 tag in the ps file is changed, does the file print correctly? Does the problem happen for other things besides Hebrew? If Russian doesn't print correctly, I think you would have a much better argument of getting International printing fixed in general.

Stupid question: AFAIK is international printing supported/covered via libXp/Xprt (the X print system)... Where's your problem ?

I'll bite :). Since i am a russian speaking too, i tested www.rambler.ru - print to file - crash... ok, let's try something else: http://top100.rambler.ru/top100/Music/index.shtml.ru - print to file - crash.. finally - http://kulichki.rambler.ru - print to file - a file is created.. Now more ./mozilla.ps | grep iso - > /Encoding isolatin1encoding def Wow, i guess russian is not working too. I don't know about Xprt (will check what it is on google in a moment), but does the user really wants to do anything else but press print to print? I am attaching the mozilla.ps file from http://kulichki.rambler.ru for Postscript gurus to look at. Now about myself, yes i am a programmer, but i've not done c/c++ for couple of years (doing mostly java lately), and never programmed c/c++ on linux other than simplest things, don't know enough of postscript to be of any help and would not be able to dive into it without sacrificing my daily job+msc in cs that i am doing right now. So may be i don't have the right to complain, but i thought that having a user input as detailed as i provide will help in at least setting the priorities. I guess i'm wrong.

One other comment about bidi - i didn't ask for a bidi printing. most hebrew pages are visual anyway, and i can read backwards, I just ask you to understand that A with an umlaut or whatever is not similar to hebrew Aleph or russian Ia.

X print system can be easily enabled in Mozilla, but I don't know if I'm allowed to give the info here how to enable&&configure it in the Zilla... Q to Hidetoshi Tajima... am I allowed to post your small README here ?

Not wanting to spam this bug report anymore, but at least on my system the ghostview dies trying to show the mozilla.ps file in last (third) attachement: Error: /syntaxerror in -file- Operand stack: unicodeshow Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:930/983(ro)(G)-- --dict:0/20(G)-- --dict:89/200(L)-- Current allocation mode is Aladdin Ghostscript 6.01: Unrecoverable error, exit code 1 local Hope this helps.

Roland, it's not about that specific readme. I can write a script to edit the postscirpt file, or dig on google and find some solution, but most users can't. And NS6.0 is hopefully going to become a popular browser, so my real concern is what OTHER people will do? When i show someone how easy it is to setup linux these days, do I also have to show them how to use/program in perl so they can print from Netscape?

NO no, completely wrong. Printing via libXp/Xprt is _very_ simple. 1. Start the X11 print server (like you start your Xfree86 server): Example: % Xprt :4& 2. Set a secret option in Mozilla (can't tell you yet, otherwise Hidetoshi will cut me in little peaces :-) and tell it where it can find the X print server (Xprt). That's all. I18n etc. should be completly covered and the default settings for Xprt should generate the proper PostSostScript code :-)

Ok, this is a start of a solution but let's play a somewhat willing_to_mess_up_with_config linux user that installed vanilla mandrake 7.1: #man Xprt No manual entry for Xprt ---- ok, let's try #Xprt --help ---- looks much like starting an X server, good... #Xprt Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. Aha, it needs to run on another display #Xprt :1 Xp Extension: could not find config dir /usr/X11R6/lib/X11/C/print --- Ha? #Ctrl-Z, bg%1 #ps axw | grep Xprt 12222 pts/0 S 0:00 Xprt :1 Great, it seems it is running, now vi ./prefs.js I think you get my point. The real solution is to integrate whatever solution is there into the standard build, provide the needed gui in mozilla prefs to configure it properly if needed, help etc.., But! it is all post NS6.0 right? I don't specifically care in this bug report about removing isolatin1encoding in postscript files, if there is another solution, great. My point however remains that it should not be post NS6.0 issue. Thanks for bearing a flamewar in bugzilla, and sorry for it, Moshe Vainer moshev@easybase.com (if someone wishes to e-mail me about it off-bugzilla, feel welcomed)

Ok, i know everyone is tired of me but one last thing worth mentioning: I fired up windows/ie5.0, went to http://www.rambler.ru and did a print to file. (I have a ps printer). The output file although big (since it has all the fonts encoded) is a valid postscript file, which when transferred to my Linux Box, views great in gv with color, russian text and everything. Why is it not possible to generate the same kind of output from mozilla? If it is a valid .ps file, and is rendered perfectly with ghostscript, then there should be no problem to print it on any PS printer. And embedding fonts in ps output should not depend on true-type font support. If mozilla can render the page, can't it embed the very same fonts it uses for page rendering into the output ps? Should i attach the resulting .ps file from ie that can be viewed with ghostview? (it's large ~250k gzipped)

Yes, please attach it for comparisation. I'm currently building Mozilla with X print enabled. But it will need at last ~45mins and I need some sleep now... see you tomorrow...

Anything new about this bug? I have added the attachment as requested, I also see that lot of things are being done for CJK for M18, but nothing for Hebrew. How is Hebrew different from CJK regarding font substitution?

How to print from Mozilla with libXp/Xprt: 1. Edit $HOME/.mozilla/default/prefs.js and add: -- snip -- user_pref("print.print_method", 1); -- snip -- 2. Start Xprt: % Xprt -audit 4 :2& 3. Set X print display var and start Mozilla % export XPDISPLAY=mysun:2 % ./mozilla Type the printer name in the "print command" field. (BTW: This assumes that Mozilla was compiled with --with-xprint) It would be nice if someone from the Linux platform would attach the resulting PS file here, AFAIK Xprt on Linux may be some bugs in the font handling...

This is extremely *user friendly*. I am not talking about this, i am talking about a solution for users, not for programmers. I personnaly can use sed and write scripts, i did not know that mozilla is about educating people how to become computer wizards. May be i am wrong. I'll just stop bugging you all, since it seems that this project is not about producing multi-lingual, user-friendly, standard compliant browser. I have said it before, and i will say it this one last time, putting isolatin1 in a postscript file that does not originate from isolatin1 page is simply a bug, printing for international pages should either be disabled, or fixed.

> This is extremely *user friendly*. I am not talking about this, > i am talking about a solution for users, not for programmers. Brrr... stop. Please. Xprt should be set-up with the "normal" print system by an administrator, not an user. In Solaris >= 7/MU4 add the following line to /etc/init.d/lp: -- snip -- [ -f /usr/lib/lpsched ] && /usr/lib/lpsched + [ -x /usr/openwin/bin/Xprt ] && (/usr/openwin/bin/Xprt :1&) -- snip -- Then restart the print system: % /etc/init.d/lp stop % /etc/init.d/lp start Then Xprt runns forever - for all users - under localhost:1 Isn't THAT user-friendly ?

Sorry, please ignore my rant, now the real questions: 1. Are Linux distros supposed to set this up on installation, 2. if not should mozilla provide it on -install? 3. Should this pref be available via XUL? 4. if so, should i file separate bug on this? 5. I will certainly try it now on Linux and report the results. Rgrds Moshe.

> Sorry, please ignore my rant, now the real questions: No problem. I'll fight for libXp/Xprt... :-) > 1. Are Linux distros supposed to set this up on installation, Uhm... you can add Xprt to Linux print system startup, too. SuSE Linux comes with Xprt. Unformtunately you may run into the problem that Xfree86-Xprt doesn't contain the fixes of Solaris8-Xprt (font glyphs wrongly placed etc.). Someone at Xfree86 mailinglist said that Sun engineering has comitted the patches back to X.org but I cannot see them. If any of the Sun engineers read this: Is it possible that I can get my clawn on the source to build a Linux-x86 binary of Xprt-fixed ? > 2. if not should mozilla provide it on -install? ???? > 3. Should this pref be available via XUL? YES YES - file and RFE for this (like "Print dialog should support X11 print system) and vote for it... :-) > 4. if so, should i file separate bug on this? see above > 5. I will certainly try it now on Linux and report the results Attach PostScript file, please !

I was just editing my other reply on this when you submitted your's, so i'll just briefly repeat: My attempt to start Xprt: #Xprt -audit 4 :2 & [1] 14116 Xp Extension: could not find config dir /etc/X11/xserver/C/print # sort: -: write error: Broken pipe Fatal server error: no screens found [1]+ Exit 1 Xprt -audit 4 :2 All man Xprt, man -k Xprt, man XF86Config etc produced nothing usable. This was done with MandrakeCooker XFree86 4.0.1 rpms. So the current state of Linux (from my point of view, correct me if i'm wrong) is that it does not support Xprt by default. 2. I will file a separate RFE for the prefs. (later today) 3. How come that my Lyx happily prints hebrew without the need for anything else? 4. Would it help if i produce corresponding .lyx,.tex,.dvi,.ps for someone to analyze? 5. <rantagain> Why oh why is it marked future? </rantagain>

> I was just editing my other reply on this when you submitted your's, so i'll > just briefly repeat: > My attempt to start Xprt: > #Xprt -audit 4 :2 & > [1] 14116 > Xp Extension: could not find config dir /etc/X11/xserver/C/print Ahhhglllrr. I'll create an attachment for this. > # sort: -: write error: Broken pipe > Fatal server error: > no screens found "No screens found" normally means that Xprt can't find/setup a printer. > [1]+ Exit 1 Xprt -audit 4 :2 > All man Xprt, man -k Xprt, man XF86Config etc produced nothing usable. > This was done with MandrakeCooker XFree86 4.0.1 rpms. See attachment. > So the current state of Linux (from my point of view, correct me if i'm wrong) > is that it does not support Xprt by default. I'll fix that... > 2. I will file a separate RFE for the prefs. (later today) Please add bug reference. > 3. How come that my Lyx happily prints hebrew without the need for anything else? Unknown. > 4. Would it help if i produce corresponding .lyx,.tex,.dvi,.ps for someone to analyze? > 5. <rantagain> Why oh why is it marked future? </rantagain> Unknown. See BUG_ACTIVITY.

Thanks for the man page, however: 1. it does not help me in setting up the config file for Xprt (XpConfig & Xprinters) since there is no syntax description for these files 2. You are trying to help me specifically with hebrew printing, for which i am very thankfull, but this is not what my problem is, my problem is that mozilla as a desktop (not server) product is only suitable for english users, or very computer savvy users, and it is my belief that - I. it is contrary to the goals of this project II. other programs are doing it without the need to be computer savvy III. All other programs that are doing it rely on embedding existing fonts in the output ps file, and i see no reason why mozilla should not do the same IV. even without the support of Xprint, or without the needed fonts being on the system, putting the string "isolatin1" into an output postscript file for a page that is absolutely not "isolatin1" is simply a bug, and should be fixed regardless of other developments on this issue. It is basically the same as hardcoding a font name for HTML page, let's say "microsoft sans serif" without giving the opportunity to change it for e.g. "helvetica" , and then dumping core if font is not found - a simple case of a bug.

Created tons of attachments (seems that BugZilla has problems with larger attachments... ;-( ). Use "munpack" to create original file (X11_etc_xpconfig.tar.gz): -- snip -- % munpack * Saving part 1 of 5 25028.967033476@castor.informatik.med.uni-giessen.de Saving part 2 of 5 25028.967033476@castor.informatik.med.uni-giessen.de Saving part 3 of 5 25028.967033476@castor.informatik.med.uni-giessen.de Saving part 4 of 5 25028.967033476@castor.informatik.med.uni-giessen.de Saving part 5 of 5 25028.967033476@castor.informatik.med.uni-giessen.de X11_etc_xpconfig.tar.gz (application/octet-stream) -- snip --

Roland Thank you very much. I have also just now seen your posts on http://www.xfree86.org/pipermail/xpert/2000-August/000907.html and yes, one of the problems is probably the lack of documentation. If docs are available, i guess then it's the distro's job to integrate the configs in the install problem. I'll try with your attachment later today and report back on any success or otherwise.

> Thanks for the man page, however: > 1. it does not help me in setting up the config file for Xprt (XpConfig & > Xprinters) since there is no syntax description for these files Sorry, I needed some food (otherwise my brain will activate sleep mode :) and some time to figure out that BugZilla produces nasty errors when attempting to create large attachments. > 2. You are trying to help me specifically with hebrew printing, for which i am > very thankfull, but this is not what my problem is, my problem is that mozilla > as a desktop (not server) product is only suitable for english users, or very > computer savvy users, and it is my belief that - Other locales simple require more work on the administrator side. > I. it is contrary to the goals of this project > II. other programs are doing it without the need to be computer savvy > III. All other programs that are doing it rely on embedding existing fonts in > the output ps file, and i see no reason why mozilla should not do the same > IV. even without the support of Xprint, or without the needed fonts being on > > the > system, putting the string "isolatin1" into an output postscript file for a page > that is absolutely not "isolatin1" is simply a bug, and should be fixed > regardless of other developments on this issue. It is basically the same as > hardcoding a font name for HTML page, let's say "microsoft sans serif" without > giving the opportunity to change it for e.g. "helvetica" , and then dumping > > core > if font is not found - a simple case of a bug. AFAIK Xprint handles fonts in multiple steps: 1. Check if printer has the font - if yes: Use it. 2. If one fails: Dump all fonts in PS file (AFAIK the reason why Xprt PS output is huge when default config is used (which assumes printer is a dumb one and has no fonts)) - please correct me anyone here if I'm wrong

Sorry for the off-topic SPAM: For those who don't own "mpack": ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z BTW: Is there a BugZilla bug that attachments ~~>512MB causes a perl-script within BugZilla to fail ?

Roland thanks again, some problems: 1. I had to run xfs -port -1 in order to run Xprt, otherwise it would complain: Could not init font path element unix/:-1, removing from list! Fatal server error: could not open default font 'fixed' I could not find how to set font path, and whether it should be set to the fonts you provided or to the same fonts i use in X font server. 2. I have tried to print (after changing prefs etc,) but my printer would still print just empty rectangles instead of hebrew. I am not sure it even used Xprt. I will attach mozilla.ps for you to inspect. Thnks again.

From PS intro of last attachment: -- snip -- %!PS-Adobe-3.0 %%BoundingBox: 36 36 595 805 %%Creator: Mozilla (NetScape) HTML->PS %%DocumentData: Clean8Bit %%DocumentPaperSizes: A4 %%Orientation: Portrait %%Pages: 0 %%PageOrder: Ascend %%Title: Test Title %%EndComments % MozillaCharsetName: iso-8859-1 -- snip -- This PS file comes from Mozilla and _not_ from Xprt ("Creator" line looks different). Currently "Save as File" does not use Xprt. You've to print and grab the file from the print queue (better: create a print queue which dumps all files into a dir instead to the printer). BAD: I have problems getting Xprt running on Linux, it can't find any printers (lpstat missing !?!?) ? Any ideas ?

Unfortunately printing directly to printer produces the same results. It leads me to believe that nightlies are not compiled with --with-xprint Can anyone confirm or deny it?

I can't confirm this but I assume that "nighlies" are build with ./configure; make; make_tarball". Xprint support isn't included per default - therefore nighlies will miss this feature.

I will then have to wait untill this is done (I really can not build mozilla while at work..., and at home i have (don't laugh, i don't bother to upgrade) a 133mhz Pentium w/o internet) Is there a tracking bug for inclusion of --with-xprint into builds? Should i file one?

> I will then have to wait untill this is done (I really can not build mozilla > while at work..., What about "% nice -n 18 make" ? > and at home i have (don't laugh, i don't bother to upgrade) a > 133mhz Pentium w/o internet) =:-) > Is there a tracking bug for inclusion of --with-xprint into builds? > Should i file one? Yes, please.

Patch 108376-12 (Xsun&Xprt patch) for Solaris _2.7_ is out, including some nice Xprt fixes. See http://sunsolve.sun.com/pub-cgi/retrieve.pl?patchid=108376&collection=fpatches for the README and http://sunsolve.sun.com/pub-cgi/patchDownload.pl?target=108376&method=H for the patch itself.

> > Is there a tracking bug for inclusion of --with-xprint into builds? > > Should i file one? > Yes, please. Since I couldn't find one, I added one; bug #52076 |It is basically the same as hardcoding a font name for HTML page, let's say |"microsoft sans serif" without giving the opportunity to change it for e.g. |"helvetica" , and then dumping core if font is not found - a simple case of a |bug. Well, where is the difference. If you look closely at the source for ps printing, you will realize that it only uses Times Roman (not even Courier for printing monospace). I haven't looked at Xprt (I have the same problems with starting, and building takes ages on my PII for building Mozilla), but I if I understand this correctly, Xprt + Mozilla--with-xprint allow to print monospace and sans-serif and unicode etc.? Then XPrint seems to be *the* solution of many of the pending unix bugs (maked as OS=Linux).

Ok, I'm almost asleep. The bug id is bug 49947 and alread there for some time (see depend). And for those who miss the UI for enabling the XPrint feature, it is bug #49946 (also a dependence).

Has someone an URL with Hebrew X11 fonts (DPI=90) ? I'd like to add a PostScript dump of libXp/Xprt printing http://www.qsm.co.il/Hebrew/qashetab.htm with matching fonts...

Ignore that last message... seems the hebrew fonts were available. I've put some low-low-resolution (!!) examples (for SPARCprinter 2) from Xprint (Mozilla post-M18+Solaris 7 Xprt) on the WWW: http://puck.informatik.med.uni-giessen.de/people/gisburn/work/mozilla/xprint/ Comments ?

cc'd mkaply@us.ibm.com

spam : changing qa to sujay (new qa contact for Printing)

I'd like to attach new screenshots from upgraded Xprint - does anyone have some nice example URLs with many text, no frames and not-so-many images for the following locales (I don't have scableable fonts for the other locales): -- snip -- iso_8859_2 iso_8859_4 iso_8859_5 ar iso_8859_7 iso_8859_8 iso_8859_9 iso_8859_15 -- snip -- Thanks !

can someone summarize what is the current status. Does any patch get provided. katakai@japan.sun.com know the moxilla/gfx/src/xprint code will . please let him know what we need from here.

Frank Tang wrote: > can someone summarize what is the current status. See below... > Does any patch get provided. BTW: Xprint has it's own BugZilla component ("Printing: Xprint"). Most evil stuff has been fixed except the XUL unix print dialog - which is horrible insufficient for Xprint. All other stuff has bugs in BugZilla and I am working on this... see below... > katakai@japan.sun.com know the moxilla/gfx/src/xprint code will . please let > him know what we need from here. Xprint status: - Print now prints most pages in european/english languages correctly. Others should work, too - but I cannot verify this yet because I am currently working on the fontmetrics stuff (see below)... This bug has some GIFs from PostScript files (created with _very_ old code... newer code is far better from both visual and PS code quality) attached which shows that Xprint module works... I am going to file new GIFs once the fontmetrics code works again... A list of example URLs would be nice... - Printing BIDI pages works (except the fontmetrics issue described below). - Xprint should be (depends on the time I a wasting in getting r=/sr=/checkin for my stuff) fully functional in 0.9.2 (incl. images/fontmetrics issues) - except the print dialog code. This is out of my scope. Need help. Known issues: 1. We need a better print dialog which reflects all Xprint-special features (for example: Xprint can provide a list of all available printers. Xprint can get/set special printer attributes like available color/plex/orientation/number_of_copies and so on... Xprint can make life of users/admins far more easy compared to what Mozilla's native PostScript module (and other Unix-printing solutions... ;-(( ) offer(s)... Print dialog should reflect this functionality)... I would prefer that we share the _same_ dialog for both "native PostScript" and "Xprint" modules on Unix to avoid that we have twice the work for one goal... 2. Xprint module does not print/scale images properly yet. I am working on that... should be fixed soon if nothing goes wrong. If something goes wrong I may been some help from image gurus (pavlov,syd,etc.)... 3. Starting with the checkin of the 2ndRevampOfXprint patch (bug 78548) the nsFontMetricsXP.cpp has problems to return (find !?) fonts for some locales/heights/encodings/some_weired_font_attributes. The Xlib-toolkit suffers from the same issue - the new code in nsFontMetricsXP.cpp is a 1:1 copy+s/Xlib/Xp/ from nsFontMetricsXlib.cpp... I am investigating this currently... should be fixed soon after killing image handling bugs - if nothing goes wrong. If something goes wrong I may need the help from ftang... ftang... could you please take a look at the Xlib-toolkit and check why it cannot render some fonts (mainly asian/hebrew/etc. fonts), please ? This may help me a lot in killing the same bug in Xprint module... thanks ! 4. Other minor issues are described in the bugs for the "Printing: Xprint"-BugZilla-component... Problems: It would be very nice of I would have two or three people which could do _fast_ r=/sr= for my patches. It's driving me nuts (sometimes =:-) that most of the time I am _waiting_ for r=/sr=/checkin for my patches (I do not have CVS write access). I do not have the space to hold a 2nd code tree on my disks (see bug 72087 for a nice comment about this... :-(((( )... bigger patches always block further developments on my side (yeah yeah... I know... I should "file smaller patches"... =:-) I'll try that... :-)... ;-(( Goals: - Get a fully functional and easy-to-use and easy-to-configure printing solution for Mozilla on unix - incl. _full_ i18n support - Make Mozilla the default print system for platforms where Xprint (libXp+Xprt) is available (Solaris >= 2.7 for example) and get _rid_ of that (stupid) PS module on those platforms. I think we do not need it anymore once Xprint is fully functional. Xprint module supersets the functionality of Mozilla's native PS module, will be smaller (module size is currently 1/2 of the size of PS module - and code will continue to shrink, memory footprint on client side is also far smaller), faster, print jobs will be smaller (currently printing large text files with Xprt's PS DDX results in ~2.45 times smaller PS jobs than those generated with Mozilla's "hand-written" native PostScript module // smaler print jobs == jobs will be processed+printed _faster_) and has fully functional i18n support for all pages which could be rendered with Mozilla per default (no special config needed - just start Xprt [1]... =:-) Uhm... and questions ? [1]=You may want to configure Xprt to tell it to use available printer buildin fonts to get better quality and smaller print job sizes - but this is _optional_ - and only needs to be "done" ___once___ at ___one___ central location - Xprt - which can be shared by many computers (Xprint is cross-platform and network-transparent) - which makes it an ideal solution for thin-clients (no spooler system on client-side needed... all config stuff and heavy calculations are "done" on the server-side)...

I've attached a sample PostScript job from Xprint module (incl. patches from bug 77210). Looks good so far (well... I do not have all fonts... and most CJK fonts are only available as 75dpi versions on my system. But printer-buildin fonts are printed as buildin fonts - and remaining fonts are taked from X11 fonts (fallback))...

Can anyone who is interested in the Xprint solution please vote (http://bugzilla.mozilla.org/showvotes.cgi?voteon=49947) for bug 49947 ("Please add --with-xprint to nightly builds") ? Thanks !

RFE/bug 49947 has been implemented, Xprint is now part of the default build.

Reporter: Can you confirm that attachment 79796 [details] is correct (I can't read hebrew...) ? And is the quality OK for you ? If yes I can make a short description how to print hebrew... :)

The Hebrew in the last three attachments looks correct to me, except for the page title in the header. That is a separate issue, and I have filed bug 139297 for it.

Quick guide how to print hebrew with Mozilla using Xprint is available under http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/quickguide_hebrew_iso_8859_8.txt ; Xprint FAQ is available under http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/Xprint_FAQ.txt and the current Xprt Linux x86 binary release can be downloaded from http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_006.tar.gz (sounds hard but isn't, should take less than 10mins to get it working... :)

Mass-resolving some bugs related to the old Linux/Unix printing code. The old code has been removed from the tree, and the bugs are all FIXED by the new cairo-based printing system.