| | <<<Back 1 day (to 2012/06/03) | 2012/06/04 |
| kens | ping chrisl | 08:44.58 |
| chrisl | kens: pong | 08:46.47 |
| kens | chrisl I'm looking at a 'accumulation' problem with fonts and pdfwrite. | 08:47.05 |
| | THe problem occurs because pdfwrite thinks 2 subset fonts are the same and they are not. | 08:47.21 |
| | This wouldn't happen except that the subset fonts have the 'subset prefix' trimmed off them | 08:47.37 |
| | SO they appear to be the same | 08:47.44 |
| | Do you have any idea where that happens, and is there anywhere else I can get the name with teh subset prefix ? | 08:48.11 |
| chrisl | Hmm, I do seem to remember that, but I can't remember where... let me have a look at the code.... | 08:48.51 |
| | Oh, it's done in pdf_font.ps : /.remove_font_name_prefix | 08:50.16 |
| kens | Oh great :( | 08:50.24 |
| | And it doesn't make a copy of the original font name. | 08:50.37 |
| | I bet | 08:50.41 |
| | Any idea why it does that ? | 08:50.56 |
| chrisl | No idea - there's no comment to explain it. And, it doesn't seem to save the original font name anywhere, either..... | 08:51.32 |
| kens | Well, looks like I'm going to have to do something about it. THere is no way to tell these two fonts apart in the pdfwrite code. | 08:52.00 |
| | So pdfwrite assumes thay are the same | 08:52.08 |
| | I suspect this si the same problem as that nutter with the diameter symbol too | 08:52.28 |
| chrisl | Can pdfwrite access the font dictionary? | 08:52.43 |
| kens | The PostScript font dictionary ? | 08:52.57 |
| chrisl | Yes | 08:53.00 |
| kens | I guess os, if its attached to the gs_font structure somewhere | 08:53.13 |
| chrisl | The dictionary is under the opaque "client_data" (or something) pointer in the gs_font_base structure | 08:53.50 |
| kens | OK well I have access to that, certainly | 08:54.05 |
| chrisl | I didn't know if pdfwrite was allowed to see into a Postscript ref object | 08:54.42 |
| kens | pdfwrite tends to poke its nose everywhere | 08:54.58 |
| chrisl | .remove_font_name_prefix was added by Igor..... | 08:55.39 |
| kens | Oh great, I don't suppose his commit explains it either ? | 08:55.55 |
| | I'm guessing it was for pdfwrite though | 08:56.09 |
| chrisl | No I think this is wrong, give me a sec | 08:56.47 |
| | kens: see http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=c71461c1 | 08:57.30 |
| kens | Yes, as expected, it is for pdfwrite, and doesn't say why..... | 08:58.00 |
| | THis, of course, isn't a CIDFont | 08:58.15 |
| chrisl | It doesn't mention pdfwrite...... | 08:58.35 |
| kens | Hmm, good point. | 08:58.46 |
| | Absolutely no explanation though | 08:59.08 |
| chrisl | It says "removes the subset font name prefix when computing a substitute font name" - but a non-embedded font shouldn't have a subset prefix..... | 08:59.18 |
| kens | Indeed | 08:59.35 |
| chrisl | There is a bug reference: Bug 687747 | 09:00.06 |
| kens | Presumably he wants to use the 'undecorated' name to try and find a substitute | 09:00.06 |
| | Yeah, I'm looking at the bug report | 09:00.16 |
| | It doesn't help at all | 09:00.38 |
| | And of course there are 4 patches | 09:01.21 |
| chrisl | Well, two patches, and back ported versions | 09:01.43 |
| kens | Second patch just seems to be documentation | 09:01.57 |
| | I *think* he's only removing the subset prefix for lookup in cidfmap | 09:02.23 |
| | And of course the font I have here *is* a CIDFont. The usual propensity for declaring everything as a CID. | 09:03.14 |
| | Ah, I think its only a CIDFont because of our TrueType fotn loading | 09:04.10 |
| | Yes, seems we are stripping the prefix from non-CIDFonts as well | 09:05.11 |
| chrisl | Yes we are - the thing is, with an embedded font, I wouldn't expect to get to that code..... | 09:05.38 |
| kens | Well, *something* is stripping the font name prefix. | 09:05.53 |
| | Let me stick a == in there | 09:05.59 |
| | Nope, doesn't go through there | 09:06.52 |
| chrisl | Hmm, okay - are we using the BaseFont or something, instead of the FontName? | 09:07.34 |
| kens | I'm looking at the FontName member of the gs_fotn structure | 09:07.52 |
| chrisl | But where is that coming from? | 09:08.12 |
| kens | That I don't know :( | 09:08.20 |
| | The BaseFont name has hte prefix applied in the original document | 09:08.49 |
| | As does hte FontName in the FontDescriptor | 09:09.10 |
| | THis is a TrueType font by the way | 09:09.38 |
| chrisl | Hmm, so two subsets in the same "context" wouldn't really work with rendering, either? | 09:09.59 |
| kens | I'm not certain. The fonts are in different PDF files, so that's probably why we get away with it | 09:10.26 |
| | Let me send you the 2 files | 09:10.43 |
| chrisl | Okay. | 09:10.52 |
| kens | There's a lot of garbage in them but it doens't do anything | 09:11.04 |
| chrisl | Maybe I'll get some coffee...... | 09:11.20 |
| kens | Probably a good idea | 09:11.30 |
| | Just remembered GMail does stupid things with .zip files, and sent it again as a .zpi file. You may need to rename it. | 09:16.12 |
| chrisl | Oh, lots of fonts.... | 09:18.05 |
| kens | Only 1 really | 09:18.13 |
| | I cut the rest out | 09:18.21 |
| chrisl | Hmm, am I being silly? I'm not seeing pdffindfont being called at all....... | 09:21.41 |
| kens | You did set -I/... so that its not using romfs ? | 09:21.59 |
| chrisl | Yep | 09:22.11 |
| kens | That's odd. | 09:22.17 |
| | Can't see how it would load the font at all without going in there | 09:22.30 |
| | Hmm, doesn't get there for me either | 09:23.45 |
| | Must be a different path | 09:23.53 |
| | Oh, find a font (exept for embedded ones) | 09:24.15 |
| | Says the comment | 09:24.20 |
| chrisl | Well, comments are usually wrong....... | 09:24.55 |
| kens | It does go through 'readtruetype' | 09:27.09 |
| | and tehn loadpdfttfont | 09:28.36 |
| chrisl | Which, of course, isn't in the PDF code...... | 09:29.10 |
| kens | No, seems to be a C operator | 09:29.19 |
| | 'maybe' | 09:29.27 |
| | Trying to grep for it now | 09:29.35 |
| chrisl | it's in gs_ttf.ps | 09:29.44 |
| kens | Oh, of course.... | 09:29.52 |
| chrisl | Oh, looks like we get the FontName from the TTF name table | 09:32.07 |
| kens | Well that would explain it. | 09:32.22 |
| | But that's not really good enough for pdfwrite. | 09:32.34 |
| | OTOH I'm not sure what to do about it. | 09:33.03 |
| chrisl | Well, it's not really good for anything - like I said, what if you have two incompatible subsets referenced from the same content stream? | 09:33.13 |
| kens | I suspect that, while possilbe, nobody really has 2 subsets of the same font in the same content stream :) | 09:33.45 |
| | Because its more efficient to have onse subset with teh total glyphs | 09:34.06 |
| | But you're right that its technically possible. | 09:34.15 |
| | I think this has to change. | 09:34.21 |
| | I'll poke at it some more, thanks for the pointers. | 09:34.40 |
| chrisl | I think .loadpdfttfont has to take a name parameter | 09:34.41 |
| kens | And loadttcidfotn in that case | 09:34.57 |
| | But yes. | 09:35.05 |
| chrisl | loadttcidfont already takes a name parameter - although it might not be used how we'd want..... | 09:35.48 |
| kens | It does ? I missed that | 09:35.57 |
| chrisl | <CIDSystemInfo dict> <file> <Substite name> .loadttcidfont | 09:36.09 |
| kens | Ah yes, so it does | 09:36.11 |
| | I think that's not right either mind you :) | 09:36.32 |
| | Looks ot me like that's the name Igor creates by stripping off the prefix | 09:36.49 |
| | Coffeee time | 09:37.14 |
| chrisl | kens: no, if you look in /readtruetype, .loadttcidfont gets called with the BaseFont name, which will be correct. | 09:38.16 |
| kens | What if hte font is not embedded ? | 09:39.00 |
| chrisl | If the font is not embedded we don't care about a prefix | 09:39.22 |
| kens | Oh, it can't get here if its not embedded :) | 09:39.35 |
| chrisl | So, I reckon .loadpdfttfont needs changed to work similarly to .loadttcidfont | 09:40.11 |
| kens | All of which rather makes me wonder about this business of stripping the prefix anyway. I'm beginning to think its pointless | 09:40.16 |
| | chrisl I htink you may be correct | 09:40.22 |
| | And in that case I probably won't have to change pdfwrite at all | 09:40.48 |
| chrisl | My guess is that the prefix stripping was to handle a broken file, where a non-embedded font had an erroneous prefix in the name *or* the font data was broken, and we try to carry on with a substitute | 09:41.39 |
| kens | That's what I thought, I should look at the file I suppose. But really, they shouold have been told 'its broken'.... | 09:42.08 |
| chrisl | the files from the original bug don't seem to be available :-( | 09:42.35 |
| kens | Typical | 09:42.46 |
| | There were a bunch of dupliacets though | 09:42.56 |
| chrisl | kens: what you *might* need to do is update the two ttf loading procedures to change the /FontName in the font dict, too..... | 09:43.04 |
| kens | That's possible, I'll look at this first | 09:43.22 |
| | chrisl #688232 | 09:43.43 |
| | No prefixes on that file. | 09:44.52 |
| chrisl | Not entirely convinces that's the same problem, tbh | 09:45.01 |
| kens | Me neither | 09:45.18 |
| | Well I think the prefix stripping is pointless, but it isn't causing a problem so I won't touch it | 09:46.18 |
| chrisl | Yeh, I agree - we can't be sure, of course, since the file(s) it actually purported to fix are long gone...... :-( | 09:47.05 |
| kens | Which is of course why we insist on people attaching them to the bug report :) | 09:47.25 |
| | I believe the ones Alex has marked as duplicates are not duplicates of this problem, unfortunately | 09:48.04 |
| chrisl | No, those "duplicates" look like normal missing CIDFont issues, which is not what the original issues appears to have been | 09:49.03 |
| kens | Indeed. | 09:49.10 |
| | I think you are correct, the original file must have had a prefix *and* a missing CIDFont, which is just mad. | 09:49.34 |
| | We should never have 'fixed' that. But since we did, I won't break it. | 09:49.54 |
| | If we had the file I'd test it with Acrobat, but as you say.... | 09:50.12 |
| Robin_Watts | appears to have forgotten how to type over the weekend. | 09:51.15 |
| chrisl | I've seen cases where that could happen with a "distiller" and forcing no font embedding. | 09:52.05 |
| | Robin_Watts: must of been all that jubilee partying :-) | 09:53.04 |
| Robin_Watts | Woo yay the Queen. | 09:53.17 |
| Robin_Watts | had a jubilee party here yesterday. Now weigh much more than I did before. | 09:53.47 |
| chrisl | did some DIY instead...... | 09:55.11 |
| kens | managed to sneak away from our street party on Saturday after 3 hours | 09:57.10 |
| | chrisl for what its woth, we also remove the prefix for an *embedded* font, but only if we fail to load the font for some reason. Of course the chanes of a substitute working as a replacement for a subset embedded fotn are pretty low, but I suspect this may be what was 'fixed'. | 10:43.35 |
| chrisl | kens: yep, that's what I thought - I'm guess Acrobat does something similar :-( | 10:48.03 |
| kens | Yes, probably. Looks like I may have a solution, I'm testing it now | 10:48.21 |
| Robin_Watts | I'm confused. | 10:54.41 |
| kens | I often am too | 10:55.03 |
| Robin_Watts | kens: Can you take a quick look at the last test I ran on the cluster please? | 10:55.19 |
| kens | OK one second | 10:55.27 |
| | ooh 486 diffs | 10:55.44 |
| Robin_Watts | scroll down to the diff at the end. | 10:55.55 |
| kens | OK which bit? | 10:56.11 |
| Robin_Watts | and look at the postscript changes in pdf_main.ps | 10:56.12 |
| kens | Yes ? | 10:56.45 |
| Robin_Watts | At the start of each page, where it calculates "PDFusingtransparency", I also calculate "DoKnockoutsForTransFills" | 10:56.58 |
| | which should be "PDFusingtransparency && device isn't high level | 10:57.14 |
| | " | 10:57.25 |
| kens | So you want to perform the following code if its *not* a high level device ? | 10:57.57 |
| Robin_Watts | and the changes in pdf_ops.ps are specifically guarded so that we shouldn't see any changes for pdfwrite. | 10:58.29 |
| | (i.e. we only use the new code if it's not highlevel and transparency is used) | 10:58.54 |
| kens | I think pdfwrite and ps2write are currently the only HighLevelDevice devices | 10:58.56 |
| Robin_Watts | Right. | 10:59.01 |
| kens | Well that seems to be what the code says | 10:59.27 |
| Robin_Watts | so why do I get 205 pdfwrite differences. | 10:59.32 |
| kens | Clearly it isn't working properly :) | 11:00.02 |
| | I'd get one fo the files that filas, and stick a 'dup ==' in there to see what the boolena is | 11:00.18 |
| Robin_Watts | Cunning. Will do. | 11:00.45 |
| kens | typing is also bad today | 11:00.46 |
| Robin_Watts | Oh, what a fool. | 11:03.01 |
| | pdfwrite is tested twice. | 11:03.09 |
| | Once to make a pdf, then once to render that pdf. | 11:03.19 |
| kens | :) | 11:03.24 |
| Robin_Watts | so the pdfwrite changes are probably fine. | 11:03.32 |
| | OK. Back to my previous base level of confusion then. Thanks! | 11:04.24 |
| kens | No problem | 11:04.52 |
| Robin_Watts | kens: Can you sanity check me please? gs/debugbin/gswin32c.exe -sDEVICE=pdfwrite -o map.pdf ../ghostpcl/tests/pdf/ | 11:35.29 |
| | Bug6901014_CityMap-evince.pdf | 11:35.31 |
| | The resultant map.pdf appears to have lost transparency information. | 11:35.50 |
| kens | That shouldn't happen, but its possible | 11:36.01 |
| | Want me to try it here ? | 11:36.09 |
| Robin_Watts | (there is supposed to be a border around the edge of the map) | 11:36.10 |
| | please. | 11:36.11 |
| kens | Yes transparent bnroder is missing | 11:38.10 |
| Robin_Watts | Ok, thanks. | 11:38.17 |
| kens | also the shopping centr | 11:38.23 |
| Robin_Watts | Should that be added as a new bug ? | 11:38.39 |
| kens | If you do I will ignore it :) | 11:38.51 |
| | I've known for some time that was incorrect | 11:39.01 |
| | But its a lto better than it used to be | 11:39.09 |
| Robin_Watts | better to have a record of the problem and have it ignored than to have no record and have it forgotten completely, IMHO. But if you know about it... | 11:39.38 |
| kens | Its not something I'm desperately bothered about, I have plenty of others to work on. | 11:39.57 |
| | Every time I fix something with patterns or transparency that file gets better. | 11:40.13 |
| Robin_Watts | will leave it then. | 11:40.17 |
| kens | Hmm, 2 diffs, better look at those | 11:40.58 |
| sebras | Robin_Watts: unfortunately I can not reproduce the issue even using my current version of mupdf. | 11:42.47 |
| | Robin_Watts: so I guess I might just as well download and install the latest version. | 11:43.13 |
| Robin_Watts | kens: What is the bloke on bug 693081 actually trying to do? | 14:10.51 |
| | Is he just trying to make sure that all the boxes on a page are proper subsets? | 14:18.57 |
| kens | Robin_Watts : your guess is as good as mine. | 14:19.15 |
| Robin_Watts | If it renders badly on android, then there is at least the possibility that he's using mupdf. | 14:19.26 |
| kens | Every time I answer his questions, the goalposts move a little further away | 14:19.29 |
| | Oh the rendering problem I know about | 14:19.39 |
| | I don't believe its MuPDF | 14:19.44 |
| | The reader is incorrectly using the CropBox instead of the MediaBox to display the page | 14:20.07 |
| | Since the CropBox is bigger than the MediaBox this is a problem for him | 14:20.25 |
| | I think I explained this in one of the earlier comments | 14:20.40 |
| Robin_Watts | It wouldn't sound like an absurd request for us to ensure that when changing the box sizes, we should ensure that all the boxes are proper subsets. | 14:20.45 |
| kens | Robin_Watts : there is no reason why the CropBox should be limited to the MediaBox | 14:21.04 |
| | And you definitely *don't* want to do that to teh BleedBox | 14:21.16 |
| | Using the CropBox is just wrong | 14:21.32 |
| | And I don't thin kwe should change it | 14:21.41 |
| Robin_Watts | Yes, clearly the reader is wrong. | 14:21.47 |
| kens | I'm not sure we cna reasonably change it anyway | 14:22.12 |
| | Maybe the PDF interpreter could, but pdfwrite only sees pdfmarks, so how do we know what's correct ? | 14:22.36 |
| | But the bug left that area behind long ago | 14:22.58 |
| Robin_Watts | fair enough :) | 14:23.16 |
| | hey scott-san | 14:33.16 |
| scott-san | Hi Robin. I got a query today from someone wanting to know if GS will work in 11X17 format?? | 14:34.04 |
| kens | If you request 11x17 then it will honour it | 14:34.26 |
| | Depends what he means by 'work' | 14:34.33 |
| Robin_Watts | I assume by "11x17" he means "11 inches x 17 inches" | 14:34.49 |
| | i.e. a media size. | 14:34.56 |
| scott-san | OK guys thanks. Thought that it would but thought I'd check. | 14:35.10 |
| kens | 11x17 is the name of a media size yes | 14:35.11 |
| Robin_Watts | as kens says, then yes, if you tell gs to use that size, it will oblige. | 14:35.14 |
| scott-san | Don't do this to me Robin:-) | 14:35.22 |
| Robin_Watts | ? | 14:35.37 |
| scott-san | OK Thanks! See you guys later. | 14:35.50 |
| Robin_Watts | see you! | 14:35.59 |
| | Is there a debug option to make the PDF interpreter list the PDF operators it executes? (Rather than the ps ones) | 15:47.29 |
| kens | -dPDFDEBUG dumps the objects | 15:50.27 |
| | more or less | 15:50.33 |
| Robin_Watts | Spot on, thanks. | 15:51.40 |
| kens | NP | 15:51.53 |
| henrys | kens, Robin_Watts:isn't it a holiday for you guys? | 15:52.11 |
| kens | Technically | 15:52.18 |
| Robin_Watts | Today and tomorrow, yes. | 15:52.22 |
| | but I'm working 'em. | 15:52.33 |
| kens | Me too | 15:52.37 |
| | chrisl also I imagine | 15:52.48 |
| Robin_Watts | (and chrisl too, I think) | 15:52.49 |
| | paulgardiner may not may not be around tomorrow. | 15:53.05 |
| | paulgardiner may or may not be around tomorrow. | 15:53.14 |
| henrys | okay | 15:53.30 |
| ray_laptop | morning, all | 15:54.35 |
| kens | Morning ray_laptop, mvrhel | 15:54.46 |
| Robin_Watts | mvrhel: Hey. | 15:54.52 |
| ray_laptop | Robin_Watts: did you want -dPDFDEBUG ? | 15:54.52 |
| mvrhel | good morning | 15:54.56 |
| Robin_Watts | ray_laptop: I did, and kens beat you too it (though it may not be in the logs yet :) ) | 15:55.11 |
| ray_laptop | (logs may be lagging and someone else may have said something) | 15:55.16 |
| Robin_Watts | but thanks anyway. | 15:55.18 |
| | mvrhel: I'd imagine that you're the prime user of "RAW_DUMP". | 15:55.36 |
| | Would you object if I tweaked some of the filenames it produces? | 15:55.54 |
| mvrhel | Robin_Watts: why. I know at one point you had committed as a default your PAM output but I prefer my raw output | 15:56.41 |
| ray_laptop | Robin_Watts: you can also use -dPDFSTEP to watch stuff as it is drawn (useful to 'display' or 'x11' devices). It isn't useful with transparency, however, so sometimes I run it with -dNOTRANSPARENCY | 15:56.42 |
| Robin_Watts | (specifically "Trans_Group_Pop" =>"aTrans_Group_Pop", "ImageTOS" => "bImageTOS", "ImageNOS" => "cImageNOS" etc | 15:56.44 |
| | so that they appear in alphabetical order in the order they are made. | 15:57.03 |
| mvrhel | I see. that is fine with me | 15:57.23 |
| Robin_Watts | Makes it much easier for my tiny brain to cope with walking through them. | 15:57.28 |
| | Thanks. | 15:57.38 |
| mvrhel | As long as the global number remains | 15:57.46 |
| ray_laptop | Robin_Watts: I recommend two letter prefixes (a'la "split" names) | 15:57.46 |
| mvrhel | which keeps them in order for me | 15:57.53 |
| Robin_Watts | Yes. Can i make the global number always 2 digits? | 15:57.57 |
| | ray_laptop: I don't follow. Every pdf14 pop or push gets it's own 'generation number', so we get names like: | 15:58.44 |
| mvrhel | that is fine | 15:58.47 |
| ray_laptop | I have seen > 100 images from raw dump | 15:58.50 |
| mvrhel | yes. but generally when it is the large, it is better to limit the band that does the dump | 15:59.16 |
| | as you are likely in clist mode | 15:59.19 |
| Robin_Watts | 0)Device_Push 1)Trans_Group_Push 2)Composed 2)ImageNOS 2)ImageTOS 2)Trans_Group_Pop 3)Trans_Group_Push | 15:59.24 |
| mvrhel | > 100 within a band is uncommon | 15:59.38 |
| | unless you are dumping every rect fill | 15:59.44 |
| ray_laptop | mvrhel: agreed. | 15:59.48 |
| Robin_Watts | The main thing is that with 2 digits it's going to be in alphabetical order most of the time. | 16:00.09 |
| mvrhel | I have not had a problem with it. But if if helps you sounds good | 16:00.41 |
| ray_laptop | Robin_Watts: for alphabetic sort order, I was recommending aa ab ac .. az ba bb bc ... | 16:00.48 |
| Robin_Watts | ray_laptop: The purpose of adding 'a', 'b', 'c', 'd' etc in after the ')' is so that the steps within a given push/pop operation are in order. | 16:01.13 |
| | And there are at most 5 steps in any given generation. | 16:01.21 |
| | so double digits there seems overkill. | 16:01.29 |
| ray_laptop | Robin_Watts: I thought you were putting the prefix _before_ the number (or instead of) | 16:02.08 |
| Robin_Watts | No. | 16:02.15 |
| ray_laptop | sorry | 16:02.20 |
| Robin_Watts | np. | 16:02.25 |
| ray_laptop | but numeric prefixes without the leading '0' don't sort properly (by default) past '9' | 16:03.18 |
| Robin_Watts | ray_laptop: Hence my secondary request for 2 digit prefixes. | 16:04.45 |
| ray_laptop | Robin_Watts: I concur with that | 16:05.05 |
| Robin_Watts | (or "at least 2 digit" prefixes) | 16:05.09 |
| mvrhel | if you want 3 make it 3 | 16:05.41 |
| Robin_Watts | This means I can convert the pam's to png's then "start 0)DevicePush.png" and just hit right to step through them. | 16:05.42 |
| mvrhel | just dont make pam the default output | 16:06.00 |
| | please | 16:06.05 |
| ray_laptop | going to 'split' style prefixes would sort correctly up to 675 levels | 16:06.06 |
| Robin_Watts | ray_laptop: But we want the generation number separate to the order within the generation. | 16:06.26 |
| | mvrhel: Sure. | 16:06.35 |
| | If a problem only occurs with more than 99 generations, then there is no hope of me ever solving it :) | 16:07.21 |
| ray_laptop | Robin_Watts: I understand, and numeric 3 digit generation # would be fine, might be more meaningful than aa)a... | 16:07.25 |
| | Robin_Watts: good point. I was just surprised one time how many images I ended up with | 16:08.08 |
| | Robin_Watts: I noticed (a few days ago) kens giving a rather involved PS sequence to query the device parameter's "HighLevelDevice" status. If it is something that gets checked often (when checking the PDF for transparency), it is perfectly OK to check once and create a "DeviceIsHighLevel" in the pdfdict so it will be a quck check | 16:16.27 |
| Robin_Watts | ray_laptop: I only need to check it once per page. | 16:16.44 |
| | I moved over to that involved sequence in my local version this morning. | 16:17.05 |
| | and stripped out my new operator. | 16:17.14 |
| ray_laptop | Robin_Watts: OK. I wasn't sure. I knew the pageusestransparency can be rather lengthy | 16:17.43 |
| Robin_Watts | ray_laptop: Right. pageusestransparency is run once per page. | 16:18.03 |
| | At the same time I make a new thing "UseKnockoutsWhenFillingTransparency" (or something) | 16:18.24 |
| | which is pageusestransparency && !pdfwrite | 16:18.42 |
| | and then the new code is conditional on that. | 16:18.56 |
| ray_laptop | Robin_Watts: do you only do the knockout for complex paths ? | 16:19.01 |
| Robin_Watts | At the moment, I'm doing it for all paths | 16:19.14 |
| | but if I remove the comment from the start of the next line, it does it only for complex paths. | 16:19.31 |
| ray_laptop | I thought you determined that doing it for all (including simple) paths caused a performance hit | 16:19.42 |
| Robin_Watts | .pathcomplexity 100 gt and | 16:19.59 |
| ray_laptop | Ahh.. I thought you said you had stripped out your new operator | 16:20.21 |
| Robin_Watts | No, I had a new ".devicecapabilities" operator to quickly query high level or not. | 16:20.48 |
| ray_laptop | I see. I had missed mention of that | 16:21.12 |
| Robin_Watts | That's the one I backed out in favour of kens thing. | 16:21.14 |
| kens | OK I'm off now. | 16:21.19 |
| | Night all | 16:21.22 |
| Robin_Watts | night kens. | 16:21.24 |
| ray_laptop | bye, kens | 16:21.27 |
| mvrhel | bye kens | 16:21.33 |
| ray_laptop | Robin_Watts: please mention in your commit log (when you get to it), that something similar probably should be added to the XPS interpreter | 16:22.57 |
| Robin_Watts | I will | 16:23.28 |
| ray_laptop | Robin_Watts: thanks | 16:23.33 |
| Robin_Watts | mvrhel: Why do you strokepath in the /f and /f* cases ? | 16:32.31 |
| mvrhel | If I do, that was a mistake | 16:32.53 |
| Robin_Watts | ok. I don't imagine it's harmful, but... | 16:33.10 |
| mvrhel | Robin_Watts: off to coffee shop .bbiab | 16:34.16 |
| ray_laptop | Robin_Watts: why do you think it is doing that? 'fsexec' gets an operator | 16:34.24 |
| Robin_Watts | ray_laptop: http://bugs.ghostscript.com/attachment.cgi?id=8638 | 16:34.46 |
| ray_laptop | and I see it getting /fill or /eofill (pdf_ops.ps) | 16:34.47 |
| Robin_Watts | ray_laptop: You don't have this patch. | 16:34.59 |
| ray_laptop | Robin_Watts: sorry - I'm looking at HEAD code. | 16:35.23 |
| | stroking for 'f' or 'f*' would be a problem | 16:35.36 |
| Robin_Watts | ray_laptop: He's not stroking per-se. | 16:36.05 |
| | He's stroking the path before feeding it to pathbbox. | 16:36.16 |
| | So he'll be getting a slightly larger bbox than he would otherwise. | 16:36.28 |
| ray_laptop | Robin_Watts: strokepath is needed to get the bbox, right ? | 16:36.31 |
| Robin_Watts | ray_laptop: Why can't we just call pathbbox by itself ? | 16:37.30 |
| ray_laptop | Robin_Watts: right. That should be OK for the fill. I was catching up to where you were. | 16:39.10 |
| | I hadn't seen that patch. | 16:39.39 |
| Robin_Watts | except... removing the strokepath causes loads of errors. | 16:40.27 |
| | we go into a seeming infinite loop with it complaining of mismatched q/Q operators. | 16:40.45 |
| mvrhel | that was all done due to my muddling through the PS code without understanding. the patch was far from complete nor without bugs | 16:45.11 |
| Robin_Watts | sure. | 16:45.20 |
| mvrhel | Robin_Watts: sorry that it was not 100 percent for you | 16:45.31 |
| Robin_Watts | no worries - if it was 100% then I wouldn't have had to work on it :) | 16:45.48 |
| mvrhel | next time I will be sure to get a warrenty out to you :) | 16:45.55 |
| Robin_Watts | OK. I just redid the removal of the strokepath, and as expected no difference to what I'm seeing. | 16:48.22 |
| | I have a dead simple test file now where it's going wrong. | 16:48.38 |
| | and it's pointed something out to me that I should have twigged before. | 16:48.53 |
| | We are currently saying "If the page uses transparency then do this operation in a knockout group". | 16:49.22 |
| | Shouldn't it be "if transparency is in operation now, then use a knockout group" ? | 16:49.42 |
| | otherwise we'll be introducing lots of knockout groups when we don't need to. | 16:49.57 |
| | i.e. rather than PDFusestransparency should we use: ".currentopacityalpha 1.0 ne .currentBlendMode /BMNormal ne or" | 16:51.16 |
| ray_laptop | Robin_Watts: that makes sense -- we really only need to do "correct" painting when the alpha or BM requires it. Note there are two alpha values (that I always need to check to see which does what) | 16:55.44 |
| Robin_Watts | Gah. | 16:58.25 |
| | I do 1 .setopacityalpha inside the transparencygroup. | 16:58.44 |
| | Then something is setting it back to 0.5 again. | 16:58.56 |
| | presumably something bound into the setfillstate | 16:59.09 |
| ray_laptop | Robin_Watts: setfillblend does .settransparencyparams | 17:01.21 |
| | (all iin pdf_ops.ps) | 17:01.35 |
| Robin_Watts | yeah, thanks - just twigging to that now. | 17:01.42 |
| ray_laptop | mvrhel: I am able to reproduce (exactly) the symptoms reported with http://bugs.ghostscript.com/show_bug.cgi?id=692542 . Wite NumRenderingThreads=1 I get a "double free' from gdev_prn_free_memory during clist_teardown_render_threads. | 17:26.56 |
| mvrhel | ray_laptop ok | 17:27.21 |
| | I am working on the aa stuff now | 17:27.29 |
| | if I can help you on this let me know | 17:28.11 |
| | or do you want me to work on it since I caused the issue | 17:28.28 |
| ray_laptop | With NumRenderingThreads=2 I get a malloc problem from the cms during gsicc_get_profile_handle_buffer while setting up the render_threads | 17:29.20 |
| | mvrhel: I'll work on it for now, but I may consult with you | 17:29.46 |
| mvrhel | did this exist prior to my changes in tiff sep? | 17:29.50 |
| ray_laptop | mvrhel: i don't know -- I haven't gone back to earlier code | 17:30.12 |
| mvrhel | ok just curious | 17:30.20 |
| ray_laptop | mvrhel: this also has Robin_Watts' gx_downscaler_get_bits_rectangle changes in | 17:30.56 |
| mvrhel | ah that explains it | 17:31.08 |
| | just kidding | 17:31.11 |
| ray_laptop | so you both can point to the other guy ;-) | 17:31.22 |
| mvrhel | ok course if I look at the git logs | 17:31.22 |
| | that big commit with tiffsep says Robin_Watts | 17:31.34 |
| Robin_Watts | and this one with transparency is going to say mvrhel :) | 17:31.56 |
| mvrhel | ha | 17:32.00 |
| ray_laptop | mvrhel: this is actually happening with the psdcmyk device -- I haven't bothered with tiffsep (yet) | 17:32.15 |
| mvrhel | ok | 17:32.23 |
| | psd device is wacky | 17:32.28 |
| | on how it gets its lines for each color band | 17:32.45 |
| | I see your comment in the bug | 17:33.00 |
| ray_laptop | with tiffsep I get different failures. with Threads=1 it gets a malloc problem in TIFFmalloc -- with Threads=2 the failure is similar to the psdcmyk device (cms malloc) | 17:36.52 |
| | so maybe I'll just do tiffsep for now, then after finding/fixing that check the psdcmyk device | 17:37.45 |
| | unfortunately I don't get any failures on Windows (at least with 32-bit). | 17:38.13 |
| | trying 64-bit on Windows next | 17:38.23 |
| | darn. 64-bit doesn't fail on Windows either | 17:50.22 |
| | at least it isn't too indeterminate on peeves | 17:51.03 |
| Robin_Watts | release or debug? | 17:51.08 |
| ray_laptop | Robin_Watts: debug build fails (thankfully) | 17:51.21 |
| Robin_Watts | That makes it much easier. | 17:51.37 |
| | helgrind ? | 17:51.45 |
| ray_laptop | Robin_Watts: maybe -- I need to look at the "simple" case (Threads=1) first since that _should_ be the simplest | 17:52.35 |
| | the 'main' thread should just be waiting for the rendering thread to finish | 17:53.14 |
| | have to run an errand. bbiab. | 17:54.03 |
| Robin_Watts | Damn. I really hoped I'd got it that time. | 19:19.56 |
| mvrhel | got whaty | 19:25.48 |
| | what | 19:25.50 |
| Robin_Watts | I hoped I'd found the problem with the transparency stuff. | 19:27.11 |
| mvrhel | gotcha | 19:29.03 |
| | bbiab | 19:29.07 |
| | lunchtime | 19:29.09 |
| Robin_Watts | chrisl_away: For the record, there are known problems with the parallel make. | 19:45.41 |
| | The cluster does make -j 8 && make for that reason. | 19:45.55 |
| Gigs- | Did the SVN address change? | 20:05.54 |
| | oh git only I see, nevermind | 20:06.13 |
| Robin_Watts | OK, it's an SMask that's causing the problem with this file. Seems like a good place to leave it. | 23:52.48 |
| | Forward 1 day (to 2012/06/05)>>> | |
IRC Logs