| | <<<Back 1 day (to 2015/08/06) | 20150807 |
| rayjj | anyone that cares to comment, please see my bug696132 branch: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=d8bb22004f66be5fd114c2d93d10cb60cf4701f7 | 05:23.35 |
| | ok, now back to either (1) fast HT (threshold) matching non-fast, or (2) overprint simulation using pdf14 compositor | 05:29.54 |
| | I'm inclined to go back to (1) since it's close enough (I think) to commit and the few remaining differences that are really minor can be done later -- but I have to dive back in to confirm | 05:31.15 |
| | iirc, matching the inverted transform function was problematic | 05:32.09 |
| | yep. Inverted transfer functions are what is still broken in my otherwise reasonably close code | 06:04.27 |
| | time for some brain recharging (sleep) | 06:04.50 |
| tor8 | paulgardiner: Have you got a minute? | 14:20.21 |
| | The workaround for where crap pdf files have the xref subsection headers (object number and entry count) on the same line as the 'xref' token doesn't seem to work anymore | 14:21.35 |
| | Bug #696129 gets thrown off in the pdf_xref_size_from_old_trailer function. | 14:22.03 |
| sebras | tor8: when you cluster push, do you test using all the PDFs from previous bugs as well? | 14:36.53 |
| sebras | doesn't remember. | 14:36.57 |
| tor8 | sebras: only if they've been added to the cluster test suite | 14:41.49 |
| sebras | tor8: agh! I'm going nuts over these premultiplied jpeg xr images. | 14:48.32 |
| | tor8: seems like 32bppPBGRA _isn't_ premultiplied after all... | 14:48.52 |
| | i.e. if I _do_ call fz_premultiply() then the picture looks alright if I hardcode the alpha values, however if I don't call fz_premultiply() I end up with the same kind over overflowy patchy behaviour that I had when we discovered that fz_pixmap expects premultiplied component values. | 14:55.21 |
| | I'm so confused. | 14:55.27 |
| tor8 | sebras: it should be easy to test whether any of the R,G,B components are > A | 14:55.55 |
| | are you sure the 'P' stands for premultiplied and not just padding? | 14:58.31 |
| | ah, never mind. https://msdn.microsoft.com/en-us/library/windows/desktop/ee719797%28v=vs.85%29.aspx | 14:59.16 |
| | "To retrieve the true color values of each channel in a PRGBA/PBGRA pixel format, the alpha-channel multiplication must be reversed by dividing color values by the alpha value." | 14:59.37 |
| sebras | tor8: exactly. | 15:02.46 |
| | tor8: but when I _don't_ do the premultiplication I get weird results. and if I do it then it looks sane. | 15:03.10 |
| | oh! maybe the library does some magic! :-P | 15:03.22 |
| tor8 | never hurts to check | 15:03.30 |
| sebras | tor8: can't find any evidence for that though. seems like they just read the flag and use it to control the number of "extra vlues" in tiff e.g. | 15:09.12 |
| tor8 | yeah, I can't find anything either | 15:12.26 |
| | what does the PREMULTIPLIED_ALPHA_FLAG in the image header say? | 15:16.50 |
| sebras | it indicates a separate alpha plane. | 15:20.37 |
| | no wait. you asked for the other flag. :-P | 15:21.56 |
| | tor8: I can confirm that jxr_get_ALPHACHANNEL_FLAG(image) returns 0 for this particular picture. | 15:23.39 |
| | tor8: when I'm decoding the image I see jxr_get_ALPHACHANNEL_FLAG() == false, jxr_get_CONTAINER_ALPHA_FLAG() == true and jxr_is_DECODING_SEPARATE_ALPHA() == false, but later when decoding the alpha plane they are false, true, true. | 15:32.38 |
| | which makes sense. | 15:32.49 |
| henrys | rayjj: you can just feed your comment to Joseph on skype or irc, that's what I'm doing so we don't have huge sprawling discussions on the UI. | 16:07.46 |
| rayjj | henrys: that's a good idea. I'll probably not have much to say, but I find all of the hoopla about BIU entertaining | 16:08.56 |
| henrys | fwiw it's been pretty interesting to me. I've learned a lot about UI issues which I never would have considered from (for example) reading Jamie's initial report posted to sos. It's interesting stuff that I never thought about carefully. | 16:12.07 |
| rayjj | henrys: me neither. There were always people at CalComp who's job it was to worry about all that (not that I thought the result was that great -- I just had no say in it) | 16:24.43 |
| | I did find it interesting that Office tried to use the first letter of translations for Bold, Italic and Underline for some languages, but used the smaller A and larger A for font size in all translations | 16:26.24 |
| henrys | chrisl: urw said a release should be back soon. still going back and forth about the GPL issue | 16:46.02 |
| chrisl | henrys: okay, thanks | 16:46.16 |
| henrys | I'm using a different irc client holler at me if I'm going on and off all the time. | 17:33.32 |
| rayjj | henrys: just curious -- which IRC client are you using (I mostly use Chatzilla plugin on Firefox) | 22:48.49 |
| | I think kens uses miranda | 22:49.15 |
| henrys | haha erc - emacs | 22:53.09 |
| | don't think you'd like that. | 22:53.34 |
| rayjj | henrys: BTW, Ii haven't been on chatzilla the whole time, but I am not seeing 'left/joined" messages (coelebs just had a flurry in the past 20 min) | 23:37.03 |
| | my youngest son might like emacs -- he plays piano and is used to <ctrl-shift-alt>key chords ;-) | 23:38.32 |
| sebras | rayjj: can't you configure chatzilla to ignore those? | 23:39.35 |
| coelebs | sorry about in and out my shell seem to experience some connectivity problems | 23:39.42 |
| rayjj | sebras: yeah, but they aren't so many that it's a problem. When we have our Tuesday AM (PM for .eu) chats it's nice to know when someone drops off, so I can ask if they saw the comment (irclogs lag is too long to rely on) | 23:41.33 |
| | coelebs: np. I just mentioned it because henrys asked to be hollered at if he was going on and off, and I wanted to reassure him that his client was (so far) np | 23:43.08 |
| sebras | rayjj: ah, makes sense. | 23:43.10 |
| | Forward 1 day (to 2015/08/08)>>> | |
IRC Logs