| | <<<Back 1 day (to 2017/08/07) | 20170808 |
| Robin_Watts | night. | 00:01.05 |
| mvrhel_laptop | yes | 00:01.52 |
| | ah some of the shading code is not paying attention to the default color space stuff | 00:57.51 |
| | ok. that fixed one more of the issues on that page | 01:05.09 |
| | dinner time | 01:05.11 |
| | this page still has issues with it. That was the like the fourth item | 02:47.08 |
| | ok next problem tracked down to fz_blend_separable_nonisolated. I will let you get that one updated. Minor commit on my repos Robin_Watts. | 05:50.29 |
| | time for sleep. too late to look at fz_blend_separable_nonisolated | 05:51.33 |
| | and follow it | 05:51.42 |
| rara123 | hey all :) is there a Makefile switch to reduce the built-in fonts to the old skool base14 postscript originals? no cjk, no historic, no bidi, etc.? | 08:03.45 |
| kens | NO_TOFU maybe | 08:08.46 |
| | Or possibly TOFU | 08:08.56 |
| | You really need tor to answer that one and he's not online yet | 08:09.06 |
| rara123 | nods. i looked in noto.c, and there's a bunch of TOFU* variations... | 08:09.34 |
| kens | Yeah I don;t work on MuPDF so I only have a vague grasp | 08:09.52 |
| | If you can stick around for a couple of hours tor should be up and abot and can give you a proper answer | 08:10.21 |
| rara123 | but when i add some of those as -D defines in Makerules... the fonts still get built. | 08:10.28 |
| | okay - i'll be around in a few hours.... I'm building on an 800Mhz machine - grinding through the CJK fonts will take forever :) | 08:11.05 |
| kens | YoThe channel is logged so if you can't make it in a few hours, check back in the logs when you can | 08:11.31 |
| rara123 | thanks for your input - ah great. | 08:11.41 |
| kens | Hmm noto.c claims that simply defining -DTOFU should only build in the base 14 | 08:12.30 |
| | Its possible the entire font set still gets processed by make and only the required fonts are actually linked, not sure about that | 08:13.03 |
| rara123 | yeah - that's what i ws thinking too... but given the slow machine i;m working on... i dont know yet *chuckle* | 08:13.41 |
| kens | Yeah sorry, can't tell from here | 08:13.51 |
| rara123 | all good. it'll figure itself out. | 08:14.01 |
| | once i get it built for my platform, how do i report back to muPDF so my experiences can be folded in to the sources? | 08:14.38 |
| kens | Well, you can chat here, or report a bug | 08:14.57 |
| | bugs can be enhancem,ent requests | 08:15.05 |
| | But I suspect simply chattting here is best | 08:15.16 |
| rara123 | okay - once i get a functioning binary for 1.11 i'l report. i had one for 1.10a, but silly me didn;t document my changes- so now i have to re-live the experience *grin* | 08:15.49 |
| kens | Its probably all changed anyway :-) | 08:16.06 |
| | tor8 see the question from rara123 regarding fonts earlier | 09:05.01 |
| tor8 | rara123: make XCFLAGS="-DTOFU -DTOFU_CJK" | 09:09.39 |
| | rara123: a halfway step is also make XCFLAGS="-DTOFU_SMALL" which includes the basic fonts, a smaller CJK font, and skips all the unusual unicode fonts | 09:10.56 |
| rara123 | thanks :) i'm actually currently struggling to find why isinfinite()isn't being found by the linker at the end of it all. It's strange as -lm is being added to LIBS in the Makefile. | 09:11.44 |
| tor8 | rara123: and yes, the flies still get built but are dropped by the linker | 09:11.56 |
| rara123 | sigh - kens and I figured that would be the case... too bad it takes fmy ancient IRIX box forever to chew through. Oh well, I'm super pleased that mupdf compiles on IRIX - big chapeau to all of you :) | 09:13.44 |
| tor8 | isinf requires a somewhat new C compiler/library | 09:13.45 |
| kens | sebras bug #697501 is a customer bug, please mail the customer and set it to notified (just a reminder) | 09:15.07 |
| rara123 | man isfinite gives me something sensible that should be in math.h and libm, so i guess it's there | 09:15.17 |
| sebras | kens: yes, I'm just about to do that. | 09:15.22 |
| kens | Thanks :-D | 09:15.27 |
| tor8 | rara123: we've had to add a #define isinf(x) (!_finite(x)) for windows | 09:15.43 |
| | in include/mupdf/system.h | 09:15.51 |
| | a similar trick for IRIX may do the job | 09:16.01 |
| sebras | Robin_Watts: tor8: besides me doing an eyeballing of #697501 using the Acrobat Reader installed on my system, do we need to do something else? | 09:16.05 |
| kens | It looked OK to me when I viewed it | 09:16.42 |
| tor8 | sebras: no, I think 697501 is good to close | 09:17.18 |
| | it's one of the files I've been looking at when reviewing the lcms branch | 09:17.35 |
| sebras | Robin_Watts: tor8: when reported the e-mail thread at the end seems to mention other files as well, but I don't know where these are. | 09:18.17 |
| kens | Therte was an email ? Looked to me like the customer opened teh bug directly | 09:19.32 |
| tor8 | kens: there's a support thread "Enhancement bug 690626 support" | 09:20.02 |
| sebras | kens: yes, the seem to have discussed it afterwards. There are two threads. | 09:20.08 |
| kens | Right, so sebras could look at the file tehre from zeniko | 09:20.15 |
| avih | tor8: function f(f) {return typeof f}; f() --> returns "function". https://pastebin.mozilla.org/9029108 ? | 09:20.18 |
| tor8 | from jan/feb | 09:20.20 |
| sebras | tor8: yes, that's the one mentioning the files I don't know where they are. | 09:20.24 |
| kens | If they aren't in the google location mentioned, then ignore it I guess | 09:20.57 |
| avih | (with some non obvious side effects like failing to compile this in strict mode) | 09:21.01 |
| kens | He's pointed to a Sumatra bug tracker ? I wish people wouldn't do that | 09:21.15 |
| sebras | kens: I meant the e-mail from Søren dated april 5th. | 09:21.49 |
| kens | Hmm, let me look at that | 09:22.02 |
| tor8 | avih: I was about to say "duplicate formal parameter 'f'' | 09:22.47 |
| kens | Well, unless ray replied and gave him a location we don't have teh fiels | 09:22.50 |
| avih | tor8: about to say as you expect this error to be the correct behavior? | 09:23.24 |
| kens | sebras for what its worth, the png files he sent are all of that same image | 09:24.32 |
| avih | tor8: minifiers easily output function c(a,b,c,d) { ... }, and in strict mode. as far as i understand (and confirmed in browsers) this should work | 09:24.59 |
| kens | sebras I'd be inclined to ignore that thread, since it was ray going off at a tangent | 09:25.46 |
| sebras | kens: yes, I see the pngs, but I wasn't sure whether the images contains the rendering of several different files (the mupdf pngs seems to indicate this) | 09:26.02 |
| | kens: ok. | 09:26.08 |
| tor8 | no, it's a bug in the shadowing | 09:26.08 |
| | avih: I'll need to review the spec. give me a few days. | 09:27.00 |
| kens | sebras the first of Zeniko's Sumatra bugs I looked at, the files are not attached, just refrenced by URL and the URL is stale | 09:27.19 |
| | Which is why I hate it when people don't attach files | 09:27.49 |
| avih | tor8: shall i ping you early next week if you don't ping me earlier? | 09:27.53 |
| tor8 | avih: but yes, it looks like the patch in the pastebin link you sent would do the job | 09:28.11 |
| avih | tor8: also, copy that patch. that pastebin deletes pastes rather quickly | 09:28.21 |
| tor8 | I just don't have time to dig into it right now | 09:28.22 |
| kens | sebras second sumatra issue is the same, the file has evaporated | 09:28.39 |
| avih | sure, just save the patch for now. | 09:28.44 |
| tor8 | avih: done. thanks. | 09:28.50 |
| kens | sebras in fact that seems to be the case with the third and final one too, so I would personally close 690626 as well, noting that the absence of the test files makes it impossible to proceed with that bug | 09:30.29 |
| | If you really want to you could look at 694445 which is marked as a duplicate fo that bug and actually has attached files | 09:30.58 |
| sebras | kens: I might have the old sumatrafiles... | 09:31.18 |
| kens | Well, up to you | 09:31.29 |
| | The bug does actually have on attached file so you could try that one | 09:31.48 |
| sebras | kens: that one looked good. | 09:32.15 |
| kens | Well then I'd close it, because it really annoys me when people won't attach files. | 09:32.36 |
| sebras | kens: yeah, I wrote a script to automagically download peoples link destinations because of this... | 09:37.49 |
| kens | I prefer just to shout at them :-P | 09:38.03 |
| sebras | kens: do you mind taking a look at page 6 in dslr_compare.pdf in my casper area? | 09:38.48 |
| | kens: my acroread shows it overly saturated, mupdf looks reasonable and so does gs. | 09:39.23 |
| | this is the sumatra 411 bug. | 09:39.32 |
| kens | OK 1 second | 09:39.33 |
| | which of the 12 pages ? | 09:41.00 |
| | oh page 6 | 09:41.27 |
| | So which part of page 6 ? It all looks OK in Acrobat X Pro | 09:41.48 |
| | GS looks slightly less bright, but I think I have Acrobat set to SWOP at teh moment | 09:42.30 |
| sebras | kens: all images on page 6. | 09:42.46 |
| kens | The ones labelled 18mm etc ? | 09:43.08 |
| sebras | kens: the lenses, the flashes and the greenery all look overly saturated (this doesn't happen for any other page) | 09:43.09 |
| | kens: yes, 18mm etc... | 09:43.28 |
| kens | Comparing GS display on Windows to Acrobat side by side they are nearly identical | 09:43.53 |
| sebras | kens: see capture.png on my casper area to illustrate what I mean. | 09:44.15 |
| kens | OK let me get that | 09:44.29 |
| sebras | kens: capture-mupdf.png seems to match gs. | 09:44.51 |
| kens | I'm getting both | 09:45.11 |
| | Oh wow, my Acrobat looks *nothing* like that | 09:45.40 |
| | It matches (within reason) the MuPDF output | 09:46.01 |
| | Your Acroread display is vile | 09:46.16 |
| sebras | kens: yup, but _only_ on this page interestingly. | 09:46.32 |
| kens | Hmm I could try reader | 09:46.45 |
| sebras | kens: oh well, then this file is ok at least. I'll have a look at the others. | 09:46.48 |
| kens | I'd say that file is fine | 09:47.03 |
| | Interestingly selecting e-sRGB produces an insufficiently saturated image | 09:47.42 |
| | sebras my Acrobat Reader DC looks perfectly OK on that page too | 09:49.52 |
| sebras | kens: ok, I have checked sumatrapdf bugs 441, 560, 567, 662, 820, 875 which are all directly or indirectly linked to from 690626. they all look reasonable now. | 10:09.35 |
| kens | Sounds good | 10:09.45 |
| | Glad to hear the colour management is looking in good shape | 10:10.00 |
| sebras | tor8: there are a few patches on sebras/master | 12:05.30 |
| | tor8: they seem to cluster fine. | 12:09.49 |
| tor8 | sebras: bah, where do we print octal characters? | 12:12.35 |
| | I believe the printf flags are supposed to be in a strict order according to spec | 12:13.20 |
| | 'innner' has toooo manny enns | 12:13.48 |
| sebras | tor8: not sure but it has been around since 30bcbe60b93a0e4a697871f69e8367476796f27c which seems to be your first printf implementation. | 12:14.14 |
| tor8 | yeah, I just wonder if we actually use it :) | 12:14.29 |
| | I have no problems with the fix | 12:14.34 |
| sebras | tor8: I tried to grep but came up empty handed. | 12:14.47 |
| | tor8: opengroup: Zero or more flags (in any order), which modify the meaning of the conversion specification. | 12:15.05 |
| | tor8: there are a few things we're still doing wrong wrt to padding though. | 12:15.31 |
| tor8 | why grow with factor 1.5 rather than 2 in detect_flow_directionality? | 12:15.44 |
| sebras | tor8: while fixing this I learned that to write 0x%02x is actually not correct, %#0.2x is probably more accurate, but hey I like %02x. | 12:16.07 |
| | tor8: you usually grow by 1.5 so I opted for that, no real reason. | 12:16.28 |
| tor8 | it just changed, that's all | 12:16.47 |
| sebras | tor8: also I noticed that there are many instances were we are growing arrays like this, maybe we ought to change those to use fz_buffer if possible... | 12:16.57 |
| tor8 | sebras: dealing with padding might be easier if you don't put the sign and prefix in the 'buf' but print them directly | 12:19.40 |
| sebras | tor8: mm, but note that 0 padding and space padding go on different sides of the sign. | 12:22.06 |
| | if printed. | 12:22.12 |
| | I haven't looked into the - (minus) flag which causes left justification. | 12:22.52 |
| | there is a patch on sebras/wip which I used to try to see where printf and fz_format_string() differ. | 12:23.19 |
| | tor8: so... LGTMed or did I need to work one something? | 12:35.25 |
| | on. | 12:35.27 |
| tor8 | sebras: all up to 9044d06d5420c9665ea37a3f0833052d657a1dd6 LGTM | 13:15.03 |
| | if (x && w && w-i <= 2) looks weird | 13:15.41 |
| | and you add the octal 0 in a different place from where you add hex 0x | 13:16.17 |
| | oh, hang on. | 13:17.37 |
| | you only print the sign if z == ' ' or 0 not if z == '0' | 13:17.54 |
| | oh, that's later again | 13:18.03 |
| | very confusing :( | 13:18.06 |
| sebras | tor8: I know, the wording the spec is "The result of a signed conversion shall always begin with a sign ( '+' or '-' ). The conversion shall begin with a sign only when a negative value is converted if this flag is not specified." | 13:19.31 |
| | which is also but there are also "An optional minimum field width. If the converted value has fewer bytes than the field width, it shall be padded with <space> characters by default on the left. The field width takes the form of an <asterisk> ( '*' ), described below, or a decimal integer." | 13:20.37 |
| tor8 | sebras: but that's already handled in fmtint32 (since fmtuint32 will never be called with a negative number) | 13:20.45 |
| sebras | tor8: yes, but I moved the printing of the sign inside fmtuint32 because of the padding. | 13:21.14 |
| | if you do printf("%+ 4d", 42) you should print " +42", but if you do printf("%+04d", 42) you should print "+042", where the z flag is ' ' and '0' respectively | 13:22.14 |
| | tor8: we are also missing that the optional precision actually specified the minimum digits to be printed for d, i, o, u, x... | 13:23.33 |
| | tor8: so there are still issues with our printf if we want it to conform. | 13:23.47 |
| | tor8: though I think we decided to call it fz_format_string() to avoid having to conform. but someone did you %#x so I wanted to make that work and while doing so I tried to separate things out and try to make the thing we _do_ implement conform to a larger extent. | 13:24.33 |
| tor8 | IMO we don't need to conform to every detail of the spec | 13:28.47 |
| | if we did, we could just use the original printf | 13:28.58 |
| sebras | tor8: unless printf() does something locale specific... | 13:29.11 |
| | tor8: or something differs per platform. | 13:29.19 |
| tor8 | we have our own because we want to print non-standard things like matrices and rects and point | 13:29.22 |
| | and to avoid stupid locale dependent formatting | 13:29.36 |
| sebras | tor8: I know. | 13:29.42 |
| tor8 | sebras: have you got a test file that exercises all the options? | 13:30.00 |
| sebras | tor8: there is an ugly patch on sebras/wip that tried to exercise them all. | 13:30.20 |
| | tor8: it actually only prints it out if vsnprintf() and fz_format_string() differ. | 13:30.46 |
| | tor8: if you want them all look for the fz_strcasecmp() and comment that line out. | 13:31.03 |
| tor8 | sebras: there's a patch on tor/printf, untested but I need to go to the store now | 13:31.11 |
| | I'll be back in a bit | 13:31.14 |
| sebras | tor8: field separator is colon, field order is format, then printf, then printf result, then fitz, then fitz result. your code results e.g. in %3d:printf: 9:fitz:9 : | 13:37.37 |
| | tor8: or %+3d:printf: +9:fitz:+9 : | 13:37.55 |
| | in the first one it is obvious that the padding is at the wrong position. | 13:38.45 |
| | in the second one printf takes the sign into consideration when evaluating the field width | 13:39.04 |
| | % 03d:printf: 09:fitz:9 : when you add both the space and 0 padding I'm not sure what the spec really states, but it sure looks odd. | 13:39.40 |
| | %+03d:printf:+09:fitz:+009: though it seems like the initial space might be there as a placeholder for the sign. | 13:40.40 |
| tor8 | sebras: I still don't understand why you print the octal prefix in a different place from the hex prefix in %# | 14:35.49 |
| | sebras: IIRC, what we want to print is: pad(' ') + sign + prefix + pad('0') + number | 14:37.13 |
| sebras | tor8: I'm not sure I know why I do that either. :) | 14:40.04 |
| | tor8: note that the precision is what determines the minimum number of printed digits, i.e. if the precision is 3 and the value is 42 you first print 42 and then add 042. | 14:40.49 |
| | tor8: and that's what the # does to octal, it extends the precision until the most significant digit is a zero. | 14:41.14 |
| | printed digit. | 14:41.17 |
| tor8 | sebras: slightly rearranged logic in tor/printf2 | 14:44.28 |
| | to where I can understand it a bit | 14:44.41 |
| | it looks to me like "% #5x" could do the wrong thing | 14:46.00 |
| sebras | tor8: is it the case that the precision determines how many zeroes preceed the number and the field width determines how many spaces are located to the left or the right of the number (including sign and prefix)..? | 14:47.46 |
| tor8 | okay, I am very confused by the order and logic here | 14:48.38 |
| sebras | tor8: me too. | 14:48.53 |
| | tor8: "_% #5x", 9 --> "_ 0x9_" on my system. | 14:49.28 |
| | so essentially the field width determines the space padding to the left of "0x9" | 14:49.54 |
| | now if you write "_% #5.2x_", 9 --> "_ 0x09_" which seems to indicate to me that yes the precision determines the number of digits in the number while the field width determines the space padding. | 14:50.52 |
| | but "_%0#5.2x_", 9 --> "_ 0x09_" which is strange since the spec says that the precision '2' should be ignored when the '0' flag is present. | 14:53.08 |
| | "_%0#5x_", 9 --> "_0x009_" works as I expect it too. | 14:53.35 |
| | does this mean that glibc does not conform to POSIX printf?! | 14:53.48 |
| tor8 | fz_write_printf(ctx, fz_stdout(ctx), "'%#+ 6o'\n", 33); | 14:53.59 |
| | fz_write_printf(ctx, fz_stdout(ctx), "'%#+ 6x'\n", 33); | 14:53.59 |
| | that one prints both with the right width | 14:54.07 |
| | change it to +06o +06x and they don't | 14:54.18 |
| sebras | my systems print print both with a 6 char width. | 14:55.16 |
| tor8 | '000041' | 14:56.08 |
| | '0x000021' | 14:56.08 |
| | not the same widths as when it had spaces | 14:56.17 |
| sebras | is that because of the 0x prefix? | 14:57.00 |
| | what if you do fz_write_printf(ctx, fz_stdout(ctx), "'%#+ 8x'\n", 33); | 14:57.11 |
| | does it still only differ by two? | 14:57.19 |
| | tor8: it seems to me that the prefix "0x" is included in the number length which is then padded up to the field width. | 14:58.20 |
| kens | tor8 I'll be interested to see your comments regarding the PDF 2.0 spec, I'm especially interested in anything important you notice that I've missed..... | 15:16.22 |
| mvrhel_laptop | Robin_Watts: are you in a SO meeting now? | 15:25.17 |
| tor8 | so with %o the prefix is included in the width, but with %x it's not? | 15:27.56 |
| Robin_Watts | mvrhel_laptop: Theoretically, I guess. | 15:32.52 |
| sebras | tor8: yes, I think you are right. | 15:33.08 |
| | tor8: this is likely because the x in 0x is not a hexdigit and so it cannot be part of the precision, but it counts against the field widht, while the 0 prefix in octal _is_ a digit in octal and so counts against both..? | 15:33.55 |
| | oh, and since the x is not a hexdigit the preceeding 0 is handled similarly. | 15:34.16 |
| Robin_Watts | mvrhel_laptop: But I can't focus on that now, cos I'm buried in a blending problem. | 15:34.18 |
| | So I looked at your commit last night. | 15:34.28 |
| | And I have a tweaked version. | 15:34.35 |
| tor8 | sebras: ugh. what a mess. | 15:34.47 |
| Robin_Watts | We can't change the colorspace within a shade. | 15:34.48 |
| tor8 | I'd rather just not support # in our printf :) | 15:35.03 |
| Robin_Watts | we can't just assign to shade->colorspace (even allowing for reference counting) cos we feel like it. | 15:35.17 |
| sebras | tor8: or remove octal _and_ support #..? | 15:35.27 |
| Robin_Watts | so I tweaked your commit a bit so we pass an explicit colorspace around. | 15:35.45 |
| sebras | tor8: oh.. # is much less common than I anticipated, only in pdf-xref.c at one location. | 15:36.05 |
| mvrhel_laptop | Robin_Watts: I was worried about that | 15:36.09 |
| | I figured it was wrong | 15:36.14 |
| | but I figured you would have a solution | 15:36.24 |
| Robin_Watts | let me just do a quick spot of rebasing. | 15:36.40 |
| tor8 | sebras: I'd change the pdf-xref.c instance of it and nuke both # and %o | 15:36.47 |
| mvrhel_laptop | I suspected with a shared object like a shade it would cause problems to do that | 15:36.56 |
| tor8 | sebras: btw, we can probably get away with only having fmtuint64 | 15:37.04 |
| | no need to duplicate the function for both integer widths, given that it's exactly the same code | 15:37.19 |
| sebras | tor8: wouldn't that be slower on 32-bit platform? do we care? | 15:37.53 |
| Robin_Watts | mvrhel_laptop: OK, so I've pushed a new robin/spots with the fixed version on. | 15:37.55 |
| mvrhel_laptop | cool | 15:38.07 |
| tor8 | sebras: it could be slower on arm, and printing is slow enough already that maybe we should care | 15:38.09 |
| mvrhel_laptop | Robin_Watts: so were there planned changes to fz_blend_separable_nonisolated? | 15:38.26 |
| Robin_Watts | But I had some group problems on page 7 of the altona file, that confused me a bit. | 15:38.48 |
| mvrhel_laptop | There is a bug in there but I don't want to look for it if you need to make changes there | 15:38.49 |
| Robin_Watts | mvrhel_laptop: You claimed last night there was a problem there. | 15:39.02 |
| | I looked at the code and couldn't immediately see it. | 15:39.09 |
| | but you didn't give me an example that showed the problem, so I've not gone anywhere with it. | 15:39.22 |
| mvrhel_laptop | hmm ok. let me give you this file | 15:39.42 |
| Robin_Watts | At the moment, I've got a problem derived from page 7 that I'm looking at. | 15:40.09 |
| | In fz_blend_non_separable, that looks wrong. | 15:40.30 |
| mvrhel_laptop | Robin_Watts: oh well you work on that and I can find where this is going wrong | 15:42.30 |
| | I just did not want to step on your toes in the same spot | 15:42.45 |
| Robin_Watts | I understand. | 15:42.50 |
| | I have made no changes in there past the point that was on your branch last night. | 15:44.10 |
| | mvrhel_laptop: Can I borrow you for a sanity check please? | 15:48.36 |
| mvrhel_laptop | sure. Robin_Watts I sent you the file, but no need to look at yet | 15:48.57 |
| Robin_Watts | In my casper dir is a file e1.pdf | 15:49.04 |
| mvrhel_laptop | I will see if I can figure out what the issue was | 15:49.04 |
| | ok let me grab it | 15:49.15 |
| Robin_Watts | hold on, let me clean it. | 15:49.36 |
| | ok, e2.pdf in the same place. | 15:51.17 |
| | Acrobat is showing that as a magenta rectangle on a grey rectangle. | 15:51.50 |
| | mupdf is showing it as a dark grey rectangle on a light grey rectangle. | 15:52.04 |
| mvrhel_laptop | oh | 15:52.11 |
| | let me run with mupdf | 15:52.20 |
| Robin_Watts | ok, so it's my changes that have broken it. Bah. | 15:52.56 |
| mvrhel_laptop | Robin_Watts: did you want me to help on this? | 15:53.37 |
| | or do you have it | 15:53.45 |
| Robin_Watts | mvrhel_laptop: No, I think I should retry from here. | 15:53.53 |
| | Thanks. | 15:53.55 |
| mvrhel_laptop | ok np | 15:54.01 |
| | Robin_Watts: so I have a dr. appt that I need to leave for in about 25 minutes or so | 15:54.26 |
| | if you need me before then | 15:54.32 |
| Robin_Watts | Check back in with me when you get back. | 15:54.39 |
| mvrhel_laptop | annual heart check. this guy is so hard to get in to see. Had to make the appt. 9 months in advance. dont want to miss it | 15:55.08 |
| Robin_Watts | Of course not. And he'll be running late, if you're on time, and early if not. | 15:55.31 |
| mvrhel_laptop | yes :) | 15:55.38 |
| Robin_Watts | mvrhel_laptop: OK, so it's possible/probable that the problems I've been seeing were due to the WIP stuff I did. | 15:57.41 |
| | I'm going to back that out, and do it again in less of a rush. | 15:57.52 |
| | I may start with the problematic file you sent. | 15:57.59 |
| mvrhel_laptop | oh ok | 16:02.24 |
| | that would be fine | 16:02.29 |
| | back | 19:56.18 |
| Robin_Watts | I just sent you an email. | 19:56.50 |
| | I've got to stop for the night, sorry. | 19:56.58 |
| mvrhel_laptop | Robin_Watts: no problem | 19:57.08 |
| | are your changes pushed? | 19:57.12 |
| Robin_Watts | basically, I'm confused, but I suspect something is wrong with the shape values. | 19:57.15 |
| | yes. | 19:57.31 |
| mvrhel_laptop | Robin_Watts: do you want me to push on with it? | 19:58.53 |
| | and let you know what I find? | 19:58.59 |
| Robin_Watts | yes. | 20:01.49 |
| | I think it will benefit from another pair of eyes. See what I said in the email. | 20:02.04 |
| mvrhel_laptop | will do | 20:05.05 |
| | thanks Robin_Watts | 20:05.08 |
| | oh I might see the problem with this | 22:10.01 |
| Robin_Watts | mvrhel_laptop: ooh, good. | 23:04.32 |
| | mvrhel_laptop: Care to share? | 23:31.14 |
| mvrhel_laptop | Robin_Watts: yes. hold on on phone with ray | 23:31.35 |
| Robin_Watts | sorry. | 23:31.39 |
| mvrhel_laptop | np | 23:47.24 |
| | almost done... | 23:47.32 |
| | you still there Robin_Watts ? | 23:51.18 |
| | sorry I am going to have to switch over to halftone madness tomorrow for kip | 23:51.43 |
| | So this is what has me confused | 23:51.52 |
| Robin_Watts | sure. | 23:53.35 |
| mvrhel_laptop | when the path with cmyk = [0 0 0 .3] is drawn with alpha of 0.33, the results is CMYK pre-multiplied with 0 0 0 .11 and an alpha channel of .33 | 23:53.51 |
| | but the shape has a value that is also hit by the alpha value | 23:54.06 |
| | that seems odd to me | 23:54.12 |
| Robin_Watts | That does seem odd. | 23:55.02 |
| | oh, wait... | 23:55.19 |
| mvrhel_laptop | I tried something dumb which is to not apply the alpha to shape but that had the opposite effect ;) | 23:55.27 |
| Robin_Watts | yeah, the line I pointed to in my email is where it applied the alpha to the shape. | 23:56.10 |
| mvrhel_laptop | oh | 23:56.22 |
| Robin_Watts | I tried making it NOT apply the alpha, and everything got darker. | 23:56.22 |
| mvrhel_laptop | yes me too | 23:56.26 |
| | ha. i forgot to read your email... | 23:56.34 |
| Robin_Watts | The nasty discontinuity between bp =0 and bp != 0 pixels went away, but it all got darker. | 23:57.02 |
| mvrhel_laptop | and found the same thing. I got distracted and just started working | 23:57.06 |
| | yes | 23:57.09 |
| | Is there any odd chance that the polarity of the alpha in the shape channel is wrong. wild guess.... | 23:57.43 |
| Robin_Watts | So tomorrow, I'm going to try to make a really simple file with some tiny images with known values in, and I'll feed that through mupdf and gs and look at the debug dumps to see where we differ. | 23:58.24 |
| | I can't see how. | 23:58.30 |
| | Forward 1 day (to 2017/08/09)>>> | |
Log of #mupdf at irc.freenode.net.