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"
Doens't recognise the command.
Should recognise the path and open the OpenOffice.org Printing Admin, SPadmin,
which exists in the following path:
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
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
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
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,
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,
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/
Sorry, it would be much easier to just go directly to:
(the previous was the site of the project, not of the download).
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
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?
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