| | <<<Back 1 day (to 2012/07/15) | 2012/07/16 |
| alexcher | It turned out that increasing the size of ref to support lage strings and arrays is quite easy. | 00:00.12 |
| | Increased limits enable gs to process PDF files that have large objects and close several bugs. | 00:01.10 |
| | However, larhe limits are detected and reported by the test suite. | 00:02.35 |
| | What's a good approach to deal with the tests? | 00:05.39 |
| Robin_Watts | tor8: Are we expecting to see the new viewer in time for the release? (I'm guessing not...) | 10:23.46 |
| nehex | Hi. I have not executable mupdf. | 10:25.15 |
| | Is it because I build it without X support? | 10:25.36 |
| Robin_Watts | nehex: You'll need to give us a bit more detail than that before we can comment. | 10:26.29 |
| nehex | Oh, I'm sorry. What detail? | 10:27.44 |
| | I am a Gentoo user. | 10:27.58 |
| | I install mupdf by emerge command without X use-flag. | 10:28.31 |
| Robin_Watts | nehex: So you're installing from a package? | 10:28.53 |
| | We can help you if you're using the version of mupdf from our site, using the package of libraries that we supply. | 10:29.19 |
| paulgardiner | tor8, Robin_Watts: do we exepect app writers to deal with exceptions? Or to put it another way, are methods of the library api allowed to throw? | 10:29.36 |
| Robin_Watts | IF you're using a package from elsewhere, then you need to contact the packager. | 10:29.45 |
| | paulgardiner: I think we expect callers to have fz_try/fz_catch set up at various points, yes. | 10:30.09 |
| nehex | Ok, I'll try that, thanks. | 10:30.23 |
| Robin_Watts | The API headers should all say "May throw exceptions" for the functions in question. | 10:30.36 |
| | nehex: OK. | 10:30.41 |
| paulgardiner | Robin_Watts: Ok good. I'd previously assumed not, but for the case I'm looking at, it would have been difficult if they were not allowed. | 10:32.05 |
| | Actually, I should have known: I now remember that the jni code in the android app has try catch around all calls. | 10:34.14 |
| chrisl | Oh, great, PCL never shuts down the graphics library, nor the memory manager......... | 10:39.46 |
| tor8 | Robin_Watts: no, I don't think there's time enough for that. | 11:03.21 |
| Robin_Watts | tor8: Fair enough. | 11:03.42 |
| | Do you have time to handle the merge of forms -> master then ? | 11:03.55 |
| tor8 | that we should be able to do | 11:04.22 |
| Robin_Watts | paulgardiner is off on holiday next week, I think. | 11:04.50 |
| paulgardiner | I've been a bit lax this week on asking you to look at my commits. There are six or so on paul/forms not yet on origin/forms | 11:05.32 |
| Robin_Watts | paulgardiner: I'll try and look later today unless tor8 beats me to it. | 11:06.05 |
| paulgardiner | Partly I was holding off because one involves dates and will cause daily bmp changes until we update the autotests | 11:06.55 |
| Robin_Watts | oh... | 11:08.21 |
| | When we do cluster tests we build with -DCLUSTER | 11:08.34 |
| | so we could maybe do something to say "If we are cluster testing, the time/date is always tor8's birthday" or something. | 11:09.09 |
| paulgardiner | Would need some thought becaue it's v8's concept of time that we'd need to alter | 11:09.47 |
| Robin_Watts | Could we provide an Artifex js object? | 11:12.30 |
| | with a cluster member which can evaluate to true or false and have the js look at that ? | 11:12.59 |
| | and then the C can set Artifex.cluster to be true/false as required ? | 11:13.18 |
| | That would avoid having to change the v8 source. | 11:14.13 |
| paulgardiner | Possibly, but once the mjs files are udpated we shouldn't need this: the case that causes it is the value of a date widget being set with insufficient numbers to fully define the date | 11:15.31 |
| Robin_Watts | Right. We can back the .js change out then. | 11:16.19 |
| paulgardiner | Oh ok, possibly then. I wasn't really looking at solutions like that because I thought you were planning to update the mjs files fairly soon. I've put the api calls in that you requested - the ones that let you tell whether a text widget expects a date. | 11:18.38 |
| Robin_Watts | yes. I am loathe to predict how much longer I'm going to be buried in this damn interpolation thing though. | 11:19.15 |
| | I *think* I'm almost there, but then I've thought that for the past few days... | 11:19.27 |
| paulgardiner | Oh right. That does sound hairy. | 11:19.57 |
| | I could use the CLUSTER define to hack fz_widget_text_set_text. That's probably simplest | 11:21.12 |
| Robin_Watts | how would that work ? | 11:21.55 |
| | It would be nice to have the cluster testing the date code, but having the bitmaps change every day is probably a showstopper. | 11:22.37 |
| paulgardiner | If the value is being set and the widget takes a date then ignore the value specified and use Tor's birthday | 11:22.47 |
| Robin_Watts | That would be the best workaround we could do in the short term I think. | 11:23.29 |
| paulgardiner | Ok. I'll go with that. | 11:23.54 |
| | Robin_Watts: Actually, it does look possible to override javascripts Date constructor so that might be a good way to do it. Would catch all uses. | 11:38.54 |
| Robin_Watts | paulgardiner: So we'd have a #ifdef CLUSTER stuff in the mupdf C code that inits v8 that overrides Date ? | 11:39.53 |
| paulgardiner | Yes. Just as you suggested | 11:40.12 |
| Robin_Watts | I don't think I suggested anything that neat, but OK :) | 11:40.47 |
| paulgardiner | I may go with the other approach for now because I know it wont fight back. | 11:41.33 |
| Robin_Watts | ok. | 11:42.30 |
| paulgardiner | Either way needs extensive research to find Tor's birthday :-) | 11:42.45 |
| Robin_Watts | tor8, sebras: When is tor8's birthday ? | 11:45.16 |
| | (or some other meaningful mupdf date) | 11:45.35 |
| | We shipped v1.0 of mupdf on 24/4/2012, so we could use that. | 11:46.56 |
| paulgardiner | yep. That'll do. | 11:47.18 |
| tor8 | Robin_Watts: june 15, 1979 | 12:09.18 |
| Robin_Watts | Unspeakably young. | 12:10.00 |
| sebras | Robin_Watts: I couldn't agree more. :) | 12:18.27 |
| tor8 | young, dumb, and we need to hire more young engineers so I can feel senior ;) | 12:21.02 |
| alexcher | I want to increase max object sizes (and a corresponding member of ref structure) to support big PDF objects. | 13:07.36 |
| | This causes differences in a few test cases that specificly check max object sizes. | 13:08.15 |
| kens | I think we hsould ignore tht, its a progression | 13:08.55 |
| henrys | alexcher I can't imagine it would cause a problem for a user, but it should be documented ... that said I'm a bit nervous changing the size of ref won't break other stuff, are you sure there are no other problems? | 14:20.32 |
| kens | We know Jaws does nort limit the size of composite objects (arrays and strings) the way Adobe interpreters do, and that certainly never caused a problem. Compliance should be documented somewhere (so we can point to it when it differs form the Quality Logic output) but that's all that need be done IMO | 14:29.04 |
| henrys | I was concerned about Peter having some squirrely code that assumes the ref is a particular size ... | 14:34.21 |
| kens | I think chrisl and alexcher have both looked at that and it seemed to be OK | 14:34.50 |
| henrys | so I guess they are confident it can go in before the upcoming release? | 14:36.24 |
| kens | If it was me I would wait until after release personally | 14:36.51 |
| | Since its so close and this is an old problem | 14:36.59 |
| | I htought Alex just wanted opinions about the fact that there's a diff in the test suite | 14:38.37 |
| alexcher | henrys: 64-bit build keeps sizeof(ref) unchanged. It should be quite safe. | 14:42.55 |
| Robin_Watts | So... cluster testing this is worthless ? | 14:43.40 |
| alexcher | henrys: 32-bit build appears to work but needs full regression testing. | 14:43.43 |
| kens | The cluster only does 64-bit tests | 14:43.56 |
| alexcher | henrys: we have a few bugs caused by PS restrictions on the object sizes. I wanted to have them fixed in the upcoming release. | 14:47.46 |
| henrys | do you have a 32 bit machine? | 14:48.25 |
| Robin_Watts | alexcher: I'm with kens - I think we should flip the switch *after* the release. | 14:48.34 |
| alexcher | henrys: yes | 14:48.36 |
| henrys | I'm uneasy changing it now too. Let it fester for 6 months. | 14:49.21 |
| alexcher | henrys: the changes are in 'bigref' branch in my repository on casper. | 14:50.12 |
| henrys | I don't know if I like the business of uint vs say uint32 | 14:53.13 |
| alexcher | henrys: uint32_t depends on stdarch.h, which needs iref.h. | 14:56.22 |
| henrys | alexcher:and I think almost everyone will agree this should go in after the release and get used a few months before unleashed. | 14:56.46 |
| alexcher | henrys: OK | 14:57.08 |
| kens | Oh good grief, in order to have pdfwrite emit linearized PDF I'm going to have to change the object number of every object in the file :-( | 14:59.03 |
| Robin_Watts | kens: Yes. I've just been through all this. | 14:59.47 |
| kens | Stupid spec :-( | 14:59.57 |
| Robin_Watts | really stupid, painful, unclear spec. | 15:00.15 |
| kens | I think this may be hard with pdfwrite. Any idea if we can have unused (free) objects in the second xref ? | 15:02.33 |
| Robin_Watts | kens: I believe, no. | 15:02.50 |
| kens | Then that could be fatal. pdfwrite sometimes allocates objects, but doesn't use them..... | 15:03.21 |
| | I suppose I could condense those too :-( | 15:03.36 |
| | can of worms.... | 15:03.53 |
| henrys | kens:I didn't think comp.lang.postscript still had traffic. | 15:05.20 |
| kens | ure it does, just quieter than it used to be :-) | 15:05.39 |
| | Most of UseNet is quiet these days | 15:06.19 |
| | OTOH at least hte spammers have mostly gone too :-) | 15:06.43 |
| alexcher | Perhaps, PDF lineariser is easier to write as a separate utility based on mupdf? | 15:07.02 |
| Robin_Watts | alexcher: Theoretically, it's already there. | 15:07.32 |
| | mubusy clean -l in.pdf out.pdf | 15:07.45 |
| kens | We aklready have a PostScrip tone, I was thinking of not fixing thebugs in it (cos I don;t understand it) and doing the pdfwrite lineariser instead | 15:08.10 |
| Robin_Watts | But there are bugs in the pdfclean stuff that we really need to fix. | 15:08.28 |
| kens | I think people would prefer a single-step process anyway | 15:08.30 |
| alexcher | pdfwrite is not an optimal solution for PDF to PDF conversion. | 15:10.34 |
| kens | People use it that way though | 15:10.46 |
| mvrhel | kens: do you have a second | 15:20.28 |
| kens | a minute mvrhel | 15:20.39 |
| mvrhel | So I have been looking over the files in Bug 693061 | 15:21.15 |
| | Most of these appear to be correct to me | 15:21.27 |
| | but there is one interesting case | 15:21.34 |
| | that I think we will have issues with for tiffsep and psdcmyk | 15:21.56 |
| | the file fts_14_1420.pdf | 15:22.11 |
| | and fts_14_1421.pdf | 15:22.21 |
| | these have DeviceN color spaces | 15:22.29 |
| kens | OK | 15:22.29 |
| mvrhel | with multiple \None entries | 15:22.40 |
| kens | \None makes no marks, so we should be able to skip the plates | 15:22.55 |
| mvrhel | and then fills using those with nonzero entries for the \None colorants | 15:23.04 |
| | these can effect what the alternate tint transform color is going to be | 15:23.19 |
| kens | Yes, but the ink is non-marking, so the plate is, by definition, empty | 15:23.27 |
| mvrhel | and unfortunately for our separations we cant draw a proper CMYK preview then | 15:23.41 |
| kens | Well I would argue that we never can | 15:23.51 |
| mvrhel | not in psdcmyk | 15:24.00 |
| kens | Either we make CMYK using the tint transfrom or we make separations | 15:24.05 |
| | I don't see why psdcmyk matters | 15:24.27 |
| mvrhel | ok let me back up one step | 15:24.36 |
| | with tiff sep we get the planar output tiffs and we get the composite tiff as output | 15:25.00 |
| | with the above run, our composite CMYK tiff will not really look correct, but all the sep planes are correct (in terms of ink amounts) | 15:25.44 |
| kens | Yes | 15:26.11 |
| mvrhel | with psdcmyk, we have the same situation. all the planes in photoshop will have the correct ink amounts, but photoshop will not really match Adobe Acrobat when we see it on the screen. I agree maybe that none of this may be important though | 15:27.26 |
| kens | Well acrobat output is also a kludge, since you are drawing CMYK+spots in a RGB space :-) | 15:28.04 |
| mvrhel | yes | 15:28.11 |
| kens | So the fact that our kludge doesn't match the Adobe kludge is not surprising | 15:28.29 |
| | Actually we're talking the Photoshop repretentation of the composite not matching the Acrobat representation, so this seems to me 'not our problem' | 15:29.54 |
| | Though I think it would be reasonable to elide teh 'None' planes altogether | 15:30.09 |
| mvrhel | Right. OK. well with my big fix on the separation devices, I fixed it so that we do not get the \None color separations. (We were getting them occasionally before). | 15:30.11 |
| kens | THat sounds correct to me | 15:30.25 |
| mvrhel | right. but by not having them, it is not possible for us to properly show the preview but I guess that is the way that it goes? | 15:31.35 |
| | well, we can always do the preview by running out to tiff32nc or something | 15:31.51 |
| kens | But hey shoudl not affect the preview | 15:32.01 |
| | Because /None plates make no marks.... | 15:32.08 |
| mvrhel | ah they can | 15:32.09 |
| | the can effect the computation of the alternate tint transform | 15:32.23 |
| | so I can have a color space as follows | 15:32.34 |
| | \Spot1 \None \None | 15:32.44 |
| | and then do a fill with | 15:32.47 |
| | 0.4 0.2 0.1 | 15:32.53 |
| | and go through the tint transform | 15:33.04 |
| | where all three numbers affect the result | 15:33.11 |
| kens | which is 'the' reault ? | 15:33.32 |
| mvrhel | so my CMYK value for the preview is affected by the None tint values! | 15:33.32 |
| | if my alternate color space was CMYK say | 15:33.43 |
| | and I have a DeviceN color space with \Spot1 \None \None | 15:34.05 |
| | and I am going out to tiff32nc | 15:34.14 |
| kens | one minute, I need a second | 15:34.32 |
| mvrhel | let me point you to the section in the spec | 15:34.42 |
| | Section 4.5 I think | 15:35.58 |
| | ha that narrows it down | 15:36.31 |
| | hold on | 15:36.33 |
| | page 271 | 15:37.22 |
| kens | OK let me find that | 15:37.36 |
| mvrhel | it mentions that the \None components are passed to the tint transform which can use them as desired | 15:38.10 |
| | in the middle of the page | 15:38.26 |
| kens | Well I think personally that any tint transform which produces a CMYK representation where /None has an effect is just wrong | 15:38.57 |
| mvrhel | I agree it is stupid | 15:39.07 |
| kens | page 271 in my spec (PLRM) is sahding dictionaries | 15:39.24 |
| | are you talking the PDFRM ? | 15:39.31 |
| mvrhel | pdf | 15:39.33 |
| | sorry | 15:39.39 |
| kens | <shrug> Well I think that the tint transform is incorrect in that case | 15:40.18 |
| | And that means that the tint transformed outptu would look nothing like the sfinal printed utput incorporating the coerrect inks | 15:40.49 |
| | SO I would say its wrong. | 15:40.56 |
| | But nayway, I've lost th thread of the problem | 15:41.22 |
| mvrhel | right. basically, for a separation device, I don't think there is an easy solution for this case. | 15:41.39 |
| kens | You are saying that our composite (using the tint transform) would not match the Photoshop (not using the tint transform) ? | 15:41.48 |
| mvrhel | out non separation devices work just fine for this | 15:41.54 |
| | s/out/our/ | 15:42.04 |
| kens | Because they always use the tint transform | 15:42.06 |
| mvrhel | yes | 15:42.09 |
| | and they have the \None colorant values to compute the proper alternate color | 15:42.24 |
| kens | The only problem is that the Photoshop composite doesn't match our composite ? | 15:42.27 |
| mvrhel | for the sep devices, we assemble the tiff CMYK version from the separations | 15:42.47 |
| | similarly, psdcmyk assembles what is shows from the separations inside its file | 15:43.05 |
| kens | OK | 15:43.20 |
| mvrhel | without the \None tint values, it cant show it properly | 15:43.20 |
| kens | 'properly' is debatable | 15:43.31 |
| mvrhel | ;) yes | 15:43.39 |
| kens | I would say that the result is indeed 'proper', but the tint transformed composite is incorrect | 15:43.47 |
| mvrhel | I agree. At the end of the day, if someone is getting separations, we have the correct ink amounts | 15:44.07 |
| | for all the colorants except the \None | 15:44.20 |
| kens | If this is a worry I woudl document it and leave it, there is no way to get teh composite fomr merged separations (which is a *good* preview of the final pritned reuslt) to match a tint transmformed result anyway | 15:44.38 |
| mvrhel | where we can even have multiple Nones to add to the fun | 15:44.38 |
| | right | 15:44.47 |
| | ok. thanks. I agree. Just wanted to see if I was thinking the right way | 15:45.14 |
| kens | DOes that jibe with your posirtion ? Oh I see that's a yes | 15:45.26 |
| mvrhel | I had thought and thought about ways around it and they were all ugly | 15:45.44 |
| kens | I don't think there is any realistic solution. | 15:45.55 |
| mvrhel | the sep devices I think should be clean and clear of any \None colorants | 15:46.07 |
| kens | Yes, having those si just wrong | 15:46.23 |
| mvrhel | ok. I think that boils this bug down to an single issue in patterns then | 15:46.45 |
| kens | Col | 15:46.56 |
| | Cool | 15:46.58 |
| mvrhel | thanks for the chat kens | 15:47.07 |
| kens | NP sorry I needed the one sylabble explanation :-) | 15:47.32 |
| | Or even syllable | 15:47.45 |
| apineda | hey guys. do you have time for a few questions? | 15:49.36 |
| kens | Depends on how hard they are :-) | 15:49.48 |
| apineda | hard for me :D | 15:49.58 |
| | mostly about icc, ghostscript. im lost on the idea of an input rendering intent, as I'm only used to a single output rendering intent setting. | 15:50.36 |
| kens | mvrhel : over to you :-) | 15:50.59 |
| mvrhel | apineda: what is it that you want to do? | 15:51.18 |
| apineda | trying to rasterize a pdf for print using ghostscript and icc profiles | 15:53.25 |
| mvrhel | that happens by default | 15:54.46 |
| apineda | using tiff32nc | 15:54.50 |
| | i know thats the thing, im jumping into this project and nobody knew... | 15:55.10 |
| Robin_Watts | listens in on this too. | 15:55.34 |
| | The output rendering intent is used to map colors within the PDF so that they appear correctly on the output device, right? (Is that too simplistic, or wide of the mark?) | 15:56.26 |
| apineda | so I've been trying to figure out some shit becuase, well because I want to and am able to. We use a custom rip that uses custom color solution, but its poopoo. I was given a bit of time to try to improve the color output and so here I am. We might just revert to Roland software but its crashy. | 15:56.34 |
| mvrhel | Robin_Watts does more than listen :) | 15:57.01 |
| apineda | yeah output I understand, the gamuts get mapped in a way thats desired for output, atleast for what the device is capable of | 15:57.06 |
| Robin_Watts | mvrhel: You should know I can't keep quiet by now :/ | 15:57.38 |
| mvrhel | hehe | 15:57.41 |
| apineda | the thing is that, well ok here goes... cmyk -> LAB for input, and rendering intent i thought was for LAB -> LAB | 15:57.42 |
| kens | AFAIUI the input rendering intent is used to map device colours back to device-independent colours, by telling the process what the original rendering intent was. You can then use an output rendering intent to map the device-independent colours into device colours approrpriate for the final device. BNut I may be mis-understanding | 15:57.51 |
| apineda | the second LAb being in the output profile then to device cmyk or whatever | 15:58.00 |
| mvrhel | brb | 15:58.09 |
| apineda | kens: I have to think... | 15:59.45 |
| kens | So lets say you have a CMYK colour in your input file. You can tell the CMS that this was originally intended for a epson inkjet. The CMS can then say 'given this CMYK value, what Lab (or other device indepdnent colour) woudl have given rise to that CMYK value on this device | 16:00.22 |
| | THen you give the CMS an output profile suitable for a different device | 16:00.43 |
| mvrhel | ok I am back | 16:00.44 |
| apineda | kens: yeah I get that, but I think i just lack clarity on the SWOP stuff, which is what the input would be going to | 16:00.53 |
| kens | It converts the device independent colour into one 'correct' for that device and renders it | 16:01.00 |
| mvrhel | apineda, did you read the color document in the docs directory? | 16:01.18 |
| kens | apineda : I defer to mvrhel, this is my crude understanding | 16:01.21 |
| apineda | but thats sufficient enough for me | 16:01.25 |
| | mvrhel: i've read a lot but not from there yet. I'll check it out. | 16:01.39 |
| | I have another question, for my pdfs we use spot colors. The alternate cs is cmyk. For some spot colors I need these cmyk values untouched by color management. I don't know exactly how tiff32nc works but its taking the alternate cmyk and modifying it, is there a way to prevent this for certain spot colors? | 16:03.14 |
| Robin_Watts | apineda: Well, tiff23nc is designed to render to a 32bit tiff. | 16:04.02 |
| | If you want spot colors handled separately then you want to use tiffsep. | 16:04.19 |
| apineda | right right | 16:04.19 |
| | Robin_Watts: thanks. is that in PDL? | 16:05.36 |
| | maybe a bad guess | 16:05.45 |
| kens | tiffsdep is a device | 16:05.54 |
| | produces separations as tiff | 16:06.00 |
| Robin_Watts | tiffsep is a different device. It's included in the standard builds. | 16:06.08 |
| apineda | thanks gentlemen. | 16:06.48 |
| mvrhel | with tiffsep, spot color pass straight through | 16:09.01 |
| | CMYK colors are managed | 16:09.06 |
| | by the specified output CMYK profile | 16:09.23 |
| | if you want to turn off Color management completely then use -dUseFastColor | 16:09.43 |
| | apineda: I would review http://ghostscript.com/doc/current/GS9_Color_Management.pdf for lots of details on ghostscript's color managmeent | 16:11.09 |
| | quite a bit of information in there about rendering intent | 16:11.40 |
| karlheinz | I know ghostscript does a lot; I need it for pdf to image conversion. Is ghostscript the better product, or is something like PDFTRON? | 16:13.05 |
| mvrhel | but essentially an ICC profile can contain 3 unique mappings. These are specified by the rendering intent. | 16:13.06 |
| Robin_Watts | karlheinz: What is your intended use for the images? | 16:13.41 |
| | and on what platform? | 16:17.04 |
| | karlheinz: We can't really give an answer without more information. | 16:17.18 |
| karlheinz | They will be displayed in a browser. The PDFs contains forms, and both Linux and Windows | 16:17.18 |
| Robin_Watts | That sounds more like a job for mupdf. | 16:17.37 |
| | especially with the work being done on the forms branch. | 16:17.48 |
| karlheinz | Hmm, I didn't know MuPDF converted PDF pages to images | 16:19.03 |
| kens | Amongst many other abilities | 16:19.13 |
| | Its has to create an image to dusply it on screen | 16:19.22 |
| | display* | 16:19.38 |
| Robin_Watts | karlheinz: mudraw is the simplest tool for converting PDF page to images. | 16:19.54 |
| kens | It sounds to me more appropriate for this project than GS | 16:20.14 |
| Robin_Watts | but the mupdf executable does the same thing internally; as kens says, we have to convert to images to display on the screen. | 16:20.16 |
| fdncred | wher mupdfshow <pdf> xref prints something like this "00001: 0000000008 00000 n (stm_ofs=176; stm_buf=00000000)" does stm_ofs mean? where it found the stream? where the stream should've been? | 16:20.40 |
| Robin_Watts | It runs on windows, linux, ios, android, and even webos, rtos etc. | 16:20.48 |
| karlheinz | I see | 16:20.57 |
| Robin_Watts | karlheinz: We are working on forms support now (so with appropriate hooks you can edit the forms etc) | 16:21.09 |
| | stm_ofs = The offset of the start of the ACTUAL DATA in the file, IIRC. | 16:21.42 |
| karlheinz | Robin_Watts: I see. Currently we use itext for that, so I solely need it for image conversion | 16:21.43 |
| Robin_Watts | ok, well, there you go. | 16:21.58 |
| fdncred | Robin_Watts: so in my example, the data should've started at offset 8 but really started at offset 176 - correct? | 16:22.31 |
| Robin_Watts | mupdf will probably give you better quality in less memory than gs will for screen use (as it antialiases by default) | 16:22.36 |
| | No. | 16:22.38 |
| | In your example, you've got pdf object 8 of generation 0 that is is a stream. The actual data offset of which is 176. | 16:23.35 |
| fdncred | ok, i see now. following the word stream is byte 176. got it. | 16:24.48 |
| | just trying to figure out how this xref is messed up exactly. | 16:25.05 |
| Robin_Watts | "mubusy clean in.pdf out.pdf" and compare the two? | 16:25.43 |
| | That may not help, but it's worth a shot. | 16:26.06 |
| karlheinz | OK, mupdf is probably better than GS in full | 16:29.59 |
| fdncred | in the diff, it looks like all the 0x0D's are 0x0A's. wouldn't thinkn that would matter. | 16:31.07 |
| | in the text portions, thatis. the binary streams are identical. | 16:32.43 |
| mvrhel | henrys: did you see that email from the tiffsep customer? | 16:35.53 |
| kens | Is that Gemma ? | 16:36.03 |
| mvrhel | yes] | 16:36.06 |
| kens | She has sent 2 | 16:36.07 |
| henrys | sigh yes | 16:36.11 |
| mvrhel | the last email I don't quite understand | 16:36.29 |
| Robin_Watts | fdncred: Well, it matters if the offsets are all off now. | 16:36.41 |
| kens | The one with the sampl efiles mvrhel ? | 16:36.53 |
| Robin_Watts | Also, the xrefs (despite looking like text) have specific binary requirements. | 16:37.08 |
| mvrhel | kens: yes | 16:37.21 |
| kens | WHat don't you understand ? I haven't tried the files myself, but there do look to be problems with the output | 16:37.42 |
| mvrhel | "quite a lot slower than any others" | 16:38.01 |
| | what others | 16:38.06 |
| kens | Well, previous versions she has used I guess | 16:38.16 |
| mvrhel | oh she means then other files | 16:38.17 |
| | or previous versions? | 16:38.23 |
| kens | BTW when I use HEAD with the file from her first email (missing barcodes) they are OK fr me | 16:38.31 |
| | I think she means previous versions of GS | 16:38.43 |
| mvrhel | I have not looked at them yet | 16:38.44 |
| henrys | that was my read | 16:38.55 |
| mvrhel | the newer versions should be quite a bit faster, at least if transparency is involved | 16:39.08 |
| kens | Well I used her command line and file for the 'barcodes' one, and the tiff I get has hte barcodes in | 16:39.10 |
| fdncred | Robin_Watts: if i look at the offsets in a hexeditor everything lines up in the "bad" file. so i'm not sure how 0a vs 0d would be counted differently. | 16:39.15 |
| kens | mvrhel : welll that was what I thought too | 16:39.24 |
| fdncred | Robin_Watts: just found another difference that probably matters as well, oldpdf="xref 1 28" cleanedpdf="xref 0 28" | 16:39.30 |
| henrys | mvrhel:I would let marcosw preprocess it and then it will be clear exactly what is needed. | 16:40.36 |
| kens | 'signal.pdf' renders incorrectly for me | 16:41.24 |
| | THough I should point out that it has the 'unbalanced q/Q operators' error | 16:41.40 |
| mvrhel | henrys: yes. I am beating on my blocker bug now anyway | 16:42.26 |
| kens | sigh 10 spot colours.... | 16:42.50 |
| Robin_Watts | I've got to do the mupliple reboot dance with VMware player. bbiab. | 16:50.37 |
| ray_laptop | oops. problem with a bank account... bbiaw | 17:04.41 |
| | mvrhel: I need to talk to you after I deal with this about fill_rectangle_hl_color | 17:05.02 |
| Robin_Watts | Down to a single page of diffs with this interpolation stuff, and it looks to all be the same issue. | 17:17.06 |
| linux_dr | I saw GS Bug number 691116 ("Greek characters missing in conversion to TIFF") that was supposed to have been fixed in 9.00 that I thought was affecting us... | 18:00.06 |
| | We upgraded to 9.05 and made sure all the "std" and "other" fonts were installed, and am still having an issue rendering "pi" in TimesNewRomanPS-ItalicMT | 18:01.19 |
| | can someone suggest what we may be doing wrong? | 18:01.39 |
| | is anyone awake in here? does anyone know where else would be good for me to ask? | 18:05.30 |
| Robin_Watts | yes people are awake in here. | 18:05.41 |
| linux_dr | that's reassuring anyway. :) | 18:05.56 |
| Robin_Watts | but the 2 people that probably would be best place to help you work on UK time. | 18:06.03 |
| linux_dr | understood... | 18:06.11 |
| chrisl | linux_dr: I just tried the test file on the bug you quoted, and the current output isn't missing any glyphs I can see..... | 18:06.23 |
| Robin_Watts | and it's 7pm here, so you've missed them for the day (unless they check in later) | 18:06.23 |
| linux_dr | Understood... | 18:06.33 |
| Robin_Watts | And indeed, here is chrisl :) | 18:06.33 |
| linux_dr | is where? | 18:06.45 |
| chrisl | I'm working a little later as I was out this afternoon | 18:06.57 |
| linux_dr | And I *DO* realize that you all have better things to do than answer some random Yokel's newbie questions⦠lol | 18:07.52 |
| chrisl | linux_dr: and I just tried the 9.05 release, and all the glyphs seem to be present, so yours may be a different issue from the one in 691116 | 18:09.32 |
| linux_dr | (Ok.. not exactly a newbie⦠just been away from ghostscript for a very long time) | 18:10.43 |
| | Yes⦠I was looking at the EPS source⦠I'm seeing a 50 /TimesNewRomanPS-ItalicMT f1 followed (not immediately) by a [/pi] gs | 18:11.35 |
| kens | Oops, I CC'ed the customer when I didn't mean to <blush> Fortunately I was reasonably polite | 18:11.59 |
| Robin_Watts | linux_dr: Making the file available to us might be an excellent first step. | 18:12.06 |
| | kens: You need lessons from paulgardiner :) | 18:12.33 |
| kens | In not being polite ? :-) | 18:12.48 |
| linux_dr | I *THINK* I can⦠it's just "pi/8" but *AM* at a publishing company⦠so let me get someone's permission... | 18:12.54 |
| | I don't think "pi/8" is copyrightable⦠but.. you know.. :P | 18:14.22 |
| kens | Wasn't there a Douglas Admas book where someone copyyrighted 3.4115... ? | 18:14.58 |
| Robin_Watts | kens: Customer hassled me on the phone for ages, then sent me an email. I forwarded the email to paul for him to deal with with a note attached at the top explaining that the customer was an idiot, and would need everything explained to him in words of 1 syllable and even then he'd **** it up. | 18:15.17 |
| linux_dr | it's just over 1K⦠do you suggest a pastebin? | 18:15.40 |
| Robin_Watts | kens: paulgardiner then top posted to my message when replying to the customer :) | 18:15.49 |
| kens | Oops ROFL | 18:15.56 |
| | Fortunetly for me I didn't write anyting as bad as that | 18:16.20 |
| Robin_Watts | No, what you wrote seemed absolutely fine. | 18:16.34 |
| kens | linux_dr pastebing is 'probably OK' but PS files can contain binary amd that won't work | 18:17.30 |
| | You could open a bug report and attach the fiel there, or just put it any pulbic place | 18:17.57 |
| linux_dr | it's text⦠but here's a link: http://pastebin.com/LD456SAM | 18:18.07 |
| kens | Oh, ooops I'd closed Firefox.... | 18:18.29 |
| chrisl | linux_dr: I suspect your problem is that our fonts don't include the glyphs in question | 18:18.31 |
| kens | That woudl seem most likely | 18:18.45 |
| linux_dr | chrisl: yes⦠I totally agree⦠just not sure how to fix that⦠or why pi would be missing.. :( | 18:19.01 |
| kens | To fix it you can supply a differnt font in place of the one with the missing glyphs | 18:19.22 |
| | There's no real reason why pi woudl be there in a 'normal' (as opposed to math ot Greek) font | 18:19.41 |
| linux_dr | there's no way to tell ghostscript to fall back to another font *IF* the glyph is missing? | 18:20.00 |
| kens | No, absolutely not, that's not the way PostScript works | 18:20.18 |
| | If the glyph is missing the spec says we must substitute the /.notdef glyph | 18:20.40 |
| | OK you are already falling back to a default font | 18:21.04 |
| | The font you are using is TimesNewRomanPS-ItalicMT | 18:21.35 |
| linux_dr | Yes⦠said that.. | 18:21.43 |
| kens | You obviously don't have that installed in GS so it falls back to Times-Roman | 18:21.59 |
| | The font isn't the same so all bets are off in essence. | 18:22.10 |
| | You should install a copy of TimesNewRomanPS-ItalicMT | 18:22.24 |
| | Then it will work | 18:22.32 |
| linux_dr | give me a minute to tear into the fontmap. | 18:22.46 |
| kens | chrisl are the resuorces going to be built in in linux_dr's installation ? | 18:23.27 |
| karlheinz | Is it safe to make several conversions using mudraw at the same time | 18:24.04 |
| chrisl | kenI've no idea | 18:24.28 |
| kens | Oh well, guess we'll find out :-) | 18:24.38 |
| Robin_Watts | karlheinz: You mean have several invocations at once ? | 18:24.45 |
| | karlheinz: Absolutely. | 18:24.57 |
| karlheinz | yes, I assumed so | 18:25.04 |
| linux_dr | I see the Fontmap in the docs, but not sure where it's supposed to live⦠don't see it in my install. | 18:25.16 |
| Robin_Watts | You can even use it in multithreaded mode if you're building it into your own app. | 18:25.20 |
| kens | linux_dr depends if you have a binary built with COMPILE_INITS=1 or 0 | 18:25.44 |
| karlheinz | I see, well I'm considering MuPDF. | 18:26.02 |
| linux_dr | I'm building from source⦠| 18:26.07 |
| kens | OK so do you have COMPILE_INITS set to anything special ? | 18:26.24 |
| | chrils what;'s the default on Linux ? 1 ? | 18:26.35 |
| | chrisl | 18:26.39 |
| chrisl | yes, default COMPILE_INITS is 1 | 18:26.56 |
| kens | OK so correct me if I say something stupid.... | 18:27.09 |
| | linux_dr : you need to have the resources on disk somewhere as well. You should find that fontmap is in ghostpdl/gs/Resource/Init | 18:27.41 |
| | You need to modify it (or copy it or whatever) and then use the -I switch to GS to tell it to include the directory as a search path | 18:28.09 |
| | I *think* that will work | 18:28.15 |
| linux_dr | at compile time? or does it need to be installed in /user/local? | 18:28.16 |
| kens | No you can do this at run-time | 18:28.30 |
| chrisl | Or in ghostscript-9.05/Resource/Init is you used the GS source distribution | 18:28.35 |
| kens | THe resoruces can be anywhere convenient | 18:28.46 |
| | NB I think fontmap redirects to fontmap.gs in the current source, so maybe yo uhave to modify that | 18:29.16 |
| | modify fotnmap.FS I mean | 18:30.10 |
| | I must be tired, my typing is deteriorating | 18:30.35 |
| linux_dr | so is there a way to define meta-fonts that cascade through multiple possible fonts before resulting in /.notdef? | 18:35.00 |
| chrisl | no | 18:35.12 |
| | linux_dr: huh, when I run your file here, I get pi/8 | 18:37.42 |
| kens | I didn't | 18:37.56 |
| | I just /8 | 18:38.05 |
| chrisl | Oh, damn, wrong window - I was using the UFST! | 18:38.32 |
| kens | :-) | 18:39.04 |
| | I guess it proves its the font though | 18:39.15 |
| | Substituting fonts is never good | 18:39.25 |
| chrisl | Can we use TTFs to substitute fonts? | 18:39.28 |
| kens | Yes, shoudl be fine | 18:39.36 |
| | Just don't ask me for the syntax.... | 18:40.38 |
| chrisl | Hmm, UFST giving me a headache, I think I'll finish now! | 19:27.17 |
| kens | tor8 Robin_Watts can one of you answer thies please ? Or tell me and I'll reply for you: | 20:12.53 |
| | http://stackoverflow.com/questions/11507424/is-it-possible-to-save-a-modified-pdf-using-mupdf | 20:12.53 |
| tor8 | kens: Robin_Watts added a pdf_write_document function that should be callable, but it's a post 1.0 addition which is only in the git. in 1.0 you need to copy some code from mupdfclean.c to do it. | 20:14.20 |
| kens | OK I'll reply and tell him | 20:14.34 |
| | tomorrow ;-) | 20:14.40 |
| JohnCC330 | Hello all... I have this script which 'manually' generates Postscript files. The files aren't too large - about 600kB. Strange is that rendering them in gv, vertical lines take large amounts of time | 21:05.01 |
| | After splashing the horizontal on screen in about a second, the verticals take nearly a second each. | 21:05.37 |
| | BTW, they're much shorter than the horizontal ones ... Any suggestions? | 21:06.23 |
| alexcher | Perhaps, vertical lines are drawn dots, multiple images, etc. PostScript language has loops. The size of the files is not important. | 21:09.41 |
| JohnCC330 | No, all lines are pure moveto/lineto commands. | 21:10.21 |
| alexcher | Put your file somewhere for download. | 21:11.21 |
| JohnCC330 | http://www.jcoppens.com/pp_plot_0.ps.gz | 21:15.07 |
| | It flies with 'evince' (poppler library) | 21:17.00 |
| alexcher | johnCC330: The file takes 1.3 seconds for me to render in the current development version. Older versions take about the same time. | 21:26.32 |
| JohnCC330 | Here it takes minutes (AMD64, 2.6GHz, 2 GB RAM) | 21:27.48 |
| | GS is probably old - version 9.00, could that be the reason? | 21:28.51 |
| alexcher | johnCC330: I also have AMD64 box, T1100 is not fast for a single thread program. | 21:30.20 |
| JohnCC330 | I see that slackware-current is at 9.02, which isn't all that different... I was surprised that evince showed the file in about 1 second. | 21:31.29 |
| alexcher | johnCC330: v. 9.00 and v. 9.02 are faster then current HEAD. | 21:32.54 |
| | johnCC330: I've just tested them. | 21:33.40 |
| | johnCC330: What's your command line? | 21:34.27 |
| JohnCC330 | I didn't use a command line, but Ghostview as front end | 21:35.33 |
| alexcher | johnCC330: The file has broken DSC comments. Most likely Ghostview is trying to parse them and searches the whole file. | 21:37.27 |
| | johnCC330: remove PS-Adobe -3.0 from the file and try again. | 21:38.52 |
| JohnCC330 | gs <filename> shows the file almost instantly, but doesn't permit scrolling. Maybe it's gv which has problems with the large canvas? | 21:39.26 |
| ray_laptop | mvrhel: are you available ? | 21:39.40 |
| | sorry I was out this AM (till just now). Our bank account had a fraudulent w/d for a large amount -- I had to go change accounts | 21:40.40 |
| JohnCC330 | alexcher: Removed the Adobe part, I suspect the %!PS is necessary. This renders VERY fast, but doesn't allow scrolling either | 21:41.59 |
| | %%DocumentMedia: Custom 13464.000000 720.000000 0 () () <--- I suspect this needs level 2 or 3 to work. | 21:43.43 |
| alexcher | johnCC330: I didn't notice the custom page size. DSC comments are mostly ignored by PS interpreters and GS developers. | 21:49.06 |
| | You file needs <</PageSize [13464 720]>> setpagedevice | 21:50.28 |
| JohnCC330 | alexcher: I didn't find any other way to change the pagesize which actually worked. | 21:50.38 |
| | I tried that, it didn't seem to have any effect. Any place in particular? | 21:51.11 |
| alexcher | johnCC330: Put it just after the header comments. | 21:51.59 |
| JohnCC330 | alexcher: Interesting... GV ignores it, gs does enlarge the view to the width of the screen | 21:52.54 |
| alexcher | johnCC330: you can also convert your file to PDF and use any PDF viewer, for instance Evince. | 21:54.43 |
| JohnCC330 | GS seems to call gv with an option -dFIXEDMEDIA Could that be the problem? | 21:56.01 |
| | Sorry - GV calls GS, of course | 21:56.20 |
| alexcher | johnCC330: Yes, this stops any page size changes. | 21:56.48 |
| JohnCC330 | alexcher: No difference... still no scrolling. The complete command line, according to the preferences is: | 21:59.47 |
| | -sDEVICE=x11 -dTextAlphaBits=4 -dGraphicsAlphaBits=2 -dMaxBitmap=10000000 -dNOPLATFONTS | 22:00.07 |
| | alexcher: Well, this is for the magicians... And fairly sure it's actually GV. Called with the same options on the command line, GS just flies... | 22:02.47 |
| alexcher | BTW, if you make an EPS file, it needs valid DSC comments. If you make a PS file it needs showpage at the end. | 22:04.35 |
| JohnCC330 | alexcher: Thanks, I hadn't noticed that showpage was missing. It was there at some point. With all the changes in the script... | 22:07.05 |
| alexcher | johnCC330: Convert your file to PDF as: ~/ghostpdl/gs/bin/gs -sDEVICE=pdfwrite -o pp_plot_0.pdf pp_plot_0.ps | 22:09.38 |
| | johnCC330: And use any PDF viewer. | 22:09.55 |
| JohnCC330 | Just tried with ps2pdf, and it works fine. The missing showpage didn't help for GV. | 22:11.53 |
| | By default pdfs open in evince, which doesn't have a problem with the .ps either... | 22:12.36 |
| | Well, I'm not sure if I should report this on a bug list... I can work around it, but I dislike such glitches... | 22:19.25 |
| | Thanks, Alex! | 22:19.37 |
| alexcher | johnCC330: Ghostscript developers don't maintain gv. You can file a bug report for your Linux distribution. | 22:24.03 |
| JohnCC330 | Ok, Alex... Will do that. Cheers... | 22:24.49 |
| | Forward 1 day (to 2012/07/17)>>> | |
IRC Logs