alternative solution to GS [ The Path to the Desktop]

On Wednesday 13 August 2003 08:29, James Richard Tyrer wrote:
|  Vadim Plessky wrote:
|  > Hello James,
|  >
|  > I need to say that I tend to agree with majority of the things Havoc
|  > wrote in his mail.
|
|  I guess that to me it sounded too far off in the future.  Like it would
|  come to pass about the time Plan-9 was a common OS. :-)

Who knows? :-))

|
|  > GhostScript is kind of legacy application, IMO. We still need it, but I
|  > hope we would be able to get rid of GS in nearest future.
|  > Most of GS developers are working on Windows platform, and they DO NOT
|  > CARE about Linux/UNIX. Believe me, I have asked them about
|  > FontConfig/unified font configuration with other Linux apps, and that
|  > was the answer.
|  > Ok, may be the answer was "if you implement this, we can adapt", but
|  > they are not going to implement FC compatibility on their own.
|
|  That isn't very encouraging.  But for now at least, either they adopt FC
| or FC & XFree86 need to support GhostScript.  That is, a program: mkfontmap
| needs to come with XFree86/FontConfig.  Setting the two search paths is a
| problem because you can't (AFAIK) go backwards on the execution tree
| (towards init) to set environment variables.  But, features to evaluate the

ok, based on my experience working for one famous printer & copier company 
(Xerox), I can tell you that there is a very nice & elegant solution (to get 
rid of GS): print to Native PostScript printer.
Think of Xerox Document Centre series (DC 330/340, new 4xx series), and 
N-series of laser printers from Xerox. All N-series printers support 
PostScript (andf it's native Adobe PS, BTW)

Now I work for HP (but don't deal with printers, I am doing Networking 
Business and compete with Cisco :-), and can tell you that HP also has a lot 
of networking printers. Majority of those printers support PS, too.
It's not native Adobe PS, but PS support in those models should be o.k. to 
handle Qt/KDE-generated PostScript

| font paths and set the GS paths could be added to FontConfig so that you
| just called: fc-cache with a parameter in profile (just after it sources
| the 'profile.d' scripts, I think), and it would keep a copy of and then add
| the directories to GS_LIB or GS_FONTPATH depending on whether or not they
| had a "Fontmap" file  It would have to check that it didn't make
|  duplicates. If this were written so that there was a library interface,
|  then the only change you need to make to GhostScript is that instead of
|  reading the environment variables from the system, it makes a call to
|  FontConfig to get them.  This should be simple to add to FontConfig and
|  GhostScript.

But as I said, GS developers focused on their problems (and understanding what 
GS is for).
AFAIK, they target GS at Embedded PS market (think of modern RIP processors, 
mostly for high-end color printers/printing machines)
Embedded PS is pretty much different from Desktop PS requirements.

|
|  > Xr/Xc platform (now renamed to "Cairo") is very powerful rendering
|  > platform based on PostScript and SVG primitives, with possibility to
|  > support export to PDF in the future.
|
|  Yes, I understood that they planed PostScript and PDF export.  But, I
|  didn't see any mention of a native file format.  If it is going to replace
|  GhostScript for printing, it must be able to save to a file and then
| render the file.

I think native format (for Xr/Xc/XSVG, now renamed to Cairo) is SVG.
Or XML, if you like that better. It would be better to ask on Cairo mailing 
list for details, I guess Carl can make some comments.

|
|  > CUPS is working like a daemon already for some time (at least on my
|  > computer) Several Linux distributions (in particular: Mandrake) ship ESP
|  > (a-ka: CUPS-optimized) GhostScript as standard GS interpreter.
|  > So, CUPS/GS integration is already happened for users of those distros.
|
|  I don't think that CUPS and GhostScript are very well integrated.  CUPS
|  appears to require a modified GhostScript -- they don't just build in an
|  additional device.  Perhaps this isn't the case, but I was unable to build
|  GS-8.10 with the CUPS device.

I use ESP GS (part of Mandrake), have rebuilt it from Source RPM which is 
available from CUPS/ESP GS web site.
That SRPM is pretty generic and I guess you can build it correctly on any 
modern Linux (UNIX) system.

|
|  And, I see no solution here for the problem with CUPS and fonts installed
|  in the $HOME directory.  CUPS doesn't call GhostScript as the user that
|  submitted the job so there is NO way to find the user's private fonts.  I
|  would say that users having private fonts was a bad idea (perhaps it *is*)
|  but FontConfig has made provisions for them.
|
|  I'm really not sure how FontConfig deals with the user fonts, but
|  obviously, it needs to know which user if it is going to find the fonts!

IIRC, FC searches for User fonts in ~/.fonts os something like this.
I guess reading FC man page would bring up an answer.

|
|  --
|  JRT
|

-- 

Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net


Kde-cafe mailing list - [email protected]
http://ofb.biz/lists/listinfo.cgi/kde-cafe

DISCLAIMER: The views expressed on this mailinglist are the personal
opinions of the author and do not represent OfB.biz: Open for Business, KDE or the author's employer.