| | <<<Back 1 day (to 2015/04/16) | 20150417 |
| rayjj | mvrhel: I don't know if you saw the logs -- I didn't want to dump on you, but the color issues with Altona_Technical_v20_x4.pdf are quite strange. Note I am only reporting rather obvious differences (not trivial) and not ones where Adobe has quite differennt output depending on the Simulation Profile. | 00:45.07 |
| | mvrhel: but can we use the "OutputIntent" in the PDF file. (that just occurred to me and I will look at the GS9_Color_Management doc to see if I can find it). ISTR that was an embedded Output Device ICC profile that Adobe seems to use by default | 00:46.46 |
| | my 10th science fair is now behind me (as an advisor) 3 with my niece and nephews and 7 with my own kids. | 00:48.16 |
| mvrhel | rayjj: yes we can use the output profile | 01:06.37 |
| | I mean the profile in the output intent | 01:06.46 |
| | -dUsePDFX3Profile | 01:08.02 |
| | darn found another gsview bug | 01:08.40 |
| mvrhel_laptop | hmm so when I have an epub document open with gsview, I am getting an access violation deep in the innards of mupdf. If I do a very rapid scroll of the pages and I have one thread that is just rendering a display list while another is creating a display list then bad things happen. The mutex lock is set up for the display list creation but my understanding is that it is not needed for the... | 05:59.46 |
| | ...display list rendering. This problem is not happening with PDF source files | 05:59.47 |
| | I will share the call stacks of the two threads tomorrow with you Robin (for the logs) | 06:00.10 |
| | maybe you will see something obvious | 06:00.25 |
| tor8 | Robin_Watts: about michael's problems with epub, where doc->page_h is 0 | 09:35.31 |
| | sounds like the threading may be accessing count_pages before the actual layout pass has completed | 09:35.59 |
| | calling fz_count_pages from more than one thread is not safe with epub (since that call may trigger a layout) | 09:36.29 |
| Robin_Watts | tor8: Ah. | 10:38.56 |
| tor8 | Robin_Watts: mvrhel migh get around it by manually calling fz_layout_document and waiting for completion before doing anything else | 10:39.39 |
| mvrhel_laptop | Robin_Watts: I just sent you and tor8 some sample call stackes | 15:40.12 |
| | stacks | 15:40.15 |
| | perhaps you will see something obvious | 15:40.25 |
| rayjj | mvrhel_laptop: I avoided putting in another bug on Altona_Technical for page 15. I had thought that the colors were way off when going to the tiffsep device, but it was XnView not using a reasonable mapping from CMYK to the screen (RGB). Looking at our output with Photoshop says we are "spot on" | 15:59.02 |
| mvrhel_laptop | nice | 15:59.40 |
| rayjj | mvrhel_laptop: that means that the method of bug 695925 should be OK | 15:59.43 |
| | I was worried at first that we had another problem | 15:59.54 |
| mvrhel_laptop | we don't need any more of those right now | 16:00.31 |
| Robin_Watts | fredross-perry: Tor reckons the problem might be that fz_count_pages is being called before fz_layout_document. | 17:35.26 |
| | actually, it looks like fz_count_pages does an fz_ensure_layout, so I don't see how that can be a problem. | 17:37.48 |
| | fredross-perry: Can you examine variables at the point at which you get page_h == 0 ? | 17:41.29 |
| | What does doc->did_layout say? | 17:41.52 |
| fredross-perry | give me a sec, I need to pull down tha latest code and rebuild. Hang on⦠| 17:42.04 |
| | Robin_Watts: briliant. calling fz_count_pages solve both problems, I can now open my epub, AND I donât get crashing un subsequent re-searching. | 17:57.36 |
| Robin_Watts | Excellent! | 18:01.48 |
| | In general, don't call the document directly :) | 18:02.05 |
| fredross-perry | got it | 18:04.07 |
| | mac and linux installers for gsview updated to support (properly) epub. | 18:49.45 |
| Robin_Watts | Evening mvrhel | 20:06.18 |
| mvrhel_laptop | hi Robin_Watts | 20:53.56 |
| | Just getting ready to update mupdf | 20:54.02 |
| | had to finish fixing one thing I was in the middle of to get better response with scaling during window resize | 20:54.25 |
| | this will take a few minutes as I have to convert projects over to VS 2013 and add a few minor path and precompile changes | 20:55.42 |
| | grrr git troubles | 20:57.51 |
| | you guys did not take out the platform/windows stuff from mupdf? | 21:01.40 |
| | Robin_Watts: ^^ | 21:01.44 |
| | hmm my update did not work | 21:02.18 |
| | got to go pick up daughter at school | 21:02.30 |
| | bbiaw | 21:02.32 |
| | I will get this tested later today Robin_Watts | 21:02.44 |
| | apparently I mucked up my submodules somehow in gsview | 23:51.14 |
| Robin_Watts | mvrhel_laptop: is it behaving OK now ? | 23:57.24 |
| mvrhel_laptop | no :( | 23:57.32 |
| | maybe I should have you try to do the checkout | 23:57.40 |
| | I am trying to do a clean one | 23:57.44 |
| | and I can't seem to get the submodules to update | 23:58.01 |
| Robin_Watts | Will just try. | 23:58.12 |
| mvrhel_laptop | but I know its late there | 23:58.13 |
| | ok thanks | 23:58.17 |
| | I suspect I messed up something when I created them way back when | 23:58.36 |
| | however, I know that I did do an update about a month ago | 23:58.52 |
| | and that worked fine | 23:58.55 |
| | so I am not sure why it does not work now | 23:59.01 |
| | Forward 1 day (to 2015/04/18)>>> | |
IRC Logs