| | <<<Back 1 day (to 2012/05/22) | 2012/05/23 |
| mmilgram | When I print from Firefox or evince under Fedora 16, my postscript printer replaces a few of the characters with a blank box - as though it is missing the character in the font. | 00:28.57 |
| | I captured the network traffic, and extracted the postscript. "evince" displays the postscript correctly, but it also has access to the fonts on the system. | 00:29.06 |
| | The postscript contains some large blocks that look like compressed to ascii code, which I can't easily understand. | 00:29.17 |
| | I'm not even sure which software is generating the postscript. | 00:29.28 |
| mvrhel_laptop | good night all | 07:10.04 |
| kens | mmilgram without seeing the PostScript I can't help you. Unless this is a problem involving Ghostscript I still can't help with your problem. It could be an issue with your printer. | 07:23.56 |
| Robin_Watts | I like this function. I can't put my finger on why, but... https://www.google.co.uk/search?q=exp%28%28-%28%28%28x-4%29%5E2%2B%28y-4%29%5E2%29%5E2%29%29%2F1000%29%2Bexp%28%28-%28%28%28x%2B4%29%5E2%2B%28y%2B4%29%5E2%29%5E2%29%29%2F1000%29%2B0.15*exp%28-%28%28%28x%2B4%29%5E2%2B%28y%2B4%29%5E2%29%5E2%29%29%2B0.15*exp%28-%28%28%28x-4%29%5E2%2B%28y-4%29%5E2%29%5E2%29%29 | 12:11.41 |
| tor8 | Robin_Watts: I'm disappointed. I expected better from you. ;) | 12:19.11 |
| Robin_Watts | sorry :/ | 12:19.24 |
| tor8 | Robin_Watts: back to the update_stream stuff, I'm thinking we should probably start off by just leaving them uncompressed and unencrypted in the stm_buf buffer and encrypt when writing them out. | 12:20.05 |
| Robin_Watts | encrypt when writing out, yes. compress when writing out... need to think about that. | 12:20.38 |
| tor8 | another option would be to compress when adding to the xref, but that means decompressing if we access it again | 12:21.14 |
| | but maybe that's not a problem | 12:21.20 |
| Robin_Watts | I think that whenever we store stuff in objects/in the xref we should keep the PDF in a consistent state. | 12:31.04 |
| | (i.e. if the /Filter says it's flated then it should be flated) | 12:31.17 |
| | But I have no problem with pdf_write being able to copy items, and then alter them/compress them before writing out - but that shouldn't go back to the existing one. | 12:32.10 |
| | (that shouldn't change the existing xref and objects - as far as possible) | 12:32.27 |
| tor8 | Robin_Watts: right. so pdf_update_stream should change the /Filter to match at least. | 12:37.14 |
| | or we should make sure they match when we update | 12:37.40 |
| Robin_Watts | pdf_update_stream is a new function, and its purpose has fallen out of my head. | 12:38.41 |
| | If the purpose of pdf_update_stream is to say "make the stream contents come from this buffer", then it's the callers job to ensure that the buffer is encoded according to the filters in the file. | 12:40.15 |
| | (or equivalently, the caller must update the filters in the file to match the encoding of the buffer) | 12:40.38 |
| tor8 | correct | 12:40.51 |
| Robin_Watts | To cope with encryption, I suspect that pdf_update_stream should also take the orig_num and orig_gen figures. | 12:41.27 |
| | (with orig_num == 0 meaning not encrypted, maybe) | 12:42.05 |
| | but we can probably ignore that initially. | 12:42.44 |
| tor8 | open_raw_filter adds the decryption filter to the stream, open_filter adds the compression filters on top of that one. so I think we're okay with storing it unencrypted without having to change anything for reading. | 12:48.21 |
| Robin_Watts | ok. | 12:48.54 |
| tor8 | since in the updated stream buffer case, open_raw_filter will just do fz_open_buffer, and the open_filter will then tack on the decompression filters on that | 12:48.58 |
| | we just have to make sure to encrypt it when writing it back out | 12:49.14 |
| Robin_Watts | To simply the pdf_write code I want to push orig_num and orig_gen into the xref (as it means renumbering is much easier). | 12:49.39 |
| tor8 | yes, you mentioned that | 12:50.04 |
| Robin_Watts | but you're right, the way we use it probably means that encryption isn't an issue when using buffers for streams. | 12:50.20 |
| tor8 | can pdf_write_document write encrypted files? | 12:51.15 |
| | copystream calls load_raw_stream to get the unencrypted (if I read the comments and code correctly) buffer | 12:51.48 |
| | and then just fwrites it out | 12:51.59 |
| Robin_Watts | It cannot currently. | 12:52.22 |
| tor8 | okay, good to know :) | 12:52.27 |
| Robin_Watts | but we should update it so it can. | 12:52.29 |
| tor8 | then my patch doesn't need more work. I just wanted to run through the encryption cases first to make sure it would all work :) | 12:52.48 |
| | just need to update the comments a bit then I'll push to master | 12:53.00 |
| Robin_Watts | cool. | 12:53.05 |
| tor8 | Robin_Watts: okay, pushed. hope it works :) | 13:10.06 |
| alexcher | kens: I'd like to rename pdf_open_document() in gs because it conflicts with mupdf, and mooscript links both projects together. How about pdf_begin_document() ? | 13:31.57 |
| kens | As I suggested on irc yesterday, I thin kwe should prefix name clashes with 'pdfwrite' | 13:32.27 |
| alexcher | So it's pdfwrite_open_document() ? | 13:34.16 |
| kens | pdfwrite_pdf_open_document I suggest | 13:34.34 |
| Robin_Watts | sounds like prefix overkill to me. | 13:34.59 |
| | So, kens: You want to move the meeting forward a few days? | 13:45.13 |
| kens | Yes, ideally before the weekend instead of after | 13:45.30 |
| | Anytime the week before would be better from my POV | 13:45.43 |
| | I know the Monday is Labor Day so I assumed late in the week would be better for the US folks | 13:46.08 |
| Robin_Watts | I could cope with that, but it needn't stop you having a holiday - stella/melanie could just fly back on saturday. | 13:46.50 |
| | It would be nice to avoid flying on September 11th for a change :) | 13:47.08 |
| kens | Not that Saturday, it would have to be the previous one. | 13:47.15 |
| | Melanie is due at college the week of the 3rd | 13:47.27 |
| Robin_Watts | oh, I see. | 13:47.30 |
| kens | I can stay on in a hotel for a few days, but I'd prefer not to spend a week doign so | 13:48.01 |
| Robin_Watts | yeah, that could get expensive very quickly. | 13:57.36 |
| kens | Especially adding in internet access.... | 13:57.55 |
| | And I really don't want to fly home one weekend and back the next | 13:58.13 |
| Robin_Watts | kens: If you do it, you'd be best advised to pick a motel. | 13:58.22 |
| | Much cheaper, and they generally include internet access. | 13:58.32 |
| kens | Yes, true | 13:58.40 |
| | If I ahve to spend a long time I'll look around of course. | 13:58.52 |
| Robin_Watts | Hmm. I'm getting Unrecoverable error: undefined in .putdeviceprops | 14:05.27 |
| | and I can't find a putdeviceprops function. | 14:05.40 |
| kens | That's the device putparams isn't it ? | 14:05.59 |
| | maybe not... | 14:06.21 |
| mvrhel | kens: so the week that you propose the meeting is labor day weekend here in the US | 14:07.26 |
| Robin_Watts | mvrhel: I think ken was suggesting meeting on the 7th/8th rather than the 9th 10th ? | 14:09.16 |
| kens | Yes. | 14:09.30 |
| | The end of the week, not the beginning | 14:09.40 |
| mvrhel | oh his email says the week before | 14:09.42 |
| Robin_Watts | The end of the week before. | 14:09.48 |
| mvrhel | so I assume -7 days | 14:09.49 |
| | oh I sse | 14:10.02 |
| | see | 14:10.03 |
| | its early for me... | 14:10.14 |
| kens | Its hard to phrase , I should have put dates, it was early for me then.... | 14:10.40 |
| henrys | it is a bit unclear I read it as mvrhel did also. | 14:11.02 |
| kens | Shall I resend wiith dates ? | 14:11.14 |
| mvrhel | probably. | 14:11.31 |
| kens | OK will do so now | 14:11.38 |
| henrys | one sentence with your requested dates. | 14:11.39 |
| kens | OK sent | 14:14.06 |
| henrys | kens:I did remind marcosw to ping the pcl->pdf customer with what you said. We do need to make these emails more direct ... I recommend "Marcos please follow up with this customer ..." as an opener, so it's clear you are "reassigning" | 14:35.51 |
| kens | Well, I did think it was clear, but OK | 14:36.19 |
| | I oculd always wait rfor Marcos to make a bug report of course | 14:36.43 |
| henrys | or maybe we should just talk to marcosw about how best to get his attention. | 14:37.07 |
| kens | asking him seems like the best idea | 14:37.32 |
| Robin_Watts | I'm confused... I'm updating the psdcmyk device to support downscale_factor. | 14:37.37 |
| | and adding the following into get_params: | 14:37.55 |
| | code = param_write_long(plist, "DownScaleFactor", &xdev->downscale_factor); | 14:38.03 |
| | if (code < 0) | 14:38.05 |
| | return code; | 14:38.07 |
| henrys | kens:I completely missed it and then launched into an explanation to you about what you'd already explained in the previous mail, so I'm no better. | 14:38.20 |
| Robin_Watts | causes me to get an 'undefined in .putdeviceprops'. | 14:38.21 |
| kens | got a matching read ? | 14:38.24 |
| Robin_Watts | I never get an error from that call. | 14:38.51 |
| kens | get_params and put_params need to be matched | 14:39.08 |
| | Or you get an error | 14:39.15 |
| Robin_Watts | Yes, I have a matching read in put_params | 14:39.24 |
| kens | OK that's what I meant, so its not that | 14:39.35 |
| Robin_Watts | If I comment out the 2 lines given above, everything works fine. | 14:39.54 |
| kens | I'm ptreey sure I had that problem, nad it was caused by not having a matching get, other than that I have no ideas, sorry | 14:40.41 |
| Robin_Watts | Hmm. Moving the place of the read seems to have solved it. strange. | 14:45.07 |
| chrisl | Moving it before the generic putparams call? | 14:47.14 |
| Robin_Watts | yeah. | 14:52.02 |
| chrisl | Right, IIRC, each device has to read all it's own specific parameters before calling the generic one, or the generic will throw an error on a parameter it doesn't recognise | 14:52.50 |
| Robin_Watts | fair enough, thanks. | 14:53.05 |
| chrisl | Something I've tripped over a couple of times before! | 14:53.32 |
| p1xi3 | Hi | 15:22.40 |
| Robin_Watts | Hola | 15:22.47 |
| p1xi3 | I have a question about ghostscript and C++ - have I come to the right place for that? | 15:22.54 |
| | No? | 15:24.51 |
| kens | Its *a* place. | 15:26.42 |
| | Ask your question | 15:26.45 |
| | p1xi3 : ? | 15:27.41 |
| p1xi3 | Ah alright | 15:30.50 |
| | Well, I've installed ghostscript 9.5 I believe, installed it through my operating systems packet manager | 15:31.12 |
| | There's now a X11.so file located in /usr/lib/ghostscript/9.5 | 15:31.27 |
| kens | there is no 9.5 yet, the current version is 9.05 | 15:31.43 |
| p1xi3 | Where is the documentation on how I use this library in C++? What I want to do is batch-convert vector files (svg, ai, cdr etc) to bitmaps and generate thumbnails | 15:32.02 |
| | Ah, sorry - I meant 9.05 | 15:32.10 |
| kens | I don't think X11.,so is anything to do with us. | 15:32.37 |
| | If you want to ue GS then the documentation is ghostpdl/doc | 15:33.18 |
| chrisl | That X11.so isn't actually Ghostscript, it's some dynamically loaded devices which GS can use. | 15:33.25 |
| kens | GS is written in C, so you will have to ddo the required name mangling | 15:33.32 |
| p1xi3 | Question is, do I installed a shared library for it or do I use an already compiled program and just send it parameters? | 15:34.33 |
| | Is ghostpdl/doc documentation on how to use GhostScript in code? | 15:34.50 |
| chrisl | ghostpdl/gs/doc contains developer information | 15:35.17 |
| | p1xi3: FWIW, I would look to use the existing gs executable, it would be rather easier, I think | 15:36.36 |
| henrys | kens:I thought I fixed AutoRotatePages - I did add support for PostScript names to the command line processing, I thought I did that to support AutoRotatePages but it might have been something else. | 15:40.33 |
| kens | henrys, I did try it, but it didn't work, so I assumed it was because of PostScript names | 15:43.36 |
| | I can investigate more if you like | 15:43.46 |
| henrys | I'll have a look | 15:45.47 |
| kens | ok thanks | 15:46.11 |
| chrisl | kens: does cust 1 actually want to *not* embed "base 14" fonts when converting from PCL to PDF? | 15:47.03 |
| henrys | for PCL you never want to use the base 14 fonts and always want to use what pcl pickles into type 42 or type 3, things go terribly wrong in PCL when the metrics are wrong because of things like line wrap. | 15:51.23 |
| kens | Yes, correct chrisl | 15:51.26 |
| chrisl | So, how do base 14 fonts get used in PCL, then, in order to be emitted by pdfwrite? | 15:53.04 |
| henrys | Well if you select helvetica or it's URW equivalent in PCL, PCL produces a type 42 and I assume pdfwrite can substitute, but I haven't studied the pdfwrite code. | 15:55.10 |
| | a type 42 gs_font object that is. | 15:55.45 |
| chrisl | I don't understand why embedding the font is a problem - surely that's better than just having a reference to a font? | 15:57.34 |
| kens | If you get a call for a font, but no font, then we get the URW name, which we then substitute for a base 14 name (assuming its a base 14 font) | 15:57.35 |
| | chrisl I think that too, but they want small PDF files | 15:57.45 |
| | Since the base 14 are guaranteed on any PDF reader, they don't want to embed them | 15:58.34 |
| | Works for PS/PDF input, I have to go by what Henry says regarding PCL. | 15:58.55 |
| chrisl | But since PCL doesn't have a "base 14" (in quite the same way that PDF does, anyway), that seems like a recipe for disaster, to me....... | 15:59.39 |
| kens | If the PCL fonts exactly matched teh PS base 14 fonts, it wouldn't be a problem, because those fonts are guarnteed to be present | 16:00.11 |
| | Idf they don't, then it won't work properly. | 16:00.22 |
| | Which is what Henry says, I have no reason to doubt him | 16:00.37 |
| chrisl | Well, the PCL font has to exactly our font which also has to exactly match whatever font the eventual PDF viewer is using - lots of variables to save a tiny space in a PDF <sigh> | 16:02.37 |
| kens | Yes, I agree, its not my decision :-) | 16:02.56 |
| henrys | kens:didn't you add some sort of name substitution table in pdfwrite to do something similar to this? | 16:04.01 |
| chrisl | kens: well, I just wanted to confirm the customer was nuts, and not me ;-) | 16:04.22 |
| kens | henrys, yes hte name substitution is there, but for fonts which are not embedded in the input. THis means that we get teh base 14 names instead of the URW names, but still no embedded font. I don't remember how we got a PCL file with no fonts in it though. | 16:12.38 |
| henrys | oh well let's not worry about this business now. | 16:13.19 |
| Robin_Watts | mvrhel: ping? | 16:46.44 |
| mvrhel | Robin_Watts: pong | 16:46.54 |
| Robin_Watts | I've just updated psdcmyk to use the downscaler and run a cluster test. | 16:47.08 |
| mvrhel | cool | 16:47.13 |
| Robin_Watts | I see some bmpcmp differences. | 16:47.15 |
| | when I try the first of those files with my patch backed out, I get clist errors. | 16:47.38 |
| | Is this known about? | 16:47.44 |
| mvrhel | I dont think so | 16:47.51 |
| | I am not aware of any issues like that | 16:47.59 |
| | there were some issues at 300dpi I thought in the trunk actually before my commit though | 16:48.24 |
| Robin_Watts | gs/debugbin/gswin32c.exe -dFirstPage=1 -dLastPage=1 -r72 -sDEVICE=psdcmyk -o ref.psd ../ghostpcl/tests_private/comparefiles/Bug692517.pdf | 16:48.26 |
| mvrhel | not that file though | 16:48.34 |
| Robin_Watts | Could you double check that for me please? | 16:48.36 |
| mvrhel | ok | 16:48.45 |
| Robin_Watts | (I mean just run the above command and see what you get) | 16:48.56 |
| mvrhel | oh this is that file | 16:51.59 |
| | it is actually a ps file | 16:52.03 |
| | yes, there is a bug open about this file | 16:52.10 |
| | Robin_Watts: Bug 693061 | 16:52.47 |
| | I need to look this one over | 16:52.54 |
| Robin_Watts | ok, so clist errors are expected? | 16:52.57 |
| | My basic aim here is to ensure that I'm not making anything worse. | 16:53.10 |
| mvrhel | In the bug there are rendering issues | 16:53.16 |
| | but that is at 36 dpi according to the bug report | 16:53.37 |
| | so likely clist was not invoked | 16:53.57 |
| | let me run it here | 16:54.00 |
| | that file needs to be renamed to ps | 16:54.12 |
| Robin_Watts | Nothing I've done should touch the clist. | 16:55.24 |
| | I suspect that it's just tickling an existing problem due to shifting stuff slightly in memory. | 16:55.52 |
| | (different stack contents etc) | 16:55.59 |
| | If you don't know of any problems, maybe it's worth me having a hunt with valgrind etc. | 16:57.06 |
| mvrhel | I know that I have a bug open on this file | 16:57.22 |
| Robin_Watts | How about: tests_private/ps/ps3cet/09-47D.PS.psdcmyk.300.1 ? | 16:57.46 |
| mvrhel | I have a bug open on that file too I believe | 16:58.03 |
| | dealing with the process color model | 16:58.20 |
| Robin_Watts | tests_private/ps/ps3cet/29-07F.PS.psdcmyk.300.1 ? | 16:58.21 |
| | tests_private/ps/ps3cet/29-07F.PS.psdcmyk.72.0 ? | 16:58.36 |
| mvrhel | hold on, I running the first one in clist mode | 16:58.42 |
| | so I did not get a clist error when I ran the file | 16:58.53 |
| Robin_Watts | Release or debug binary? | 16:59.11 |
| mvrhel | debug | 16:59.21 |
| Robin_Watts | With the command I gave above? | 16:59.32 |
| mvrhel | I left out the page numbers | 16:59.53 |
| Robin_Watts | I've just retried it with a clean build from 27afc73 | 16:59.58 |
| | and I get the same problem. | 17:00.05 |
| mvrhel | let me try again | 17:00.17 |
| | oh I had 300dpi | 17:00.58 |
| | at 72 dpi the clist did do a dump | 17:01.07 |
| Robin_Watts | Ah, cool. | 17:01.12 |
| | So, I'm going to commit what I've got and assume that the problems I see in the tests are for bugs you already have open. Does that seem fair? | 17:01.35 |
| mvrhel | seem reasonable to me | 17:01.45 |
| Robin_Watts | Fab, thanks! | 17:01.51 |
| mvrhel | let me add this command to the open bug | 17:01.54 |
| | Robin_Watts: recall the fix on wrapping the path fill and path strokes in the knockout groups? | 18:12.04 |
| Robin_Watts | I do. | 18:12.28 |
| mvrhel | It looks like timing wise it is the way to go | 18:12.38 |
| | from the run that marcos did | 18:12.55 |
| | I think he had things swapped as to which one had the patch applied after I checked | 18:13.14 |
| Robin_Watts | The only case I can think of where it wouldn't be, is where we have (say) a stroked box around the page. | 18:13.19 |
| | AIUI, the stroked box around a page case will mean that we end up processing every pixel of the page for transparency when only a very few pixels are actually touched. | 18:14.08 |
| | I don't know if it's feasible to say "if the path is longer than 10 elements, then do it using a group, otherwise do it the old way" | 18:15.03 |
| | (Did that make sense?) | 18:16.37 |
| mvrhel | sorry on phone hold on | 18:17.08 |
| Robin_Watts | no worries. | 18:17.15 |
| mvrhel | Robin_Watts: yes that would happen since we are pushing another group. obviously the pixels that were not drawn are short circuited during the group pop | 18:27.29 |
| | I don't know about doing the path stuff | 18:27.47 |
| | that would have to be done in the interprester | 18:27.51 |
| | interpreter | 18:27.56 |
| Robin_Watts | "short circuited" ? | 18:27.58 |
| mvrhel | something that I am no going to tackle | 18:28.02 |
| Robin_Watts | You mean they'll be '0' and so no expensive calculations will be done ? | 18:28.17 |
| mvrhel | Robin_Watts: it sees the pixel was not drawn and moves on | 18:28.21 |
| | yes | 18:28.23 |
| Robin_Watts | but every pixel will still be checked. | 18:28.32 |
| mvrhel | yes | 18:28.36 |
| | but there is no blending etc | 18:28.46 |
| Robin_Watts | Presumably you have some code in the interpreter that decides whether to push a group or not? | 18:29.18 |
| mvrhel | basically from the timings that marcos did, the number of files that increased in time were smaller than the number that decreased | 18:29.21 |
| Robin_Watts | Or is that done in the C ? | 18:29.22 |
| mvrhel | and the deltas of the increases were quite small while the deltas of the decreases were large | 18:29.53 |
| Robin_Watts | Ah, ok. | 18:30.01 |
| mvrhel | Robin_Watts: it is done in PS | 18:30.04 |
| Robin_Watts | Just humour me for a mo, while I look at the PS. | 18:30.43 |
| mvrhel | I have to track down some rendering diffs that this has introduced still | 18:31.23 |
| | once I fix those, I will leave writing this decision in PS to you | 18:31.39 |
| Robin_Watts | Presumably your PS code must have something like: | 18:31.50 |
| | flag = (alpha != 0) if (flag) { push group; set alpha to 0} stroke if (flag) { pop group } ? | 18:33.15 |
| | (That's more C than PS, but...) | 18:33.44 |
| mvrhel | it uses the has_transparency flag | 18:33.49 |
| | and wraps a group around the stroke or fill command | 18:34.06 |
| Robin_Watts | so: if (has_transparency) {push group; remove transparency; stroke; pop group } else {stroke} ? | 18:34.42 |
| mvrhel | bascialy | 18:35.04 |
| Robin_Watts | OK, so if this was an issue, we can always do: | 18:35.20 |
| | if (has_transparency && !simple) {push group; remove transparency; stroke; pop group } else {stroke} | 18:35.41 |
| mvrhel | sure | 18:35.46 |
| | just need to figure out what simple is | 18:35.54 |
| Robin_Watts | I think we'd need to implement a custom operator to return the number of elements in the current path. | 18:36.13 |
| | and if that's smaller than 10 (say) it's simple. | 18:36.26 |
| | But we can not worry about that for now. | 18:36.40 |
| | It's something we can do if anyone complains. | 18:36.52 |
| mvrhel | right | 18:36.58 |
| | looks like the patch screws up overprint with transparency for some reason | 18:40.26 |
| | oh I probably should avoid this push for high level devices | 18:43.48 |
| | oh great some pattern issues too | 18:48.21 |
| | Forward 1 day (to 2012/05/24)>>> | |
IRC Logs