| | <<<Back 1 day (to 2016/03/16) | 20160317 |
| noric | Hello, I use Ghostscript with the KDE print-to-file virtual printer. I would like to change the default print margins, but I can't find where such settings are stored. I can successfully change the margins in the KDE gui, but they revert to default every time. Where are the default settings stored, so that I can change them? Thanks. | 11:13.23 |
| | PS: the KDE devs believe this setting is managed by Ghostscript and not by KDE itself. | 11:14.14 |
| | I've looked into /usr/share/ghostscript/9.10/lib/ but I couldn't find anything useful. | 11:14.59 |
| kens | I have no idea, we don't have anything to do with KDE. I have no idea how anything is sent to Ghostscript, if you can find out : | 11:15.38 |
| | 1) What file is being sent to Ghostscript, and provide an example | 11:15.38 |
| | 2) What command line is being used ot invoke Ghostscript | 11:15.38 |
| | I may be able to say more | 11:15.38 |
| | There are, however, no 'default margins' in Ghostscript, it can and will print right to the edge of the media. Any margins must be set elsewhere | 11:16.07 |
| | Note that if you can change the KDE settings, and ths has an effect, then it can't be a *Ghostscript* setting. If they revert back again, then clearly its a setting in KDE. Possibly it is reading the PPD, but I have no idea where it is getting the values from. Presumably the KDE developers could tell you that. | 11:17.28 |
| noric | Thanks, I'll try to get some more information from the KDE devs. It indeed looked strange to me that this was a Ghostscript "problem". Thank you very much. I'll let you know if I find out something. | 11:18.49 |
| chrisl | I think the PPD suggestion is a good one | 11:19.13 |
| | Can't remember where PPDs are stored..... | 11:20.12 |
| noric | Yes, the ppd is how I usually change the settings of my "real" printers. But I can't find a ppd for the print-to-file printer. | 11:20.19 |
| chrisl | possibly, that's the problem! | 11:20.38 |
| noric | They are usually in /etc/cups/ppd/ | 11:20.57 |
| chrisl | Ah, yes. Is the print to file thing a KDE feature, or a cups feature? | 11:21.32 |
| noric | It's a KDE feature. Not cups. | 11:21.53 |
| | I'll try a bruteforce ppd search. | 11:22.14 |
| chrisl | I'm fairly sure you can do a print to file with cups, maybe that would be better | 11:22.36 |
| | FWIW, pretty all our devices, that I can find, have default margins of [0,0] - i.e. as kens said, print over the entire media area | 11:23.28 |
| noric | Yes, I've tried that. But the cups pdf printer is somewhat deprecated and produces bad quality pdfs. | 11:23.28 |
| chrisl | Hmm, "print to file" is not the same as "print to PDF", to me, anyway.... | 11:24.36 |
| kens | Not to me either :-) | 11:24.46 |
| | Ghostscrip ships with a PPD file, mostly for the benefit of MS WIndows users, its 'possible' that the KDE implemenetation uses it, there's no way we would know | 11:25.26 |
| noric | The print-to-file service lets you choose between pdf and postscript. | 11:25.27 |
| chrisl | I don't have a KDE system and, tbh, I'd rather not install one if I don't have to...... | 11:26.27 |
| noric | Ken, are you talking about /usr/share/ghostscript/9.10/lib/ghostpdf.ppd | 11:26.29 |
| | ? | 11:26.32 |
| kens | CUPS uses PDF as its intermediate sppol format, I sincerely hope its neither 'deprecated' nor poor quality | 11:26.40 |
| | noric that's the PPD we ship yes | 11:26.53 |
| | I notice we actually ship 2 others as well, never noticed that before | 11:27.38 |
| noric | As you guys are saying, that ppd has 0 margins. It must be overridden one way or another. | 11:27.56 |
| chrisl | CUPS used to treat it's PDF output as a Postscript printer: so it would spool to a PDF, convert that to Postscript and then convert the PS back to PDF..... not surprisingly, that could produce poor results. More recently, it "fast tracks" if the file is already PDF, it should just spit it out, without doing all the conversions | 11:28.54 |
| kens | Ghostscript won't impose margins, so any margins you see must be written into the PostScript program it receives, which means the application doing the layout is inserting the margins. Now, it may be reading those margins from somewhere else, but I don't know whwre it would be getting them | 11:29.04 |
| | I don't see any margins in our PPD, there are a couple of page sizes (Note for one) whch have a non NULL imaigingBox though | 11:30.19 |
| noric | I have A4 as default page layout. | 11:31.53 |
| | Which is correct for my country, but doesn't match what's inside the ppd. | 11:32.23 |
| chrisl | Ghostscript will use libpaper to find a default page size | 11:32.50 |
| kens | What do you mean ? The PPD has an A4 media defined | 11:33.00 |
| noric | I mean that the ppd says that Letter is default. I'm given A4 instead, whenever I try to print to pdf. That would confirm that the ppd isn't parced by KDE. | 11:34.50 |
| kens | Yes, that seems like its not using our PPD. It was a guess at best | 11:35.49 |
| noric | I'll try to get more information by the KDE devs. Thank you very much guys. I'll let you know, should you ever use KDE! | 11:36.35 |
| chrisl | tor8: I opened a bug (presently assigned to me) with my comments about the URW release: http://bugs.ghostscript.com/show_bug.cgi?id=696666 | 11:39.11 |
| noric | And thanks Chrisl for your comment about Cupspdf. The last time I tried it was about a year ago. But it's possible that my LTS distribution provided me an old release. | 11:39.35 |
| chrisl | noric: NP | 11:39.52 |
| | tor8: If you can add any comments/complaints/observations you have to that bug, and once we're ready, I'll assign it to Henry | 11:40.15 |
| vtorri | chrisl: why isn't mupdf used in ghostscript ? | 12:19.20 |
| chrisl | vtorri: ghostscript predates mupdf by quite some time | 12:20.08 |
| vtorri | so why mupdf, then ? | 12:21.09 |
| chrisl | vtorri: different target audiences | 12:21.31 |
| vtorri | just extracting the pdf rendering was not sufficient ? | 12:21.34 |
| chrisl | If that were sufficient, why would Ghostscript have all the devices it has | 12:22.42 |
| | vtorri: Ghostscript is primarily aimed at the printing market, whilst mupdf's primary target audience is screen viewing on (relatively) low resource devices | 12:25.06 |
| vtorri | ok | 12:25.27 |
| chrisl | Things have overlapped a bit, but that's the crux | 12:25.50 |
| | vtorri: and, of course, mupdf doesn't handle Postscript | 12:26.53 |
| | vtorri: there's a summary here: http://twiki.ghostscript.com/do/view/Ghostscript/GhostscriptOrMuPDF | 12:27.51 |
| | vtorri: we do have a "some day" project to implement the mupdf interpreter(s) on top of the Ghostscript graphics library - but it's a huge project, and we just don't have the spare cycles to devote to it | 12:29.45 |
| | Right, errands to run, and then training - back later this afternoon........ | 12:39.22 |
| tkamppeter | Hi, who is the principal MuPDF guru here? | 14:19.55 |
| kens | tor8 | 14:20.01 |
| | But it depends on the question | 14:20.18 |
| tkamppeter | kens, it is about mentoring a GSoC project, adding printer support backends to MuPDF. | 14:21.09 |
| | kens, the MuPDF-related project ideas on https://www.linuxfoundation.org/collaborate/workgroups/gsoc/google-summer-code-2016-openprinting-projects | 14:21.50 |
| rayjj | tkamppeter: for linux, I thought most printers used cups raster "drivers" -- I thought I was that mupdf now has "pwg" (cups raster) already | 14:48.49 |
| | tkamppeter: sorry -- I just read the stuff on the link -- looks like the work for the student is the script "hooks" and stuff | 14:52.21 |
| tkamppeter | rayjj, that is true. There are only a few printers where some extra backend could be of help: PCL-XL and PostScript. | 14:52.43 |
| | rayjj, or should I rather let the student create a rastertopxl and a rastertops for cups-filters? | 14:53.34 |
| rayjj | I don't think a PS backend for mupdf is being considered (by us, anyway), but PCL is also in mupdf, and I think Robin_Watts mentioned that it uses PCL-XL | 14:54.06 |
| | but I don't know if it just a PCL-XL wrapper on a image file, or if it is more like the gs "semi hi-level" pxl output | 14:57.23 |
| tkamppeter | Great. so probably I will then have to ask the student for doing the integration in cups-filters. | 14:57.42 |
| HenryStiles | rayjj: pretty sure it's just PCL, but talk to Robin_Watts if he has future plans | 14:59.02 |
| tkamppeter | I think also if one goes the lightweight MuPDF printing stack on a mobile device a print-all-via-rasterto... soultion would be good enough, on the go you do not need the highest quality. You do not shoot a bird through a 10000$ lens and then print it through a phone. | 14:59.40 |
| rayjj | tkamppeter: I just looked at mupdf/source/fitz/output-pcl.c and as HenryStiles said, it _is_ just PCL, and just is a wrapper on a pixmap | 15:01.41 |
| | having a student do a "semi hi-level" pxl type output might be a bit challenging, but the gs gdevpxl.c as an example could provide a head start | 15:02.57 |
| tkamppeter | rayjj, OK. So if I decide that a student works on MuPDF, for example for the semi-high-level backend, who of you would mentor him? | 15:04.57 |
| rayjj | tkamppeter: We should probably let the mupdf team comment on whether or not that is something that they think would be worthwhile, before identifying a "mentor" | 15:06.14 |
| HenryStiles | rayjj, tkamppeter : high level extraction is something currently under development in mupdf, I'll let tor8 and Robin_Watts give an official response, but I don't think that it is a suitable project for a student. | 15:09.38 |
| | tkamppeter: and doing other raster devices is probably trivial. | 15:11.59 |
| | tkamppeter: Under "Add printers output backends to MuPDF", The system that detects network printers... what is the license for that part of the system? | 15:17.39 |
| | it says GPL at the bottom but I thought you said you were trying to go with more liberal licenses on mobile | 15:18.32 |
| tkamppeter | HenryStiles, I am not looking for someone to code how printers get detected in the network. This code is already available. | 15:35.17 |
| | HenryStiles, what I want to get is the possibility to replacs Ghostscript and/or Poppler on a mobile device by MuPDF. | 15:36.06 |
| HenryStiles | tkamppeter: and that is GPL... printer detection? | 15:36.27 |
| mrev1l | hi everyone! May i ask you, what fz_begin_group(fz_device *dev, const fz_rect *area, int isolated, int knockout, int blendmode, float alpha) function does (mupdf) | 15:36.36 |
| | ? | 15:36.39 |
| tkamppeter | HenryStiles, to get at least support for the most common printers I need output in PWG Raster, PCL, PCL-XL, and PostScript. | 15:37.12 |
| HenryStiles | tkamppeter: well if raster is good enough that's really easy. I'm asking about the printer detection code as an entirely separate issue. What is the license? | 15:38.17 |
| tkamppeter | HenryStiles, most printer detection code is in the backends which come with CUPS. I think this is GPL 2 or so. | 15:39.21 |
| | HenryStiles, libcuos and libcupsimage are LGPL 2, the filters which come with CUPS are also LGPL 2, the backends and all the rest of CUPS is GPL 2. | 15:43.39 |
| | HenryStiles, backends detecting network printers are dnssd and snmp. | 15:44.16 |
| HenryStiles | tkamppeter: so now ppd support for mobile printing? | 15:44.40 |
| | tkamppeter: the mupdf stuff is just raster ouput. | 15:45.21 |
| | s/so now/so no/ | 15:46.12 |
| tkamppeter | HenryStiles, cups-browsed is LGPL-2.1+ | 15:51.42 |
| | HenryStiles, on mobile devices we do not hold toms of PPDs. cups-browsed can generate a PPD there, but we do not work with printer-model-specific code or data. | 15:53.14 |
| tor8 | chrisl: the '%' character has a different design in the new times clone | 16:21.06 |
| | what does the real '%' from adobe times look like? | 16:21.28 |
| chrisl | tor8: I'm struggling to find the Adobe fonts I had..... possibly on my old computer | 16:59.28 |
| Robin_Watts | tkamppeter: Sorry, I missed the beginning of this conversation. | 17:06.36 |
| | tkamppeter: The current output options in MuPDF always render to a contone image, and then either output direct from that, or convert to a bitmap image (with some simple thresholding) and then then output from that. | 17:07.32 |
| | We can output to PWG, or to mono PCL, of the things you said you wanted. | 17:08.41 |
| | Outputting a postscript wrapped image should be dead easy (in fact, I might do that). | 17:09.13 |
| | Outputting to high level postscript would be fairly easy, except for the transparency stuff. | 17:09.41 |
| | Outputting to color PCL is on my list to look at (again, just bitmap wrapping). | 17:10.17 |
| | AIUI, it's just the first 2 elements on that list that might involve us. | 17:12.24 |
| | The first one would be basically a matter of helping people to call MuPDF - talking to cups is not in our wheelhouse. | 17:12.51 |
| | The second one would be actual work within the mupdf code. | 17:13.14 |
| | Assuming the students are capable C coders and don't need their hands held 24/7, I think I'd be up for mentoring. | 17:14.11 |
| chrisl | tor8: here the Adobe glyph: http://ghostscript.com/~chrisl/percent001.png | 17:28.30 |
| bofh_ | dumb question, but how does banded rendering differ from the normal way of rasterizing to an image, and when is it useful? | 20:00.40 |
| marcosw | bofh_: banded rendering is useful if there isn't enough memory to hold the entire output image at once. the output image is rendered in bands and then each band is saved sequentially. | 21:37.12 |
| | it's slower than rendering to complete image and osm on host based systems with gigs of memory. | 21:38.06 |
| | it's not used much anymore. | 21:38.23 |
| tor8 | chrisl: thanks. looks like a progression then; the old glyph looks like Times New Roman. | 23:20.46 |
| | Forward 1 day (to 2016/03/18)>>> | |
IRC Logs
