xorg removal of Display PostScript - Xwindows

This is a discussion on xorg removal of Display PostScript - Xwindows ; I am a software developer, and have an app that relied on the X11 Display PostScript (XDPS) extension. I recently upgraded a Linux system to SuSE 10.1 (xorg 6.9) and was surprised to find my code no longer supported. I ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: xorg removal of Display PostScript

  1. xorg removal of Display PostScript

    I am a software developer, and have an app that relied on the X11
    Display PostScript (XDPS) extension. I recently upgraded a Linux system
    to SuSE 10.1 (xorg 6.9) and was surprised to find my code no longer
    supported. I found some comments by a Juliusz (jch@pps.jussieu.fr)
    that noted that XDPS was obsolete as of xorg 6.9 and referred to
    Cairo and some other libraries that are a putative replacement
    for XDPS. I have some questions about this and am hoping that
    someone in this newsgroup can perhaps answer them for me.

    My app is actually pretty small potatoes, the XDPS features are not
    heavily used and they were always a kludge, so it's no big deal for
    me to rewrite them if I need to. However, our project has always
    done extensive on-screen previewing of PS image files prior to printing
    and I am curious as to how this is now implemented in Linux and
    Solaris. My SuSE 10.1 system apparently still has working gv and gs
    (ghostscript) programs, and clearly they are not using the XDPS
    extension. I ldd'd them and they do not appear to be using Cairo,
    either. Why are these PS previewers still working even with the XDPS
    extension removed? Do they actually use their own built-in (client-side)
    PS interpreter/renderer?

    I want to steer our group's software development and data processing
    activities in a direction which has the greatest chances for long-term
    support under Linux and Solaris via the open-source community. Is
    ghostscript still the only (or best?) show in town for on-screen
    previewing, what is its likely future, and how is that being affected
    by the removal of XDPS support from xorg?

    I have done some cursory looking around in Cairo, and although it
    seems to be able to write PS output it's not clear to me that there
    is any way of feeding it an arbitrary PS input file (short of writing
    your own interpreter and calling Cairo's rendering functions as needed,
    which would be a mammoth undertaking well beyond our scope). Is there
    any widely available API out there for Linux/Solaris that will allow
    you to stream arbitrary PS input to a library function and render it into
    an X11 drawable?

    Thanks!

    Roger Davis
    rbd at hawaii.edu

  2. Re: xorg removal of Display PostScript

    In article ,
    Roger Davis wrote:
    >Why are these PS previewers [gv and gs] still working even with the XDPS
    >extension removed? Do they actually use their own built-in (client-side)
    >PS interpreter/renderer?


    Yes. gs *is* a PS interpreter/renderer, and has a driver that runs using
    basic X calls. gv calls gs.

    --Paul Vojta, vojta@math.berkeley.edu

  3. Re: xorg removal of Display PostScript

    vojta@math.berkeley.edu (Paul Vojta) wrote:

    >In article ,
    >Roger Davis wrote:
    >>Why are these PS previewers [gv and gs] still working even with the XDPS
    >>extension removed? Do they actually use their own built-in (client-side)
    >>PS interpreter/renderer?


    Kind of the other way around. According to
    http://www.gnustep.org/developers/DPSbench.html, XDPS is a client of
    GhostScript (gs).
    ----------------------------------------
    Aandi Inston quite@dial.pipex.com http://www.quite.com
    Please support usenet! Post replies and follow-ups, don't e-mail them.


  4. Re: xorg removal of Display PostScript

    quite@dial.pipex.con (Aandi Inston) writes:

    >>In article ,
    >>Roger Davis wrote:
    >>>Why are these PS previewers [gv and gs] still working even with the XDPS
    >>>extension removed? Do they actually use their own built-in (client-side)
    >>>PS interpreter/renderer?


    >Kind of the other way around. According to
    >http://www.gnustep.org/developers/DPSbench.html, XDPS is a client of
    >GhostScript (gs).



    But on Solaris, the other OS he mentioned, the "Xsun" server (as of S10,
    still the only supported SPARC) still has the Adobe DPS extension but
    the Xorg server (the default and best option on x86, though there's
    still a Xsun also) does not.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  5. Re: xorg removal of Display PostScript

    On Wed, 27 Sep 2006, Roger Davis wrote:

    > I am a software developer, and have an app that relied on the X11
    > Display PostScript (XDPS) extension. I recently upgraded a Linux system
    > to SuSE 10.1 (xorg 6.9) and was surprised to find my code no longer
    > supported. I found some comments by a Juliusz (jch@pps.jussieu.fr)
    > that noted that XDPS was obsolete as of xorg 6.9 and referred to
    > Cairo and some other libraries that are a putative replacement
    > for XDPS. I have some questions about this and am hoping that
    > someone in this newsgroup can perhaps answer them for me.
    >
    > My app is actually pretty small potatoes, the XDPS features are not
    > heavily used and they were always a kludge, so it's no big deal for
    > me to rewrite them if I need to. However, our project has always
    > done extensive on-screen previewing of PS image files prior to printing
    > and I am curious as to how this is now implemented in Linux and
    > Solaris. My SuSE 10.1 system apparently still has working gv and gs
    > (ghostscript) programs, and clearly they are not using the XDPS
    > extension. I ldd'd them and they do not appear to be using Cairo,
    > either. Why are these PS previewers still working even with the XDPS
    > extension removed? Do they actually use their own built-in (client-side)
    > PS interpreter/renderer?


    gv is a just a front-end for gs, which is a PS interpreter that
    renders PS to bitmaps using x11 and other low-level output formats.

    > I want to steer our group's software development and data processing
    > activities in a direction which has the greatest chances for long-term
    > support under Linux and Solaris via the open-source community. Is
    > ghostscript still the only (or best?) show in town for on-screen
    > previewing, what is its likely future, and how is that being affected
    > by the removal of XDPS support from xorg?


    DPS suffers from a number of very basic problems: given arbitrary PS code
    it is impossible to predict the time/memory/font requirements to render
    the artifact. Adobe had hopes that PDF (flatted PS with some enhancements
    to embed fonts and for navigation) would replace DPS, but they never found
    a customer. I think Apple implemented a graphics system that happens by
    some strange coincidence to be very close to PDF, which makes it easy for
    them to do a PDF viewer and create PDF documents.

    > I have done some cursory looking around in Cairo, and although it
    > seems to be able to write PS output it's not clear to me that there
    > is any way of feeding it an arbitrary PS input file (short of writing
    > your own interpreter and calling Cairo's rendering functions as needed,
    > which would be a mammoth undertaking well beyond our scope). Is there
    > any widely available API out there for Linux/Solaris that will allow
    > you to stream arbitrary PS input to a library function and render it into
    > an X11 drawable?


    Look at :

    "The Ghostscript interpreter can be built as a dynamic link library (DLL)
    on the Windows or OS/2 platforms, as a shared object on the Linux platform
    and as a framework on MacOS X." In the past I have built libgs.so on SGI
    Irix and Solaris, but I wouldn't be surprised to find that some
    linux-specific code has crept into current gs, so building the library on
    Solaris might be interesting.

    --
    George N. White III


  6. Re: xorg removal of Display PostScript

    "George N. White III" wrote:
    >
    >DPS suffers from a number of very basic problems: given arbitrary PS code
    >it is impossible to predict the time/memory/font requirements to render
    >the artifact. Adobe had hopes that PDF (flatted PS with some enhancements
    >to embed fonts and for navigation) would replace DPS, but they never found
    >a customer. I think Apple implemented a graphics system that happens by
    >some strange coincidence to be very close to PDF, which makes it easy for
    >them to do a PDF viewer and create PDF documents.


    Apple readily acknowledge that their Mac OS X display model is
    PDF-based; not something like PDF, as far as I can see, but PDF.See
    for instance
    http://developer.apple.com/documenta...0draw%20pdf%22

    In practice few developers get down to the native PDF level. And it
    isn't explicit whether primitive or other complex drawing instructions
    get turned into PDF, or just pass down to a PDF-friendly native
    graphics layer.

    It is less clear whose technology they use.
    ----------------------------------------
    Aandi Inston quite@dial.pipex.com http://www.quite.com
    Please support usenet! Post replies and follow-ups, don't e-mail them.


  7. Re: xorg removal of Display PostScript

    On Sat, 07 Oct 2006 19:48:14 -0300, George N. White III wrote:

    > "The Ghostscript interpreter can be built as a dynamic link library
    > (DLL) on the Windows or OS/2 platforms, as a shared object on the Linux
    > platform and as a framework on MacOS X." In the past I have built
    > libgs.so on SGI Irix and Solaris, but I wouldn't be surprised to find
    > that some linux-specific code has crept into current gs, so building the
    > library on Solaris might be interesting.


    libgs.so works on Solaris, using latest 8.54.

+ Reply to Thread