Description of problem: SPadmin doesn't have a link (or shell script to activate it) in /usr/bin. Version-Release number of selected component (if applicable): 2.0.2-5.7.2 Steps to Reproduce: 1. Type "spadmin" or "oopadmin" or "ooo-padmin" Actual results: Doens't recognise the command. Expected results: Should recognise the path and open the OpenOffice.org Printing Admin, SPadmin, which exists in the following path: /usr/lib/openoffice.org2.0/program/spadmin Additional info: All that should be done is to add another shell script to the OOo RPM packages, just like /usr/bin/oowriter, which will be called /usr/bin/oopadmin and will call /usr/lib/openoffice.org2.0/program/spadmin Thank you.
Not having a link is deliberate. spadmin is deprecated under Fedora, to add a printer or manage fonts use normal desktop printer adding functionality or font management. spadmin only continues to exist to provide a mechanism for fax printer administration, something which hopefully will be folded into cups and cups admin tools in the future. I'd be interested in knowing what problem you wanted to address by using spadmin ?
Actually, SPadmin is STILL necessary for people who print in CTL languages, such as Hebrew or Arabic (I use both). If one does not uncheck the "Enable font replacement" option for each printer, it will not print CTL documents well (apostrophes, dots, brackets etc. are printed on-top of text; white spaces are put in wrong places...). The only way to solve this is SPAdmin (quite simple to do actually, unless you cannot get to it because you aren't aware that it only exists on /usr/lib/openoffice.org2.0/program/). Besides, I would ask you all not to underestimate other people's work. I know that Fedora has very good software, and I admire the developers of CUPS - but this doesn't mean that the people on OOo don't know what they are doing. SPAdmin is there for a reason, and shouldn't be ignored by Fedora. I want to thank you for your attention, and at the same time reopen this bug. This IS a bug, whether it was deliberate or not. Thank you for your time, Oded R.
What I need is a demo document that shows this problem. Is that possible ? Running "spadmin" from the command-line is not much less obscure than running /usr/lib/openoffice.org/program/spadmin. The symptoms really sound like a bug which using printer-side font replacement works around. I'd be interested in the kind of results gotten from cutting and pasting the same text into e.g. gedit and changing the gedit default font to that in writer and seeing if the gedit print output works or shows the same flaws.
I'm adding an attachment, a .tar.gz archive of pdfs. gedit.pdf: The output of printing in gedit (fine, whether the printer was defined to enable font replacements in OOo or not). ooo_bad.pdf: The output of a printer that enables font replacements in spadmin. ooo_good.pdf: The output of a printer that disables font replacements in spadmin. I guess it's a little hard for someone who isn't familiar with the language and the letter to see the difference, but if you put them side by side, and look at the bottom line and especially on the headline, you'll see the difference. Thank you for your help, Oded R.
Created attachment 127614 [details] Printing outputs (see comment #4)
I can see the differences is positioning in the two outputs. Could I get the source writer document as well ?
Created attachment 127677 [details] The source .odt file for the print outputs. Here's the source .odt file. I don't see anything unusual in it (and it happens with many many Hebrew files, it's not something particular to this document). By the way, I'm not sure whether you'll be able to see this document on your computer, because OOo needs a set of Hebrew fonts to show Hebrew text. If this is really important to you, you can download this set (there's only one known in the Hebrew Linux community, maybe there are others, but probably no-one uses them) here: http://culmus.sourceforge.net/ Thank you, Oded R.
Sorry, it would be much easier to just go directly to: http://sourceforge.net/project/showfiles.php?group_id=59410&package_id=55474&release_id=290983 (the previous was the site of the project, not of the download). Good day, Oded R.
Checking around, it seems that it may make sense to actually default to not "enabling font replacement" for everybody, as it doesn't play well with glyph replacement (which is the problem here). Normal gnome apps on printing don't do such a font mapping from a given list of fonts to the list of printer embedded fonts.
No argument here - I do agree that defaulting to not "enabling font replacement" is the best solution (unless it is neccesary for other features/languages to work...). The question is, should this be a Fedora issue (defaulting to not enabling "font replacements") or an OOo issue... I'm sure OOo wouldn't really be glad to disable this option by default (I assume it does something good after all...), but I'm not completely sure that it's a Fedora responsibility to change this... What do you think? Good day, Oded R.
The thing to do, and I'll work on it, is to find out why it's enabled by default. It might be for reasons which are not applicable for fedora, but meaningful for upstream. e.g. solaris issues. Printer memory issues from 1980 :-), or something important which means it has to stay enabled by default. Looking at our history we actually did have it disabled by default in an older 1.1.3 fedora release but this didn't get migrated over on our changeover to 2.0.X