| | <<<Back 1 day (to 2015/02/19) | 20150220 |
| mvrhel_laptop | argh. psdcmyk and tiffsep have wrong number of components when I set SeparationColorNames and SeparationOrder. Something is wrong | 00:32.41 |
| Robin_Watts | I feel for you. | 00:32.57 |
| | That code has always felt fragile to me. | 00:33.11 |
| | frangible. | 00:33.30 |
| mvrhel_laptop | oh I see. It is still setting the damn number of colorants based upon the document contents, blowing away what was correct | 00:37.34 |
| | need to detect that and make sure it does not happen | 00:37.45 |
| | blah. not sure how best to do this really | 00:41.17 |
| | need to be careful that I don't break the case where we have NCLR output profiles too | 00:44.01 |
| | ok. I think I have a solution for the psd and tiffsep devices which will work for me. will run idea by you all in the morning | 06:02.38 |
| | done for the night | 06:18.36 |
| mulover | Hi! Is there any way using mudraw to do accurate color space conversion for a given cmyk pdf to generate a proper looking png? Or do i have to use ghostscript before and afterwards mudraw? | 12:12.55 |
| chrisl | mulover: just use Ghostscript | 12:13.21 |
| kens | At the present time MuPDF doesn't allow you to do colour management | 12:13.24 |
| | And as Chrisl says,GS can produce PNG files on its own | 12:13.39 |
| mulover | I was afraid of this answer ;-) The last time i tried ghostscript, the rendering results were poorer than mudraws. | 12:14.35 |
| chrisl | Define "poorer" | 12:14.48 |
| mulover | Font-Rendering: Antialiasing and Glyph rendering was way better with mudraw | 12:15.35 |
| chrisl | So, tell Ghostscript to anti-alias text | 12:15.48 |
| kens | Given that GS and MuPDF both use FreeType, it can be anything to do with glyph rendering :-) | 12:16.25 |
| chrisl | Except that mupdf uses freetype's antialiasing and Ghostscript doesn't - but when I tested it, the results were all but indistinguishable | 12:17.12 |
| kens | Well, he did separate glyph rendering and anti-aliasing.... | 12:17.44 |
| chrisl | True, yes | 12:17.55 |
| mulover | I believe you guys :-) I have to admit, it is some years ago. But even with high antialising switches on, mudraw performed better. The glyphs had somehow wrong spaces between them IMHO. | 12:18.24 |
| chrisl | mulover: you might find that at low resolutions - mupdf's rendering is better optimised for low resolutions | 12:19.12 |
| mulover | That sounds plausible. I was able to work around the issue by rendering a way to big image and shrink it afterwards. Very ugly, but it helped. | 12:20.47 |
| kens | Several GS devices (but not PNG) can do that internally | 12:21.21 |
| | tiffscaled devices for example | 12:21.34 |
| chrisl | Don't the png devices support DownScaleFactor now? | 12:22.54 |
| kens | Err, do they ? | 12:23.06 |
| | Its possible..... | 12:23.13 |
| | In which case, try that :-) | 12:23.21 |
| chrisl | I thought Robin_Watts extended it to support a lot of devices.... | 12:23.33 |
| kens | I'm not sure | 12:23.55 |
| mulover | Ok! That was always kind of an issue for me with ghostscript. Many options, many changes.... | 12:24.44 |
| kens | People keep wanting GS ot do different things, so yes, lots of options. Changes; not so many. | 12:25.23 |
| | If people complain about the anti-aliasing, we change it, its true, its hard to fix stuff without chaning it | 12:25.49 |
| chrisl | Yep, the png devices support DownScaleFactor | 12:26.31 |
| kens | OK so try that then, see if its acceptable | 12:26.42 |
| mulover | Did not want to complain at all. You guys do great work! | 12:26.43 |
| kens | People do complain about hte anti-aliasing, that's why RObin added the 'scaled' devices | 12:27.11 |
| chrisl | Er, not really..... | 12:27.27 |
| tor8 | mulover: if you can live with slow performance, render using gs at a high resolution then downsample to a smaller size. there's an option to do that in gs autmatically but I can't remember what. | 12:27.32 |
| kens | Really ? I thought that'sd why he did it | 12:27.42 |
| tor8 | bah, chrisl beat me to it :) use the downscalefactor option. | 12:27.49 |
| chrisl | kens: No, it was originally because a customer wanted to render pcl input at something other 300/600 dpi | 12:28.28 |
| kens | Damn, can anyone remember the runes to get Acrobat Distiller to allow the 'run' operator to work / I'm sure its a command line option but I can't remember it | 12:28.39 |
| chrisl | I don't think I've ever known it.... | 12:29.09 |
| kens | I know there is one, because people complained when they changed the behaviour (like our SAFER option) | 12:29.40 |
| mulover | Within todays trials i had another issue i dont understand. I used gs to convert the cmyk-pdf to a rgb one. Distiller told me things were right and showed the pdf with matching colors for the embedded image. mudraw though rendered them very dark. Like if used the cmyk one from before. I could work around that by setting CompatibilityLevel=1.3 inside the conversion. No matter if an old or new gs was used. Why is that? | 12:31.52 |
| kens | Its impossible to say without seeing the original PDF file and knowing the command line used. | 12:32.36 |
| Robin_Watts | gs -dDownScaleFactor=3 -sDEVICE=png16m -r600 -o out.png in.pdf | 12:33.14 |
| | That will get you in.pdf rendered at (effectively) 200dpi with antialiasing. | 12:33.32 |
| | mulover: You're saying that when you rendered a cmyk file in mupdf it was dark? So you converted it to rgb in gs and rendered it in mupdf and it was still dark? | 12:34.33 |
| | Sounds like the conversion worked well to me. | 12:34.38 |
| kens | Lunch, bbiab | 12:36.15 |
| mulover | I will try to provide an example :-) | 12:37.12 |
| Robin_Watts | tor8: bug695843 looks like glyphs are being rendered in bboxes too small or something. | 13:00.16 |
| kens | Its a regression, 1.6 has the problem, 1.4 doesn't | 13:01.24 |
| Robin_Watts | yeah, there is at least one Type3 font which has a font BBox of [0 0 1 -1] | 13:03.55 |
| kens | Hmm GS copes wiht it. | 13:04.10 |
| | It usually doesn't deal well with that sort of thing | 13:04.22 |
| Robin_Watts | If all four elements of the rectangle are zero, no assumptions are made based on the font bounding box. If any element is nonzero, it is essential that the font bounding box be accurate. If any glyphâs marks fall outside this bounding box, incorrect behavior may result. | 13:05.03 |
| | From the PDFRM | 13:05.09 |
| kens | Yeah but "Acrobat can display it".... | 13:05.35 |
| | THat BBox may be 'accurate' the FontMatric is 1 0 0 -1 0 0 | 13:06.56 |
| | Its hte same for all of them apparently | 13:07.47 |
| Robin_Watts | kens: It's not. 46 0 5 0 40 49 d1 | 13:08.25 |
| | which is a bbox of 0 5 -> 40 49 | 13:08.39 |
| | (possibly flipped due to the font matrix) | 13:08.55 |
| kens | It will definitely be flipped yes | 13:09.06 |
| | need to look at the setcachedevice1 args, can't recall them offhand | 13:09.18 |
| Robin_Watts | w w l b r t | 13:09.38 |
| kens | OK so the BBox is incorrect. | 13:09.58 |
| Robin_Watts | so possibly we need to make our d1 implementation check that the fontbbox isn't bollocks. | 13:10.25 |
| kens | I have a sneaky suspicion GS ignores type 3 font BBoxes because they are so often incorrect | 13:10.25 |
| Robin_Watts | If it is, abort and restart the draw process. | 13:10.34 |
| | ah, we now convert all type3's to display lists on loading, so we might be able to do better. | 13:12.05 |
| | hmm. We bound each glyph by measurement, then intersect it with a slightly expanded fontbbox. | 13:16.18 |
| | Presumably we don't like purely relying on the bbox of the glyph in case the glyph is stupidly huge. | 13:21.30 |
| mulover | So guys, looks like the problem might slightly different than i though before. For two simple calls, gs renders a png matching the output of Acrobat Reader / Pro. mudraw though renders a very dark version. Calls: mudraw v 1.6: mudraw -o mudraw.png cmyk.pdf gs v 9.04: gs -dBATCH -dNOPAUSE -sDEVICE=png16m -sOutputFile=ghostscript.png cmyk.pdf Link to the pdf: http://www.xup.in/dl,44565677/cmyk.pdf/ Link to preview from gs: htt | 13:21.57 |
| | Sorry, lines to long :-( Link to preview from gs: http://www.xup.in/dl,15704297/ghostscript.png/ Link to preview from mudraw: http://www.xup.in/dl,16805794/mudraw.png/ | 13:22.38 |
| kens | Well, the GS output matches Acrobat at leats in general tone | 13:23.28 |
| Robin_Watts | OK. gs uses proper color management, mupdf does not. | 13:23.29 |
| | mupdf has a hardwired rgb -> cmyk conversion. | 13:24.13 |
| | using a fairly simple matrix. | 13:24.21 |
| | gs uses color profiles (and has the same defaults as acrobrat, I think) | 13:24.44 |
| kens | THey're meant ot be similar at least | 13:25.00 |
| | Note that the PDF file has an OutputIntent ICC profile | 13:25.13 |
| Robin_Watts | hence those results don't surprise me at all. | 13:25.20 |
| | ah, well, there you go. | 13:25.26 |
| tor8 | Robin_Watts: warning: type3 glyph doesn't specify masked or colored | 13:25.48 |
| kens | So you won't get 'proper' results unless you use ICC colour management | 13:25.52 |
| tor8 | Robin_Watts: evince doesn't render the text either | 13:26.17 |
| | but gs does | 13:26.21 |
| kens | Eh ? That should be d0 or d1 shouldn't it tor8 ? | 13:26.25 |
| Robin_Watts | I see d1 being specified. | 13:26.39 |
| | I don't get that warning. | 13:26.42 |
| kens | d1 is a mask, d0 is a coloured type 3 IIRC | 13:26.50 |
| tor8 | but, ahem, maybe I shouldn't try running with my broken-in-pieces-mupdf that I just got compiling... | 13:26.53 |
| kens | :-D | 13:26.59 |
| mulover | If i "prepare" the pdf with a prior gs call with CompatibilityLevel=1.3, mudraw renders fine. | 13:27.23 |
| kens | CompatibilityLevel of 1.3 disables ICC colour I htink. You can almost certainly do better by using ColorConversionStrategy | 13:28.00 |
| tor8 | kens: I'm reworking how the pdf interpreter is hooked up, so type3 fonts are currently #if 0'd out :) | 13:28.02 |
| kens | ah! | 13:28.09 |
| | Ah, this PDF file also declares that it uses transparency | 13:29.13 |
| | With a Blending Mode of ColorBurn | 13:29.35 |
| mulover | I tried that too: gs -sDEVICE=pdfwrite -dBATCH -dNOPAUSE -dColorConversionStrategy=/sRGB -dProcessColorModel=/DeviceRGB -dUseCIEColor=true -sOutputFile=rgb.pdf | 13:30.03 |
| | No effect for mudraw. ONly with: | 13:30.12 |
| | gs -sDEVICE=pdfwrite -dBATCH -dNOPAUSE -dCompatibilityLevel=1.3 -dColorConversionStrategy=/sRGB -dProcessColorModel=/DeviceRGB -dUseCIEColor=true -sOutputFile=rgb.pdf | 13:30.13 |
| kens | OK firstly don't use -dUseCIEColor, that should have got you a big wrning saying 'DOn't do that' or words to that effect | 13:30.31 |
| | Secondly what is the version of GS you are using ? | 13:30.47 |
| tor8 | Robin_Watts: it's the bbox extraction that gets confused | 13:30.57 |
| Robin_Watts | yeah, I can see where it the code it goes wrong. | 13:31.46 |
| | OK, acrobat completely ignores the fontbbox, as far as I can tell. | 13:32.25 |
| mulover | Sorry, i had many tests, removing dUseCIEColor changed colors a bit, but did not make the difference. I tried the following versions: 9.04, 9,10 and 9.14 | 13:32.44 |
| Robin_Watts | but acrobat does honour the d1 bbox. | 13:33.09 |
| kens | mulover : all of those are too early really, you need at least 9.15 to get colour conversion halfway correct with pdfwrite. | 13:33.17 |
| Robin_Watts | so, a simple tweak is required. will look at that after lunch. | 13:33.32 |
| | tor8: Where did we land on the display list stuff? | 13:33.50 |
| kens | mulover but, fundamentally you need to be rendering using a PDF consumer which does ICCBased colour management. | 13:34.08 |
| Robin_Watts | the display list stuff got us to about 60% of the size on torture-test. | 13:34.23 |
| | With the path trimming, we hit about 30% of the size. | 13:34.47 |
| tor8 | Robin_Watts: I'm good with the display list stuff. is the path trimming on robin/master? | 13:35.05 |
| Robin_Watts | It is. | 13:35.10 |
| Robin_Watts | lunches. back in a bit. | 13:35.21 |
| tor8 | Robin_Watts: I'd be curious to see how a static-array at the end of fz_path would help, if that could let us avoid allocating the cmd/coord arrays | 13:36.21 |
| | for the majority of paths | 13:36.25 |
| mulover | Tried 9.15 too, no difference. OK, i understand. But shouldnt mudraw be happy if i supply a primarly to rgb converted version (by gs)? | 13:36.45 |
| tor8 | it'd be a bit invasive to let fz_moveto etc return a new pointer, in case they realloc the entire fz_path struct while constructing it | 13:37.11 |
| kens | mulover : you are assuming that the file *has* been converted to RGB, I suspect it has not | 13:37.17 |
| | But when you specify CompatibilityLevel of 1.3, it is. | 13:37.35 |
| mulover | At least Acrobat says so.... wait i will bring it online... | 13:37.44 |
| tor8 | Robin_Watts: I wonder if it wouldn't be clearer if we let the display list call fz_trim_path explicitly | 13:39.36 |
| | but this hidden approach is safer for all possible uses | 13:39.59 |
| mulover | The "might be rgb" ;-) http://www.xup.in/dl,13709086/rgb.pdf/ | 13:43.24 |
| | All i can see inside Acrobat tells me rgb | 13:43.43 |
| kens | Just a minute, I'm busy with something else for a few. | 13:44.22 |
| mulover | No problem. | 13:45.47 |
| henrys | there will be snow, check out the 10-day for Vail http://www.wunderground.com/cgi-bin/findweather/getForecast?query=vail%2Ccolorado | 13:51.29 |
| kens | OK it looks to me like the problem is that, as I mentioned earlier, the file uses transparency. If you don't blend in the specified colour space then you get differences in the output. This is quite visible when beldning in RGB as opposed to belnding in (additive vs subtractive colour models). By specifying PDF 1.3 you are going back to an earlier revision of PDF which does not support transparency. This causes pdfwrite to rende | 13:53.08 |
| | r the transparent area (all of it in this case) to an image. That's why you get the correct answer that way, and not any other. | 13:53.09 |
| | henrys if it stops snowing before Monday I'll be very happy :-) | 13:54.03 |
| | Looks moderately chilly | 13:54.37 |
| | mulover : I see signifcant differences between rgb.pdf and cmyk.pdf when vioewed in Acrobat. | 13:55.57 |
| | RGB.pdf ha an overall greenish tint | 13:56.21 |
| kens | fetches coffee | 13:57.32 |
| | BTW thanks for pointing me to the weather Henrys | 13:57.47 |
| mulover | For me here too, i was just stuck with acrobat <> mudraw :-) | 13:58.39 |
| kens | Well transparency is black (and evil) magic. The only way to get accurate colour management involving transparency is to render the transparent areas, and then colour manage. In effect that's what you are doing by setting CompatibilityLevel to 1.3 | 14:00.51 |
| | For *this* file that's no a huge concer, because its mostly a big image anyway, but the result would be less good on a file which was mostly vector data. | 14:01.25 |
| mulover | I understand - a little bit ;-) How did you detect the transparency? | 14:05.41 |
| kens | By decompressing the PDF file (using MuPDF) and reading it ;-) | 14:06.01 |
| Robin_Watts | tor8: I'd be interesting in seeing if 'flattening' paths into a single structure worked, yes. | 14:11.33 |
| | but to do that nicely, I feel we'd need to move to a 'fz_process_path' thing that made callbacks for each tag type. | 14:12.02 |
| | That way the path processors would be isolated from the path structure itself. | 14:12.22 |
| | It's easy to do, but I'd want to check on speeds. | 14:12.42 |
| tor8 | we can flatten it without having a path callback procedure just by moving to an array of union {enum cmd; float coord;} | 14:14.24 |
| | or just a float array and stick enums in as floats | 14:14.45 |
| Robin_Watts | tor8: Yes, but then every path processor needs to know about our 2 different representations, right? | 14:15.18 |
| tor8 | no. the pointer would point to the static array when we create the fz_path object | 14:15.38 |
| | and if it gets reallocated, the pointer points to the new chunk | 14:15.49 |
| Robin_Watts | ah, avoiding having an internal pointer would be high on my list. | 14:16.00 |
| tor8 | fz_path { float *p; int len, cap; float a[10]; } where p initially points to a, and gets reallocated once it doesn't fit | 14:16.48 |
| | s/reallocated/allocated/ | 14:16.59 |
| Robin_Watts | tor8: yeah, I follow the idea. | 14:17.08 |
| tor8 | but we can flatten the cmd/coord struct independently | 14:17.18 |
| | I think that should save a fair bit of malloc overhead as well | 14:17.30 |
| mulover | kens: thank you very much! | 14:17.40 |
| kens | NP | 14:17.51 |
| Robin_Watts | The nice thing about a callback based path processor, is that it would let us have multiple internal implementations of paths. | 14:18.18 |
| | so if opengl needed one thing, and non-opengl needed another, none of the code would care. | 14:18.38 |
| | I think this is an area where there are several options, and we'd need to experiment. | 14:19.10 |
| | we're missing a load of error handling in fz_new_type3_font. | 14:30.26 |
| kens | tor8 I see you've inherited the idiots :-) | 14:46.19 |
| Robin_Watts | kens: Hey, Paul and I do our best! | 14:48.04 |
| kens | Well, I assumed you and Paul were busy with SOT< plenty of idiots to go around I suspect | 14:48.25 |
| Robin_Watts | Oh, right, so we're not the idiots ? :) | 14:49.19 |
| kens | LOL I was referring to the latest bug report | 14:49.34 |
| Robin_Watts | I'm going to ask for a copy of the file. | 14:50.56 |
| kens | Oh God, hey'll probably try and send it to support.... | 14:51.13 |
| tor8 | kens: paying customers or can I ignore them? | 14:52.33 |
| kens | Now there's the question..... | 14:52.47 |
| | These are th people who were 'consultant's for a paying customer | 14:53.00 |
| | We insisted they went through the customer so it was clear because they'd previously been trying for free support. | 14:53.24 |
| | SO who knows, in this case.... | 14:53.32 |
| | My incination is to ignore them unless a real paying cusotmer sayts its for them. | 14:53.52 |
| | 1 million page PDF files are just dumb | 14:54.01 |
| tor8 | kens: I'm tempted to say -- compile it for a 64-bit target and run it on a machine with >16G or RAM | 14:54.10 |
| kens | :-) | 14:54.28 |
| | Their previous complaint was that GS was 'too slow'. But at lwast it worked! | 14:54.44 |
| tor8 | kens: they haven't attached the monster file anywhere have they? | 14:55.28 |
| kens | THankfully no | 14:55.38 |
| tor8 | I suspect if they ran the command with only one -g it would work | 14:55.40 |
| kens | Possibly, I wouldn't know :-) | 14:55.51 |
| tor8 | since they second g in -gg compacts the xref and needs to allocate big tables to do object renumbering | 14:56.19 |
| Robin_Watts | tor8: I wondered that. I then decided I didn't care enough to check the code without them supplying a file. | 14:56.36 |
| kens | you can suggest it and let them try it out | 14:57.04 |
| | They could double the performance with GS if they were capable of modifying the PostScript program, so that it only did one pass over the file. Obviously I *could* do that, but heck its a utility, and such a big file is bonkers | 14:59.41 |
| Robin_Watts | tor8: OK, I have a solution that works nicely for d1 glyphs. | 15:16.38 |
| | For d0 glyphs, acrobat ignores the font bbox. | 15:16.51 |
| | and so if the d0 glyphs are massive, everything slows down a lot. | 15:17.06 |
| | As far as I can tell, they completely ignore the fontbbox. | 15:17.24 |
| | I am tempted to say that we should do the same. | 15:17.32 |
| kens | As I said, I have a sneaky suspicion GS does that too | 15:18.01 |
| Robin_Watts | but that will go against zenikos bug 694952 that you fixed in 5faaa444 | 15:18.08 |
| | Or I can change the d1 behaviour, and leave the d0 behaviour as is. | 15:18.41 |
| | tor8: 1 commit on robin/master then (master~5 :) ). Cluster testing now. | 15:25.53 |
| rayjj | darn. Skipping the pdf14 transparency (bug 695841) is really only possible for 'vanilla' devices (RGB, GRAY or CMYK contone), which is admittedly a lot of devices, but detecting devices ICC profiles with incompatible conversions may be problematic. I'll have to consult with mvrhel on this.rhel | 15:34.37 |
| | at least the workaround is simple :-/ | 15:34.53 |
| mvrhel_laptop | I want to add an option to the tiffsep and psdcmyk devices to have them lock down their colorants and not do the auto-add as colorants are encountered. Two questions. Does anyone have an objection to this and does anyone have a clever name. Its a boolean and I thought perhaps ColorantsFixed or SpotsFixed or AutoSpots | 15:43.06 |
| rayjj | reminder to all. I will be leaving shortly for about 6 hours of road travel (up to the mountains to pick up my son and others, then back down in Friday pm traffic :-( ) | 15:43.46 |
| mvrhel_laptop | rayjj: drive safe | 15:43.59 |
| Robin_Watts | mvrhel_laptop: I'd prefer Colorants to Spots. | 15:44.04 |
| chrisl | mvrhel_laptop: LockSeparations would be by choice | 15:44.06 |
| kens2 | prefers Lock to Fixed | 15:44.28 |
| Robin_Watts | I'd prefer LockColorants to LockSeparations :) | 15:44.28 |
| rayjj | mvrhel: I prefer ColorantsFixed or ColorantsLocked | 15:44.32 |
| | or as Robin said, LockColorants. | 15:44.47 |
| chrisl | Lock... matches the standard LockScreens parameter | 15:44.54 |
| mvrhel_laptop | ok I like LockColorants | 15:45.03 |
| kens2 | Yes, and 'Fixed' has other meanings | 15:45.05 |
| mvrhel_laptop | much better than Fixed and Spots | 15:45.23 |
| chrisl | Yeh, my only complaint about LockColorants is the wrong spelling ;-) | 15:45.40 |
| rayjj | mvrhel: but if this is set automatically when the command line sets colorants prior to the device open, is it something that the user has to specify | 15:45.45 |
| Robin_Watts | chrisl: hehe. | 15:45.48 |
| rayjj | ? | 15:46.03 |
| mvrhel_laptop | rayjj: it is something the user has to specify on the command line | 15:46.33 |
| Robin_Watts | Presumably some devices (like psdcmykog) will set that themselves ? | 15:46.36 |
| rayjj | mvrhel: or did you find that the -c "<< /SeparationOrder [ ] >> setpagedevice is after the open ? | 15:46.51 |
| mvrhel_laptop | Robin_Watts: I don't think the psdcmykog device does the auto add of colorants | 15:47.25 |
| tor8 | Robin_Watts: don't we use the bbox device for some configuration of settings with t3 fonts? | 15:47.39 |
| mvrhel_laptop | rayjj: the order is set before the device is open, but I have no way of knowing if someone actually had specified something or it is the device default values | 15:48.21 |
| Robin_Watts | tor8: fz_bound_t3_glyph (or something like that) runs the display list for each glyph through the bbox device. | 15:48.21 |
| rayjj | mvrhel: if it does have that enabled, it shouldn't. Robin devn devices get to say whether or not they can have colorants be dynamic | 15:48.23 |
| Robin_Watts | and that bbox is then intersected with (a scaled up) FontBBox. | 15:48.41 |
| mvrhel_laptop | right. this is not a devn parameter | 15:48.45 |
| tor8 | Robin_Watts: why don't you use (reuse) the font->bbox_table array? | 15:48.56 |
| mvrhel_laptop | but a parameter for those two devices that do the auto add | 15:49.04 |
| tor8 | we have a per-glyph bbox cache already | 15:49.08 |
| Robin_Watts | tor8: ooh, is there already one of those? | 15:49.11 |
| rayjj | mvrhel: if you get a put_params that includes the related parameters, you could automatically lock, right ? | 15:49.16 |
| tor8 | yeah. we use it for all but fonts with > some number of thousand glyphs | 15:49.32 |
| Robin_Watts | tor8: OK, that's me being dim. | 15:50.09 |
| | Will amend the commit to reuse that. | 15:50.16 |
| | But you're not offended by the new dev->d1rect ? | 15:50.32 |
| mvrhel_laptop | rayjj: I guess I need to talk to you about that. I tried to monitor for SeparationColorNames when I had this -c "<< /SeparationColorNames [ /Cyan /Magenta /Yellow /Black /xGreen /Orange] /SeparationOrder [ /Cyan /Magenta /Yellow /Black /xGreen /Orange]>> setpagedevice" but it did not work properly for me | 15:50.40 |
| rayjj | mvrhel: why isn't it (LockColorants) part of the devn parameters ? Other devices (that don't handle separations) don't need it, do they | 15:50.43 |
| tor8 | no, that seems like a good approach to use the d1 rect if available | 15:50.49 |
| Robin_Watts | cool. | 15:50.56 |
| mvrhel_laptop | I guess we could put in in devn | 15:50.58 |
| | s/in/it/ | 15:51.04 |
| tor8 | uint16_t is not something we generally use though | 15:51.07 |
| Robin_Watts | you'd prefer unsigned short ? | 15:51.24 |
| mvrhel_laptop | rayjj: the only devices that need it are those sep devices that do the auto add | 15:51.35 |
| tor8 | I would | 15:51.37 |
| rayjj | mvrhel: I'm fine with making it manual, if you tried it and it didn't work. Not worth spending more of your (valuable) time on | 15:51.37 |
| mvrhel_laptop | the only two that I know of are psdcmyk, psdrgb and tiffsep | 15:51.57 |
| | oh that is three | 15:52.01 |
| | ;) | 15:52.04 |
| rayjj | mvrhel: OK, right. Only for Sep devices that do auto-add makes sense | 15:52.10 |
| kens2 | Our 3 chief weapons.... | 15:52.13 |
| chrisl | I prefer the parameter to be manually set | 15:52.26 |
| rayjj | weapons of self destruction ;-) | 15:52.37 |
| mvrhel_laptop | ok. thanks for the feedback. I am going to break up my changes into multiple commits to make it easier for review. what I thought was going to be a couple simple fixes has grown a bit | 15:53.43 |
| rayjj | chrisl: fine with me, too. And I guess if it's not managed automatically, a user can turn it on and off between pages | 15:53.59 |
| chrisl | rayjj: my reasoning is that if we make it automatic, sure as heck, *someone* will want it to work the other way! | 15:54.40 |
| mvrhel_laptop | yes ;) | 15:54.47 |
| rayjj | chrisl: agreed | 15:54.47 |
| chrisl | This would all be so much easier if no one actually used the software ;-) | 15:55.21 |
| rayjj | much, but the bonus would be a lot smaller ;-) | 15:55.41 |
| mvrhel_laptop | need to head to my daughters school this morning so I will be out for a bit | 15:56.19 |
| chrisl | rayjj: Oh, I'd still want them to pay for it, just not use it! | 15:56.36 |
| rayjj | and there is somewhat more satisfaction to developing something that people actually use, even if it sometimes means we actually have to make it work | 15:57.01 |
| Robin_Watts | chrisl: Are you responsible for Labours approach to taxation? :) | 15:57.16 |
| rayjj | bbiab... | 15:57.29 |
| chrisl | Robin_Watts: TBH, I haven't noticed much difference with the current crowd | 15:58.41 |
| Robin_Watts | true. Neither of us earn enough to be getting their tax breaks :) | 15:59.02 |
| chrisl | We'll have a chat to Miles next meeting :-) | 15:59.30 |
| Robin_Watts | at least the current crowd don't seem quite so intent on spending everything they can borrow. | 15:59.47 |
| chrisl | Seems to me they're just spending about the same, but in different places | 16:00.43 |
| Robin_Watts | I think we're going to disagree there, but... | 16:02.44 |
| | tor8: Updated commit on robin/master then. | 16:03.03 |
| | actually, skip that, something isn't right. | 16:04.57 |
| rayjj | I'm going to take off now. Anybody need anything, just call. I'll put you on speaker phone in the car. Probably will be just creeping along in traffic. | 16:22.07 |
| Robin_Watts | rayjj: have fun. | 16:23.35 |
| rayjj | Robin_Watts: I'll try. | 16:26.31 |
| Robin_Watts | tor8: 2 commits on robin/master. | 17:03.42 |
| | The first fixes some scan build issues and passes the cluster test with no diffs. | 17:04.06 |
| | The second (the use of the d1 rect) is producing diffs in 3 files (14 tests). | 17:06.17 |
| | The diffs are plausible, but ... odd. See my bmpcmp. | 17:06.30 |
| jogux | fredross-perry: okay. I have your new iOS project open. I get build failures though. source/pdf/js/pdf-jsimp-mu.c:35:30: error: too many arguments to function call, expected 2, have 3 | 18:18.09 |
| | J = js_newstate(alloc, ctx, 0); | 18:18.09 |
| | ~~~~~~~~~~~ ^ | 18:18.10 |
| Robin_Watts | jogux: git submodule update --init | 18:18.28 |
| | Your mujs is out of date, I fear. | 18:18.37 |
| fredross-perry | hmmm. did you just get the iOS folder? The error relates to recent changes tor made in the mupds API. | 18:19.18 |
| jogux | ah, possibly a git clean has fixed it. | 18:19.51 |
| | though that confuses me. | 18:19.57 |
| fredross-perry | hokay | 18:19.59 |
| jogux | fredross-perry: I think http://git.ghostscript.com/?p=user/joseph/mupdf.git;a=blobdiff;f=platform/ios/MuPDFLibTest/MuPDFLibTest/ViewController.m;h=5409737c65b4b0c215bc5120a878b30a709750d1;hp=eefe08ae279e6e3a09159e582dc654dfd1cddded;hb=3cde50b44c6ab1cd97b567b31dc955107c1208c9;hpb=c98b08e15c7cf5df0ac8ebc43c09f4822fd6ae28 answers your main question | 18:22.08 |
| | no idea why that url is so long :-S | 18:22.12 |
| fredross-perry | I see. | 18:23.04 |
| jogux | but, given you're not actually implementing any methods defined in UINavigationControllerDelegate, you don't actually need to set the delegate anywa | 18:23.34 |
| | let me just comment on a few other things (via commits) | 18:24.17 |
| fredross-perry | yes, I think thatâs true. | 18:24.21 |
| jogux | I don't expect you to use the commits, it's just easier to talk like that :-) | 18:24.29 |
| fredross-perry | please do. I am short on time and Iâll probably get back to this Sunday night. One thing I am wondering is if it makes sense to push the navigator inside the library, since the app does not (I think?) care about it. Cheers. | 18:26.45 |
| jogux | the uinavigationcontroller? I'm just pondering that. | 18:27.04 |
| | I think it should probably be outside. | 18:27.16 |
| | I'd generally say you should have a really good reason if you want to make a uiviewcontroller own other uiviewcontrollers | 18:27.32 |
| | fredross-perry: 'initialize' is probably a bad method name choice. There's an 'initialize' on the class that it would easily get confused with. | 18:28.30 |
| | (in the programmers mind, I think the OS would be fine with it :) ) | 18:28.43 |
| | and the viewDidLoad definitely shouldn't be creating the window. I'm not actually quite sure how that works :-) | 18:29.30 |
| fredross-perry | open to suggestions. But mostly I am looking to make this super-easy for a dev to just drop in and go. | 18:29.45 |
| | So, provide a framework and a sample app that uses it. | 18:30.03 |
| jogux | fredross-perry: yep, that's definitely the way to go | 18:30.11 |
| fredross-perry | gotta run now. Iâll check commits later. Thank. | 18:30.21 |
| jogux | hm. actually this is definitely a bit weird. we definiitely shouldn't have stuff on the screen above the uinavigation controller. I think I need to think about this more on Monday (it's coming up for 7pm here) | 18:38.01 |
| | the window should really be (and in fact I believe *is also) being created by the storyboard | 18:38.29 |
| Robin_Watts | Urm... wtf? /FontMatrix [ 0.0399999991 0 0 0 -4 0 0 ] | 18:38.49 |
| jogux | fred: two more commits on http://git.ghostscript.com/?p=user/joseph/mupdf.git;a=summary hopefully commit message explains | 18:39.26 |
| | fred: the <> syntax from my first commit is saying 'my object confirms to the uinavigationcontrollerprotocol' btw. | 18:40.01 |
| Robin_Watts | jeez. /FontMatrix [ 0.0526 0 0 0.-526 0 0 ] | 18:40.30 |
| | and /FontMatrix [ 0.04 0 0 0.-4 0 0 ] | 18:40.44 |
| jogux | fred: I can't quite make sense of the rest currently. I'll have a proper look on Monday. | 18:42.22 |
| | Possibly MuDocumentController is actually already close to what we want as the main UIViewController that other people use. | 18:42.45 |
| Robin_Watts | tor8: So, the fix for the d1 stuff uncovers a slight problem. | 19:51.18 |
| | There are some duff files that have a degenerate fontmatrix in them. | 19:51.45 |
| | This causes the area covered by a glyph to be zero sized. | 19:51.58 |
| | We take the zero sized rect, and turn it into an irect. | 19:52.19 |
| | This irect is non zero sized. | 19:52.28 |
| | and so we get nasty blobs appearing on the render. | 19:52.39 |
| | So... I tried for a fix whereby fz_irect_from_rect always goes from empty rect to empty irect. | 19:53.05 |
| | And that produces some diffs, in particular for clip regions. | 19:53.36 |
| | If you have region [0,0, 100,0] for instance as a cliprect and fill it, acrobat fills a 1 pixel high region. | 19:54.16 |
| | So, there are 5 commits on robin/master | 19:55.55 |
| | Whether we drop the 'fudge' one, or roll it into the previous one is up to you. What do you think? | 19:56.28 |
| fredross-perry | jogux: regarding âPossibly MuDocumentController is actually already close to what we want as the main UIViewController that other people useâ, that could easily be true. I was thinking that the document list might also be useful to devs, so I left that in as well. But I could go either way. | 22:22.08 |
| | jogux: Iâve been thinking that devs might want to embed the entire mupdf functionality in a space thatâs not full-screen. Maybe I am wrong. Maybe a good thing to do next is decide exactly what weâll give devs. Maybe itâs only MuDocumentController. | 22:26.32 |
| mvrhel_laptop | oh crap | 22:27.57 |
| | henrys: I just goofed | 22:28.06 |
| | I meant to push my patch for the psdcmyk and tiffsep devices to my repos on casper | 22:29.05 |
| | and pushed it to orgin | 22:29.11 |
| | I was just starting the cluster push too | 22:29.41 |
| | Robin_Watts: are you around? | 22:30.17 |
| | probably not since its so late. | 22:32.28 |
| | keeping my fingers crossed that nothing is screwed up. it was a minor change | 22:32.52 |
| | well at least it built | 22:34.39 |
| | whew. ok got away with only a warning about one unused variable. | 22:40.25 |
| | which I don't think was new | 22:40.53 |
| | will fix that too though | 22:41.01 |
| | oh that is a bogus warning | 22:42.18 |
| | so all is good | 22:42.22 |
| | darn I am thinking that the named color profile really needs to be part of the device profile structure so that it is accessible during c-list reading | 22:54.13 |
| | sigh | 22:54.31 |
| | I think the easier solution is to just avoid the issue during the clist writing phase | 22:57.28 |
| | for now | 22:57.32 |
| | oh it looks like images with DeviceN source colors even those in index color spaces don't make it through the c-list anyway | 23:00.31 |
| | as high level images | 23:00.45 |
| | that simplifies things for me | 23:00.54 |
| tor8 | Robin_Watts: hm, so empty rects are actually 1-sized due to adobes rendering rules? | 23:14.48 |
| | depending on where they land, I guess, for inclusion in the pixel test | 23:15.02 |
| | Robin_Watts: not convinced of the fudge irects for clips commit details | 23:17.06 |
| | but it's too late for me tonight. the scan build warnings and pdf_show_char changes look good | 23:17.46 |
| | and I'm too tired to look through the d1 values commit now | 23:17.57 |
| rayjj | whew!!! back from the driving. Traffic coming back was actually better today than it was on Monday morning (which was a holiday) | 23:39.47 |
| | mvrhel: are you around for a discussion ??? | 23:40.05 |
| | Forward 1 day (to 2015/02/21)>>> | |
IRC Logs
