| | <<<Back 1 day (to 2012/05/16) | 2012/05/17 |
| kens | ray_laptop (for the logs) Yes I did also test ps2write, both in the 'one file per page' mode and in 'server' mode. The number of 'leaked' blocks, and the total allocation on job exit was the same as wehn rendering and did not alter no matter the size of teh input file (in pages) or the number of times it was run. | 07:05.55 |
| chrisl | kens: Am I right in thinking that we haven't killed off pswrite mainly because ps2write can't do EPS output? | 07:27.29 |
| kens | Absolutely correct chrisl | 07:27.43 |
| | We probably can do EPS output, but I haven't coded it. This is especially tru now that we can close the output file, as it means we cna produce multiple EPS files from a single multi=page input. | 07:28.23 |
| chrisl | So we could make pswrite mean ps2write, and the keep the epswrite device? | 07:28.44 |
| kens | I thought epswrite basically was pswrite. | 07:29.05 |
| chrisl | Yes, it would just be name thing, no "real" changes | 07:29.24 |
| kens | Yes we could do that. The scripts already use ps2write not pswrite, you have to set the command line options manually to get pswrite | 07:29.50 |
| chrisl | I'm just asking because henrys asked about killing off pswrite the other day | 07:30.15 |
| kens | I want to kill it off, as soon as we can do eps from ps2write I plan to totally kill it | 07:30.35 |
| chrisl | I've also been wondering how we haven't seen these printer problems before.... | 07:31.40 |
| kens | Which ones, the Ubuntu problems ? | 07:32.07 |
| chrisl | Yes | 07:32.20 |
| kens | There are more ? :-( | 07:32.27 |
| chrisl | Well, the HP filter one has reappeared from a different reporter - I'm hoping he'll be more able to help us track it down | 07:33.06 |
| kens | That would be helpful, certainly | 07:33.19 |
| chrisl | Changing the filter stuff in ps2write looks like a bit of a minefield, though :-( | 07:34.26 |
| kens | I guess our customers (the ones mainly using ps2write) aren't trying to send the output to desktop printers. | 07:34.35 |
| | More than a minefield, it may not be possible. | 07:34.47 |
| | Depends what needs to be done. | 07:34.59 |
| | Its the usual 'object oriented' hands-off spaghetti wher you don't really know what's going on at any moment. | 07:35.29 |
| chrisl | Clearly *someone* tried sending ps2write output to HP printers because they noted filter problems | 07:36.00 |
| kens | Oh yes, I'd forgotten about that. | 07:36.15 |
| chrisl | And I guess it had to be lower spec HP printers because the high-end ones used Adobe back then - and I doubt CPSI would have such fundamental issues | 07:37.19 |
| kens | I'm sure CPSI doesn't have these problems, its undoubtedly a clone rip problem. | 07:37.46 |
| chrisl | The worry with this one is that I think the error occurs on (basically) "currentfile /SubFileDecode filter" - there really shouldn't anything to go wrong there! | 07:39.24 |
| kens | Oh :-( If SubFileDecode doesn't work we're in trouble | 07:39.46 |
| | I wonder if any of us has a HP pritner we could experiment on | 07:40.16 |
| chrisl | I think Henry and Marcos have HP printers - but this problem doesn't affect all HP printers. I find it hard to believe the problem is actually with SubfileDecode - almost *nothing* would work, then | 07:41.32 |
| kens | Nice to see HP as consistent as ever with their printer implementations.... | 07:42.06 |
| chrisl | The printer in question throws an invalidaccess error | 07:42.12 |
| kens | That's a strange error.... | 07:42.24 |
| | Is it possibly because the underlying 'currentfile' is itself compressed ? | 07:43.03 |
| chrisl | I can't see why: SubFiledecode should have/need no knowledge of the data that it's "filtering" | 07:44.09 |
| kens | Well it doesn't, but 'filter' is the actual operator here | 07:44.29 |
| | And if it decides that it can't access the 'file' for whatever reason then invalidaccess is legitimate | 07:44.52 |
| | The file in this case is 'currentfile' but that in itself can be the head of a chain of filters | 07:45.16 |
| | If one of those filters decides you can't add another one, then it could cause the problem | 07:45.33 |
| chrisl | Which is why we thought (previously) that it might be another case of the data source being wrongly closed when a filter was closed. | 07:46.17 |
| kens | Makes sense | 07:46.29 |
| chrisl | In as much as dealing with such a heap of sh*t printer can make "sense"...... | 07:47.07 |
| kens | Well, yes.... | 07:47.17 |
| chrisl | It may well be worth asking Henry and Marcos to try a file on their printers (assuming they are not PCL only) | 07:48.02 |
| kens | Sounds like a good idea to me | 07:48.13 |
| chrisl | I'll try to remember later in the day | 07:48.32 |
| kens | OK | 07:48.42 |
| | I'll try and remind you :-) | 07:48.51 |
| chrisl | Okay, next thing: that issue with XPS, pdfwrite and fonts....... | 07:49.55 |
| kens | pdfwrite ? You mean ps2write ? | 07:50.16 |
| chrisl | Well, basically same thing.... but okay | 07:50.51 |
| kens | Apparently not, pdfwrite works | 07:51.00 |
| chrisl | With embedding the base 14? | 07:51.26 |
| kens | Maybe I'm thinking of a different problem, are we talking about a bug report or a support email ? | 07:51.49 |
| | I've had btoh recently | 07:51.54 |
| chrisl | The mail from Aaron | 07:52.10 |
| kens | Is this the 'NeverEmbed' problem ? | 07:52.12 |
| | Right, I categorised that as PCL not CPS | 07:52.24 |
| | XPS | 07:52.29 |
| chrisl | Yes. I thought you'd added something for the PCL case to allow control of embedding base 14 fonts | 07:53.28 |
| kens | I don't remember doign so | 07:53.40 |
| | Even if I did, the code he's using won't work, because its PostScript..... | 07:53.55 |
| chrisl | No, my vague recollection was that it was a hard coded list, so it needed source changes and a rebuild - but maybe you'd just thought about *how* to do it, rather than actually did it | 07:54.54 |
| kens | There's a hard ocded 'white list' of exceptions to the DRM for font embedding, but that's not the same thing | 07:55.16 |
| | But there is a vague tickle there in the memory | 07:55.30 |
| | I suppose I should go look. | 07:55.46 |
| | Is there a way to 'grep' the Git history ? I was trying to find one yesterday | 07:56.31 |
| chrisl | No, this was definitely not that. IIRC, this was a downloaded PCL font, using a base 14 name, but the usual "random" PCL encoding. Because it was a base 14 name, pdfwrite didn't embed it, and the output was nonsense | 07:56.41 |
| | er, I think you can do a basic grep with something like git log -grep <pattern> | 07:57.07 |
| kens | That'll do | 07:57.15 |
| | I was hoping there was a built in way | 07:57.31 |
| | No, that just gives me an error | 07:57.56 |
| | 'unknown revision or path...' | 07:58.07 |
| chrisl | Hmm, maybe "--grep"? | 07:58.30 |
| kens | THat works better :-) | 07:58.48 |
| chrisl | FWIW, you can also go to http://git.ghostscript.com/?p=ghostpdl.git;a=summary and use the "search" | 07:59.43 |
| kens | Well I can't find any commit message that looks vaguelly relevant | 08:00.37 |
| chrisl | Well, as I say, maybe you were just kicking some ideas around | 08:01.07 |
| kens | lets try Bugzilla | 08:01.11 |
| chrisl | kens: don't spend a lot of time looking - I'm probably mistaken...... | 08:04.01 |
| kens | Well, I can't find anything so far :-) | 08:04.26 |
| | Anywya, it takes us back to a sore point, which is that there is no way to override many of the pdfwrite settings when there is no PostScript interpreter present. I'm sure I've raised this before. | 08:05.06 |
| chrisl | Well, we could make pdfwrite have the PS interpreter as a dependency....... | 08:05.57 |
| kens | But that would make all builds language switch (if they included pdfwrite) and the language switch build doesn't work..... | 08:06.24 |
| chrisl | Basically, whatever we do *short* of always including the PS interpreter, they're command line will never work | 08:07.16 |
| kens | Yes, but I think they'd be happy with an approach which worked. At the moment there isn't one. | 08:07.43 |
| | I *think* the problem you are remembering is to do with PCL where the standard font name is used, but the font is not embedded. In that case we used a lookup table to convert the URW font naems to standard font names. | 08:08.36 |
| | Because otherwise we end up with a PDF requesting URW font names | 08:08.58 |
| chrisl | Oh, could be. | 08:08.59 |
| kens | http://bugs.ghostscript.com/show_bug.cgi?id=692608 | 08:09.41 |
| | Notice that the customer is using -dEmbedAllFonts=false to suppress the base 14 | 08:09.59 |
| chrisl | Okay, so vaguely related, but not really...... | 08:10.41 |
| kens | It is related, I'm just not sure exactly how :-) | 08:10.56 |
| chrisl | PCL, fonts, pdfwrite .... close enough ;-) | 08:11.30 |
| Robin_Watts | boots his linux VMware thing. | 11:59.28 |
| | Linux needs to update. VMware needs to update. | 11:59.44 |
| | By the time that finishes, will I still remember why I booted it? | 12:00.18 |
| kens | :-) | 12:00.32 |
| Robin_Watts | reboot. bbs. | 12:01.57 |
| | lunchtime. | 12:52.09 |
| | Did we have a customer asking about linearisation recently? | 13:43.43 |
| | I was wondering if it was worth asking them if they have a method for testing whether a file is linearised or not. | 13:44.08 |
| kens | yes | 13:44.09 |
| | open the file in Acrobatm press control D look fro 'optimised for gfast web viewing' | 13:44.30 |
| Robin_Watts | ooh. | 13:44.41 |
| | Fast Web View: Yes | 13:45.05 |
| sebras | Robin_Watts: yey! :) | 13:45.10 |
| kens | OK so memory isn't perect :-) | 13:45.16 |
| Robin_Watts | kens: That's a great result. | 13:45.32 |
| | I haven't put a hint stream in there yet. | 13:45.40 |
| kens | NP its what I've been using for looking at the pdfopt.ps problem | 13:45.44 |
| Robin_Watts | Does gs generate a hint stream ? | 13:45.58 |
| kens | pdfopt.ps does yes | 13:46.05 |
| | Or would, if it wasn't broken | 13:46.11 |
| Robin_Watts | :) | 13:46.16 |
| kens | I cna tell you how to fix it if you need it | 13:46.23 |
| Robin_Watts | No, I just need to write code to do it in mupdf. | 13:46.47 |
| kens | OK | 13:46.56 |
| sebras | Robin_Watts: though it does state in F.2.5 of pdfref17 that the primary hint stream is required. | 13:46.57 |
| Robin_Watts | sebras: Indeed. | 13:47.03 |
| | If it was optional, I'd be ignoring it :) | 13:47.13 |
| kens | Presumably that's the same sort of 'required' that Acrobat usualy ignores.... | 13:47.19 |
| sebras | kens: if adobe had created a pdf validation tool to be used by pdf generator developers then having reader accept any broken pdf would be ok though. | 13:48.44 |
| | as it stands reader is the validator and it accepts anything... | 13:48.57 |
| kens | Yes, but they never did :-( | 13:49.01 |
| | I've considered writing one in the past | 13:49.10 |
| sebras | too late. | 13:49.15 |
| kens | I know.... | 13:49.23 |
| | mvrhel ping | 13:59.35 |
| nygal | hey is there a way using ghostscript in commercial program ? | 14:09.04 |
| kens | Yes, licencce it | 14:09.12 |
| | dwwwwwArtifex licences GS commercially | 14:09.33 |
| nygal | is there a link about licencense model, i couldn't find it | 14:10.36 |
| kens | You need to contact sales@artifex.com I thought that was on the web site, where are you looking ? | 14:11.13 |
| | http://www.artifex.com/indexlicense.htm | 14:12.21 |
| nygal | kens: thanks | 14:12.40 |
| kens | no problem | 14:12.47 |
| | Hmm, I must admit teh ghsotscritp site doesn't seem to have any licenceing information on it Maybe I'm just blind... | 14:18.20 |
| Robin_Watts | A supported commercial version is available from Artifex Software Inc. | 14:19.18 |
| kens | Is there a link ? | 14:19.32 |
| Robin_Watts | ghostscript.com/Ghostscript.html in the second section. | 14:19.34 |
| | "Artifex Software Inc" is a link. | 14:19.47 |
| | But, yes, it could be more front and centre :) | 14:19.57 |
| kens | Ah yes I see. Myabe that should be more prominent, is on the first page | 14:19.59 |
| nygal | tbh, i'm not so sure if GS is suitable for our usage, i was just googling, We're making a commercial whiteboard software, we're importing office files via MS XPS Document Writer (Virtual Printer) but our software is cross platform so we stuck under linux and MacOS so can i use GhostScript for this work ? | 14:25.40 |
| kens | Not for Office files, GS only handles PostScript, PDF, XPS and PCL | 14:26.06 |
| Robin_Watts | nygal: So you want to read XPS and do what with it? Print it? Or render it on a screen? | 14:26.26 |
| nygal | hms, so i still need virtual printer unders linux and macos which is providing ps or pdf , etc ... | 14:26.44 |
| Robin_Watts | oh, sorry, you are looking for an office -> xps converter ? | 14:27.33 |
| nygal | tbh, i'm fine with any format i can render office files into my application | 14:27.45 |
| | no i'm just looking for virtual printer | 14:27.59 |
| | wikipedia redirect to me to ghostscript page so i little lost :) | 14:28.55 |
| kens | Hmm, not sure why. | 14:29.07 |
| | GS isn't a vrtual pritner, though it gets used in a 'simlar' fashion under Linux | 14:29.23 |
| Robin_Watts | AIUI, on linux, apps either produce PDF out themselves, or maybe PS, or they produce bitmaps that the printing workflow wraps into PDF files. | 14:30.16 |
| sebras | kens: maybe the wikipedians are thinking about PDF Creator? | 14:55.24 |
| | it hooks in gs a virtual printer to produce pdfs... | 14:55.39 |
| | s/gs a/gs as a/ | 14:55.50 |
| kens | well it has a vritual pritner certinaly | 14:55.50 |
| | doesn't produce XPS though | 14:55.57 |
| | Nor does GS for that matter | 14:56.05 |
| | the printer rediorection code is redmion | 14:56.56 |
| chrisl | CUPS supports "virtual printer" type capabiilties, but again, doesn't produce XPS | 14:57.23 |
| | or "capabilities" even...... | 14:57.36 |
| ray_laptop | morning, all | 15:41.49 |
| Robin_Watts | Morning ray_laptop | 15:41.50 |
| kens | Hi ray | 15:41.55 |
| Robin_Watts | I hope the timings I sent were OK? | 15:41.59 |
| ray_laptop | Robin_Watts: I haven't seen them yet -- email loading now | 15:42.30 |
| | Robin_Watts: Thanks -- they look good. | 15:44.24 |
| Robin_Watts | fab. | 15:44.31 |
| ray_laptop | Also, the times are much better than what they reproted, given that you are running a 600MHz ARM (8?) and they were running a 1.2GHz (Cortex A8) | 15:46.12 |
| Robin_Watts | yeah, I'm running a cortex A8 too. | 15:46.45 |
| ray_laptop | one never sees 100% of a clock rate difference (usually due to relative RAM speeds), but they should be close to double the speed | 15:47.52 |
| Robin_Watts | Damn. Damn. Damn. | 15:51.34 |
| chrisl | relates to that sentiment......... | 15:52.07 |
| ray_laptop | wow -- a triple | 15:52.08 |
| Robin_Watts | In the linearisation work so far, I'd got away with a single int for each object in the file recording whether it was used for a single page (and if so which one), or for 'many' pages. | 15:52.22 |
| | If it's 'many' then it's a shared object. | 15:52.36 |
| | Unfortunately, for the hint stream, I need to be able to say "page 1 uses these shared objects..." and then list them. | 15:53.05 |
| kens | Yes that's true | 15:53.48 |
| Robin_Watts | So I need to either store a list of objects used by each page, or I need to store which pages each object is used by. | 15:54.35 |
| kens | we generally store objects for each page | 15:55.02 |
| Robin_Watts | I think that would be smaller overall. | 15:55.14 |
| kens | For Page level resources | 15:55.15 |
| Robin_Watts | Do you assume that because an object is in the resources it is used? | 15:55.39 |
| kens | I don't know abou tthe PDF itnerpreter | 15:55.52 |
| Robin_Watts | Or do you actually walk the page contents to know ? | 15:55.56 |
| kens | pdfwrite only stores used objects | 15:56.01 |
| Robin_Watts | ah, you're interpreting. | 15:56.04 |
| henrys | Shelly says he has a bit of time, I did find a pcl bug for him to work on but if somebody has something else let me know. | 15:56.18 |
| chrisl | henrys: we were going throw the jbig2dec security reports over to him | 15:56.53 |
| Robin_Watts | I'm assuming that if it's in the resources it's used. To figure out usage in more detail would require me to rework the interpreter slightly. | 15:56.55 |
| henrys | chrisl:is that already set to bountiable? which bug? | 15:59.33 |
| chrisl | henrys: I don't know if a bug was ever entered for it | 15:59.59 |
| henrys | why am I not remembering this? Did it come into support? | 16:00.54 |
| chrisl | it was from one of those security audit companies - I'm trying to find the e-mail now..... | 16:01.19 |
| henrys | don't answer the first question ;-) | 16:01.21 |
| | I found it | 16:02.35 |
| | marcosw never processed it these reports are often bogus I think we should try to reproduce it before creating a bug. | 16:03.56 |
| chrisl | AH, me too.... I still don't know if a bug was posted..... | 16:03.57 |
| | henrys: I assumed marcosw would triage the problems - I'm slightly inclined to afford a bit more credit to this one since they actually include the test files for the issues | 16:05.41 |
| henrys | chrisl:I sent him mail, if there isn't a bug it'll be in by tomorrow and I'll make sure it's bountiable. | 16:06.56 |
| chrisl | henrys: cool - I only remembered it because we'd talked about giving it to Shelly on here, and he asked me about it a while back...... | 16:07.50 |
| kens | Time to go, goodnight all | 16:16.36 |
| Robin_Watts | ray_laptop: Urm... | 16:38.30 |
| ray_laptop | Robin_Watts: yes ? | 16:38.40 |
| Robin_Watts | In your mail you say "pgmgray" - presumably you mean "pgmraw" ? | 16:38.57 |
| | And I think pgmraw has special code in to spot the /dev/null case. | 16:39.16 |
| ray_laptop | oops. Yes, pgmraw | 16:39.20 |
| | Robin_Watts: only to the extent that it doesn't do the 'fwrite' to /dev/null -- it still performs all of the rendering | 16:39.57 |
| Robin_Watts | Right. | 16:40.13 |
| ray_laptop | Robin_Watts: the other device that has this is the 'bit*' devices (such as -sDEVICE=bit -dGrayValues=256) which should give timings identical to pgmraw | 16:41.10 |
| Robin_Watts | yeah, I added it somewhere else too. One of the planar ones possibly. | 16:41.36 |
| ray_laptop | Robin_Watts: that would make sense for devices that we want to use for timing benchmarks and leave out OS I/O overhead | 16:42.08 |
| | Robin_Watts: at least the log I attached (from you) has the correct command line options :-) | 16:43.02 |
| | hopefully my typo won't confuse him too much. | 16:43.33 |
| | but the performance difference between yours and his are a concern. They're probably writing the data to HDD or something | 16:44.27 |
| | writing an 8Mb gray image to HDD in 0.32 seconds would be about 25Mbytes/sec | 16:47.22 |
| Ch3rryC0ke | Hey there-- I'm wondering if anyone has thought about or is working on porting the MuPDF viewer to WinRT ? | 22:01.56 |
| sebras | Ch3rryC0ke: I haven't heard of mupdf compiled for winrt, but there is a viewer that ought to work in win7 on mupdf.com | 22:12.50 |
| Ch3rryC0ke | sebras: Thanks, I've seen that. I'm interested in building a Win8 metro app that has PDF viewing & annotation capabilities. | 22:15.02 |
| | So I was thinking of porting the draw code to the new WinRT API.. | 22:15.37 |
| | ( AFAIK, I can't just use the existing WinForms viewer component in WinRT...) | 22:17.06 |
| sebras | Ch3rryC0ke: a winrt-port is not planned as far as I know, but if you come up with a patch then please submit it! :) | 22:17.22 |
| Ch3rryC0ke | How big of an undertaking do you think it will be? I'm making my way through source now and trying to understand etc.. | 22:17.48 |
| sebras | Ch3rryC0ke: I have no idea, I'm a linux guys so I'm not at all familiar with win APIs. | 22:18.25 |
| Ch3rryC0ke | Sure, I meant more how big do you think the draw code is | 22:18.40 |
| | in mupdf | 22:18.43 |
| sebras | though the existing win32 app is located over at apps/win_main.c | 22:18.59 |
| | which is less than a thousand lines. | 22:19.22 |
| Ch3rryC0ke | sebras: Do you know what drawing API is used for the actual PDF rendering? | 22:23.53 |
| sebras | Ch3rryC0ke: mupdf to an image pixmap and then you have the function winblit() in apps/win_main.c that reads this image and does whatever conversion is necessary for windows API. | 22:26.08 |
| | s/mupdf to/mupdf draws to/ | 22:26.18 |
| Ch3rryC0ke | Ah I see-- so it's always displaying an image, not a result of draw calls to GDI or something like that? | 22:26.44 |
| sebras | Ch3rryC0ke: no, it doesn't access GDI directly. | 22:27.06 |
| Ch3rryC0ke | Ah OK-- thanks. That changes my approach quite a bit... | 22:30.11 |
| | Is there any support in mupdf for writing back to the PDF file? | 22:30.51 |
| | For example, removing pages or adding annotations? | 22:31.06 |
| sebras | Ch3rryC0ke: not in mupdf 1.0. | 22:32.12 |
| Ch3rryC0ke | Is that on the roadmap or being worked on? | 22:32.35 |
| sebras | it's being worked on right now. writing objects to pdf files anyway. | 22:32.58 |
| | more specifically I think the ongoing work is related to saving data for filled forms. | 22:33.36 |
| | so I'm not sure about adding new annotations. | 22:33.51 |
| Ch3rryC0ke | Gotcha-- is that available in source, or worked on privately and merged later into an official release? | 22:34.29 |
| sebras | it may be in the git repository somewhere over at git.ghostscript.com | 22:34.54 |
| | I haven't been tracking that development so I don't know the details. | 22:35.58 |
| Ch3rryC0ke | Ok-- thanks a lot. Is there a mailing list I should join? | 22:36.28 |
| sebras | not really, no. just be a hangaround here and ask questions as you go. | 22:36.52 |
| Ch3rryC0ke | Ok, will do | 22:37.28 |
| sebras | most of the time there is someone here that may be able to help you if you get stuck. | 22:37.48 |
| | I'm just a hangaround myself. :) | 22:37.55 |
| Ch3rryC0ke | Thanks for your help so far :) | 22:38.45 |
| sebras | Ch3rryC0ke: sure, np. | 22:40.30 |
| Robin_Watts | Ch3rryC0ke: I'm the one working on saving at the moment. | 23:02.43 |
| | I believe saving pdf files is in the current git. | 23:02.57 |
| | I'm working on the ability to save linearized files at the moment. | 23:03.10 |
| | Adding new annotations can be done, but it might be a little more "internal" than you'd like (i.e. you may have to work at the PDF object level) | 23:03.46 |
| sebras | Robin_Watts: isn't paul also working on that for saving form data? | 23:08.41 |
| Robin_Watts | sebras: AIUI, no. Paul writes form data back into the PDF itself. | 23:13.56 |
| | Thus saving the PDF saves the PDF form. | 23:14.07 |
| sebras | Robin_Watts: oh, so the form data doesn't relat to the annotations at all? | 23:20.26 |
| Robin_Watts | form data goes into annotations. Paul synthesises appearance streams for them. | 23:22.06 |
| | and the whole lot gets saved back. | 23:22.19 |
| sebras | ok. I was under the impression that this required creating new annotations as well, sorry for the confusion and thanks for the explanation. | 23:24.01 |
| Ch3rryC0ke | Robin_Watts: Thanks for the info! So when you say the PDF object level-- are there already data structures in place for annotations and saving, or do I need to create those? | 23:47.22 |
| Robin_Watts | We have some limited structures for annotations; enough for us to render them etc. We don't have an interface in place to allow people to edit them neatly yet. | 23:48.34 |
| | but you can always get to the actual object structure of the underlying PDF file - so you can step through that and make changes. | 23:48.58 |
| | Forward 1 day (to 2012/05/18)>>> | |
IRC Logs