In Italy there are too many commercial software, for fiscal accounting, who use to output the official documents only for pcl native printers or with additional modules (no low cost, obliviusly) can generate pdf files. So is useful to have in cups the conversion of pcl to postscript for printing or to direct sending fax via cups/hylafax as I do or to use low cost printers. Therefore if it is possible to arrive quickly to the release in the portage it could be useful to the spread of linux in a working within for now forced to use the products of M$ by law obligation. The ebuild is simple because the ghostpcl has the same dependencies of the old ghostscript 5 and I have patched only to correct the windows/fonts path to a posix accettable form and added the mime configuration and filter for cups.
Created attachment 78959 [details] ebuild
Created attachment 78960 [details] complete release files in tbz2
I also need ghostpcl to facilitate communication with the US Mortgage industry. Years ago mortgage lenders would create and print mortage packages using M$ software and they would FedEx the printed documents to the Closing Agent. Now they have moved towards electronic transmission. Rather than create their documents in pdf (and purchase a licence for Acrobat Creator for each desktop) or convert pcl to pdf (and then proofread voluminous legalese for improper format conversion) they have resorted to using pcl files as a portable standard. Although Windows prints directly to pcl, it does not seem to be able to display or recognize .pcl files, however. So over a half dozen companies have sprung up offering WebPostServices for pcl files. Typically, the client is sent an email directing them to create an account from which they can then download their mortgage document as a modified pcl. Typically each company compresses the pcl and encrypts it and supplies a proprietary print utility for unzipping/unencrypting the pcl file, which can then displayed/printed. Some of these utilities will run partially under Wine. For example, eLynx' .elx files can be unencrypted using their elxprint.exe (installed in c:windows/Program\ Files/elynx/WebPost/). The program runs and aborts with an error, but the pcl file is left c:/windows/windows/temp/<somefile>.pcl This pcl file can be sent to a pcl-capable printer configured as a raw printer under cups. However, it is not possible to change the printing parameters (page size, print tray, resolution, etc). So it would be nice to convert to pdf with pcl2pdf and then print with my usual cups print driver. The new version of ghostpcl can be downloaded from the link on Artifex' download page http://www.artifex.com/downloads/ ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/GhostPCL/ghostpcl_1.41p1.tar.bz2 I tried copying the current ghostpcl-1.41.ebuild to ghostpcl-1.41p1.ebuild and then remaking the digest (ebuild ghostpcl-1.41p1.ebuild digest) but I kept getting an error about # ebuild ghostpcl-1.41p1.ebuild digest !!! app-text/ghostpcl-1.41p1 does not follow correct package syntax. So I then changed the ghostpcl-1.41.ebuild: MY_P=${MY_PN}_${PV}p1 and rebuilt the digest for ghostpcl-1.41.ebuild and then emerged ghostpcl-1.41p1 for ~x86 without error. However, when I try running pcl6 or pcl2pdf I get an error about fonts: No built-in fonts found during initialization and I am neither able to view or convert a pcl file. THANKS for any ideas if anyone else is using ghostpcl successfully.
Found out the cause of my font problem. I needed to "export PCLFONTSOURCE=/usr/share/fonts/pclfonts" before running pcl6 or the shell scripts pcl2pdf and pclpdfwr But there are bugs in the pclpdfwr engine, since although I could display two mortgage packages using pcl6, in one instance I got a segmentation fault when trying to convert a pcl document to pdf, and in another the pcl2pdf program just hung after creating a 4.0K pdf file.
(In reply to comment #4) > Found out the cause of my font problem. > I needed to "export PCLFONTSOURCE=/usr/share/fonts/pclfonts" > before running pcl6 or the shell scripts pcl2pdf and pclpdfwr It was explained in the message at the end of ebuild. ;-) Later I will repost new and revised ebuild. The ebuild was only a test it try to patch (with a wrong/brutal mthod) configurations files from other packages and to work correctly is needed to modify the related ebuilds (cups and hylafax)or add a "pcl" use flag. Especially the mime definition is wrong but because I use it only to convert some old prints (the productor of my accounting and tax evaluation software has imposed to buy a new licence with this module) now so I have not fix them. > But there are bugs in the pclpdfwr engine, since although I could display > two mortgage packages using pcl6, in one instance I got a segmentation fault > when trying to convert a pcl document to pdf, and in another the pcl2pdf > program just hung after creating a 4.0K pdf file. can be a problem with fonts (have you some dedicated fonts on windows?) or with the gcc 4.x compiler or a malformed input (all my computer are using hardened and glibc-compat20 use is set, so I can test only on 3.x). Try to post an example and run direcly pcl6 not the pcl2pdfwr script. Note that the command line paremeter is strictly "-sOutputFile" not as in ghostscript.
Created attachment 181114 [details] app-text/ghostpdl/ghostpdl-1.52.ebuild I'm attaching my ghostpdl-1.52.ebuild (please notice it's ghostpdl instead of ghostpcl). I've had to add dependencies if the X use flag isn't set, because this package depends on X libraries, regardless of whether you may use X, and there's no configure script to easily turn it off. I also added the urwfonts package, as it seems to have separated in ghostpdl. I've also simplified the variables a bit, no use for MY_PN and MY_P. I had add -j1 to emake, as it puked on me several times when things were built in parallel. Anyway, I hope this helps you guys.
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Heuristics show that no Gentoo developer has commented on your ebuild. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Is anyone still interested in this package?
Yes, we have this package also for archiving of old datas from some iSeries. But in the meentime, we have a newer version of the package, if it helps, i can post it. This bug is so old, i have writen my own ebuild since 4 years for this package ...
(In reply to comment #9) > Yes, we have this package also for archiving of old > datas from some iSeries. > > But in the meentime, we have a newer version of the package, > if it helps, i can post it. Please attach it and I'll have a look.
Created attachment 300481 [details] app-text/ghostpdl/ghostpdl-9.00.ebuild This is what I have been using in production in order to convert old PCL documents into postscript for a year now. I tried ghostpdl-9.01 but it was broken, and since 9.00 was works fine, I haven't taken the time to look at the later releases. It looks like 9.04 is out, whatever that is worth. This also needs a little patch file that fixes paths for urwfonts to fit within gentoo filesystem layout. I'll attach it in a bit.
Created attachment 300483 [details] app-text/ghostpdl/files/fontsdir-9.00.patch This patches the path for the fonts to the right place.
*** Bug 409023 has been marked as a duplicate of this bug. ***
Something for the printing team to think about in case of adding: as the tarball contains ghostscript of the same version, perhaps it could be shared between ebuilds ?
I don't care about pcl, but I understand that the GhostXPS source code is included in the same GhostPDL package. Please make sure the ebuild also installs the gxps binary (maybe some USE flags are appropriate?)
Created attachment 308809 [details] app-text/ghostpdl-9.05.ebuild Here is an ebuild that builds ghostpdl-9.05, which implements an xps use flag for those that want xps. It requires files/fontsdir-9.05.patch. It works well and I'm using it on production.
Created attachment 308811 [details] app-text/ghostpdl/files/fontsdir-9.05.patch Patch file for proper urwfonts placement
Created attachment 308817 [details] app-text/ghostpdl/ghostpdl-9.05.ebuild I noticed the gsvg executable and added the svg use flag to get it. Also, I noticed that gsvg and gxps are built automatically as part of the "all" target, so I removed the redundant call to it.
Just a note, ghostpdl-9.06 is available. Changing the version number on the ebuild (and fontsdir patch) works just fine. As far as the patch is concerned, does the version number actually need to be part of the filename? I would think that it would be easier to not include it so that future updates only need to worry about the ebuild itself. (Don't quote me on that though, there very well may be some reason for it that I am unaware of :P)
You're right, the patch filename doesn't really need to have the version number in it. It is just a practice I'm used to doing, as it makes sure that the patch is reviewed to still work with the new versions -- the code might change and the patch might puke.
*** Bug 447266 has been marked as a duplicate of this bug. ***
Created attachment 375142 [details] 9.14 ebuild Here's an updated ebuild for ghostpdl 9.14. Comes with absolutely no warranty :) Main changes : urwfonts can't be downloaded from mirror.cs.wisc.edu anymore - unknown host, even though the links are still showing at http://www.ghostscript.com/GhostPCL.html The ghostscript people say urwfonts are now included in the ghostpdl archive (in fact it looks like they were there in version 9.05 too) and I'm installing them. Then there's also media-fonts/urw-fonts in portage... I don't know if it's related, and I'm not touching it. There was an einfo in the ebuild that referred to its location, but was inaccurate (corrected now).
Created attachment 375144 [details, diff] 9.14 fontsdir patch Updated patch file
Created attachment 480100 [details] app-text/ghostpdl-9.21.ebuild I am only interested in the gxps utility. So I did not test any of the other functionality. But I updated the ebuild to the current version.
Created attachment 480102 [details, diff] app-text/ghostpdl/files/fontsdir-9.21.patch the adapted patch for the 9.21 version.
