| | <<<Back 1 day (to 2015/03/11) | 20150312 |
| mvrhel_laptop | rayjj: one bug per page would be fine | 01:20.35 |
| | rayj: I will be curious to see what the issues are. This file is very sensitive the the ICC output profile and comes with a output intent profile. | 01:21.24 |
| | Changing between RGB and CMYK output profiles is going to result in big differences | 01:21.46 |
| | and there may not be much that can be cone about it short of doing a proper CMYK workflow | 01:22.18 |
| | page 4 and page 7 in particular | 01:23.54 |
| | and page 8 | 01:24.17 |
| | and page 9 | 01:24.38 |
| | wow page 11 is dramatic with profile change | 01:25.22 |
| | page 12 | 01:25.40 |
| | page 15 | 01:26.47 |
| | page 16 | 01:27.01 |
| | and page 17 | 01:27.49 |
| | so Acrobat Reader demonstrates that one should expect big changes if you are doing an RGB work flow instead of a CMYK workflow for this file. It is clearly a demonstration to show the use of output intent and proper ICC usage. rayjj, I am curious how your new printer does with this file. gs with -dUsePDFX3Profile out to a CMYK device should give us the best results | 01:30.43 |
| marcosw_ | jogux: the update to the latest xcode appears to work. I do get a warning about the box framework âmissing required architecture arm64â. Presumably I need an update. | 01:55.41 |
| kens | entropix (for the logs) You should probably file a bug report. However there is a recent report (onUbuntu) which nobody can reproduce, I'd suggest you start by downloading and building the source from our site, rather than using any packages. | 08:01.35 |
| sebras | kens: good morning kens! | 08:40.04 |
| kens | Morning sebras | 08:40.10 |
| sebras | kens: all is back to normal and tor5 is nowhere to be seen for an hour or two more. :) | 08:40.22 |
| kens | I'm not surprised, given his journet was even worse than mine | 08:40.37 |
| | journey* | 08:40.41 |
| sebras | kens: how so? | 08:40.43 |
| | kens: he got stuck at heathrow? | 08:40.53 |
| kens | He had to spend the night in Heathrow | 08:40.54 |
| | We both had problems, his were worse | 08:41.02 |
| sebras | kens: helen mentioned that you guys were diverted to newfoundland..? | 08:41.14 |
| kens | Indeed, and then got to spend more than 24 hours sitting there | 08:41.29 |
| | We should have been at HeaTHROW ~09:30 on Monday, we actually arrived 17:30 Tuesday | 08:41.58 |
| | By which time Tor had missed the last flight to Copenhagen and had to spend yet another night in an airport hotel | 08:42.16 |
| sebras | kens: ok, but at least they got you a hotel. | 08:42.47 |
| kens | After 7 hours sitting on the tarmac | 08:43.01 |
| sebras | kens: in the plane? | 08:43.08 |
| kens | Indeed | 08:43.12 |
| sebras | kens: ouch. | 08:43.17 |
| kens | A 9 hour flight, we spent 13 hours in the aircraft | 08:43.32 |
| sebras | kens: I wonder why things like that happens..? | 08:43.57 |
| kens | It was a combination of problems | 08:44.09 |
| sebras | kens: it's one thing if you guys got stuck at the airport, but in the plane?! | 08:44.18 |
| jogux | marcosw : great, thanks, that is one of the things we fixed. | 08:44.43 |
| kens | THe initial mistake was letting a certain passenger on board (should haver been stopped at the gate) and when he caused problems they should have diverted sooner, instead of to a small provincial Canadian airport | 08:44.44 |
| | In fairness, the crew did a good job and did get us a hotel for the night | 08:45.30 |
| sebras | kens: yeah, yey for supposedely drunk passengers. | 08:46.01 |
| kens | Not sure this one was drunk, exactly, may have been something else | 08:46.24 |
| sebras | kens: aha, when I've travelled to taiwan (transfer in bangkok) this was pretty common. hence my deduction. | 08:47.19 |
| kens | But given the airports we flew over ahdn could have diverted to (Chicago, Boston, New York, Ottowa Toronto), we should not have ended up turning back to St John's | 08:47.19 |
| sebras | kens: luckily you guys were just heading home and not out for a trip somewhere. imaginge the grief for those passengers. :-/ | 08:49.32 |
| kens | THere were some business folks who were unhappy. Soem of them ended up taking an Air Canada plane to TOronto and on to Heathrow (paying for the flights of course) arriving only about 24 hours late | 08:50.28 |
| Aqualon | Hi there, we're trying to implement MuJS, is this the right channel for this project? | 09:20.31 |
| kens | Aqualon : yes, but unfortunately a number of the developers are travelling right now | 09:21.00 |
| | Best thing is to ask your questions and someone will respond when they can. | 09:21.18 |
| | THe channel is logged at http://ghostscript.com/irclogs/current.html | 09:21.43 |
| Aqualon | Okay, thank's a lot. | 09:25.32 |
| kens | The main MuJS developer should be online 'soon', but he's recovering from the nightmare journey from hell at the moment | 09:26.14 |
| jogux | aqualon: out of interest (if you can say) what sort of thing are you integrating mujs into? | 09:37.43 |
| Aqualon | Server side script-engine for a native delphi application. We're currently in the evaluating process to check if MuJS fits our needs. | 09:57.40 |
| jogux | interesting, thanks! | 09:59.53 |
| | hi Robin_Watts. flight back ok? | 14:00.37 |
| Robin_Watts | yes thanks. | 14:00.45 |
| | Actually managed to sleep a bit. | 14:00.52 |
| jogux | cool | 14:02.25 |
| henrys_ | Robin_Watts: snow mobile looked like fun, I've never done it. | 15:15.45 |
| | tor5: can you field the customer question to support? I responded and said you and Robin_Watts were traveling but you'd get to it when you returned. | 15:16.57 |
| kens | Tor is not online at the moment | 15:17.21 |
| | Probably recovering.... | 15:17.32 |
| henrys_ | kens: says tor5 left the chat room 5 minute before my message I missed that, but I guess he wasn't really here. | 15:19.32 |
| kens | Yeah he'd been gone 5 minutes according to my log | 15:20.01 |
| | I imagine he's pretty shattered | 15:20.14 |
| henrys_ | kens: I guess newfoundland wasn't a great deal of fun, only activity I hear about going on up there is seal beating and such. | 15:50.27 |
| kens | It was flat and freezing :-( | 15:50.42 |
| | Apparently they did have a ski hill, I can't imagine where.... | 15:50.57 |
| henrys_ | kens: a really fast one probably | 15:51.23 |
| | frozen solid | 15:51.44 |
| kens | Well I guess it woudl be over quickly. | 15:51.46 |
| | The wind chill (and the damp air) was hte problem | 15:52.01 |
| | TO be fair, it migh be a nice place if you haven't just been delayed by 10 hours on a long haul flight | 15:54.22 |
| | Oh Terry Pratchett has died :-( | 16:11.51 |
| Robin_Watts | kens: yeah, just saw that. | 16:33.44 |
| | henrys_: Snow mobiling was awesome. We stood on a peak at 12000ft plus, and had a 360 degree view. | 16:34.14 |
| | We hit about 60mph a couple of times. | 16:34.42 |
| kens | thinks; sounds like ski-ing :-) | 16:34.58 |
| Robin_Watts | We were on basic machines with a guide, not doing anything silly. | 16:35.05 |
| | We came across 3 accidents. 1 was a stuck throttle (girl baled out, and was fine - machine hit tree at 60mph, not fine) | 16:35.54 |
| henrys_ | Robin_Watts: all stayed in the car during the operation ? ;-) | 16:35.57 |
| Robin_Watts | 2 were people being silly asses. | 16:36.03 |
| kens | Silliness is not unusual on cnow mobiles IME | 16:36.23 |
| Robin_Watts | kens: indeed. | 16:36.32 |
| | Chris and I hoolied around a fair amount, but were never in danger of doing any damage. | 16:36.57 |
| | You have to be deliberately doing dumb things pretty much. | 16:37.38 |
| | The girls were slow to start with, but were doing 40mph by the end of the day. | 16:37.54 |
| | I highly recommend it as a way to see scenery that you otherwise wouldn't get to. | 16:38.23 |
| | Ptarmigan Hill, 12146 ft. | 16:42.40 |
| | I forsee a new Meme in the making. Move over Hitler. https://www.youtube.com/watch?v=KHZ8ek-6ccc | 16:43.52 |
| henrys_ | Robin_Watts: ;-) | 16:50.31 |
| | Robin_Watts: if tor pops in and I'm not here would you ask him to respond to the curstomer you've been going back and forth with. Or if you know the answer ... | 16:51.38 |
| Robin_Watts | I don't offhand, so I will prod tor. | 16:52.19 |
| | gotta reboot. | 16:52.47 |
| henrys_ | bbiaw | 17:45.22 |
| mvrhel_laptop | marcosw: you around? | 18:37.26 |
| Robin_Watts | mvrhel_laptop: Hi | 19:37.42 |
| | Did you do a commit to fix the vs solution? | 19:37.57 |
| | There is one on robin/master. (about 7 down from the top) | 19:42.24 |
| | If you nod at it, I'll push it. | 19:42.29 |
| mvrhel_laptop | Robin_Watts: great let me look | 19:46.59 |
| | Robin_Watts: so third party lib also is wrong | 19:48.06 |
| | or differs between win32 and x64 in the same manner | 19:48.21 |
| | as libmupdf did | 19:48.26 |
| Robin_Watts | bugger. give me 5 mins. | 19:48.27 |
| | libthirdparty looks right to me. | 19:56.55 |
| mvrhel_laptop | Robin_Watts: hmm | 19:58.56 |
| | hold on | 19:58.57 |
| | Win32 Output Directory is $(Configuration)\ x64 Output Directory is $(Platform)\$(Configuration)\ | 20:00.05 |
| | why would they not be the same? | 20:00.17 |
| | i.e that is $(Platform)\$(Configuration)\ | 20:00.52 |
| | Robin_Watts: like what you have changed in libmupdf.vcproj | 20:01.59 |
| | Robin_Watts: do you need to change where the libs are found for the other projects? | 20:02.30 |
| Robin_Watts | Every 32 bit one is: $(ConfigurationName) and $(ConfigurationName)\$(ProjectName) | 20:04.27 |
| | Every 64bit one is: $(PlatformName)\$(ConfigurationName) and $(PlatformName)\$(ConfigurationName)\$(ProjectName) | 20:04.50 |
| | I don't want to move the 32bit ones from where they have always been. | 20:05.33 |
| | I've got to run. will check back in later. sorry! | 20:05.51 |
| | feel free to push my commit, or to produce one that you prefer, for me to look at later. | 20:06.12 |
| mvrhel_laptop | ok. I would think that you would have the same, but if thats what you want to do | 20:06.20 |
| | but it just seems odd to have this difference between 32bit and 64bit | 20:12.11 |
| | ok. found the issue with this overprint bug | 20:52.00 |
| | oh. no actually not | 21:02.40 |
| | aha! This file has mixed op and OP settings in the graphic state | 21:24.56 |
| | I bet we are getting screwed up with that | 21:25.14 |
| | this is going to require a bit of work on the interpreter | 21:25.53 |
| zlnk | Hi jogux!, are you there? | 21:44.55 |
| Robin_Watts | zlnk: Jogux has probably gone for the night. | 21:45.19 |
| | It's 21:45 in the UK. | 21:45.26 |
| | Can I help? | 21:45.33 |
| zlnk | A few days ago, I had a problem using Mupdf 1.6 on Android and with landscape view implemented | 21:46.14 |
| | When I scroll to fast, the app crashed | 21:46.47 |
| | so he suggested me, that maybe could be a thread problem | 21:47.09 |
| Robin_Watts | zlnk: Sounds plausible. | 21:47.32 |
| | IIRC from what I saw of the discussion in the logs, you had made modifications. | 21:47.52 |
| zlnk | I want to comment that I could solve it, making a little trick on CancellableAsynctask | 21:47.53 |
| Robin_Watts | You were calling th same C classes from modified java ones, I think? | 21:48.11 |
| zlnk | particulary the gotopage Internal and drawPage | 21:48.47 |
| Robin_Watts | What's the change ? | 21:51.13 |
| zlnk | after the doInBackground process | 21:52.00 |
| | I included the function doCleanUp , that change the value of a counter when the process it's done | 21:52.55 |
| | so, if this value is higher than "X", the draw process is not done, until the previous end | 21:53.59 |
| Robin_Watts | zlnk: Could you open a bug on bugs.ghostscript.com and attach a patch there please? | 21:54.28 |
| zlnk | this case was very specific, when someone try to scroll very fast without stop | 21:54.29 |
| | of course | 21:54.38 |
| Robin_Watts | I'm too jet lagged to be able to visualise it :) | 21:54.42 |
| zlnk | I'll write it with detail | 21:56.35 |
| | Thanks again, and the last time you helped me to create a function for manage many documents of one page, and visualizing as a single one | 21:57.41 |
| | Bye! | 22:02.10 |
| Robin_Watts | mvrhel_laptop: I pushed the msvc change. | 22:12.02 |
| mvrhel_laptop | Robin_Watts: ok | 22:12.08 |
| Robin_Watts | yes, I know that x64 and x86 versions are not symmetric. | 22:12.41 |
| | The clean thing... | 22:12.48 |
| mvrhel_laptop | to me that seems odd, but I will make my project have the same asymmetry in defining where the libs are | 22:13.56 |
| Robin_Watts | The way I envisage it working, is that you'd make an fz_write_options on the stack, init it to 0, set the appropriate options in it,and call pdfclean_clean | 22:14.10 |
| | or something like that. | 22:14.31 |
| mvrhel_laptop | Robin_Watts: this has nothing to do with pdf_clean_clean | 22:14.34 |
| Robin_Watts | No, but the pdfclean_clean thing was the other thing we had left over from our discussions at the staff meeting. | 22:14.58 |
| mvrhel_laptop | this has to do with having a project that depends upon a mupdf lib and making sure that I grab the right one | 22:15.02 |
| Robin_Watts | Right. | 22:15.06 |
| mvrhel_laptop | I will revisit the pdf_clean thing a bit later. I am neck deep is this crazy overprint gs bug | 22:15.46 |
| | that is looking to be an interpreter issue | 22:15.54 |
| Robin_Watts | I'll beat on the pdfclean thing to get it a bit tidier. | 22:15.57 |
| | yeah, that looks horrid. | 22:16.05 |
| mvrhel_laptop | the stroke and fill have different overprint settings | 22:16.20 |
| | and I don't see how we are dealing with that on the interpreter side | 22:16.32 |
| | Robin_Watts: question for you | 22:17.00 |
| | pgs->overprint and pgs->overprint_alt | 22:17.11 |
| | is one supposed to be for stroke and one for fill? | 22:17.18 |
| | I think you did this part | 22:17.29 |
| Robin_Watts | I did the stroke/fill color stuff, yes. | 22:17.44 |
| | overprint and overprint_alt sound plausibly the same thing. | 22:18.11 |
| | I'd want to check git blame to be sure. | 22:18.19 |
| mvrhel_laptop | it is only set in gs_swapcolors_quick | 22:18.59 |
| | so a graphic state in PDF can define a op and an OP | 22:20.24 |
| Robin_Watts | mvrhel_laptop: Right. | 22:20.31 |
| mvrhel_laptop | It looks like setfillstate and set strokestate are doing the correct thing in pdfops. This would end up seting overprint_alt with the "stroke" overprint value | 22:37.09 |
| | question is though, when would overprint_alt be the real overprint | 22:37.28 |
| | i.e. setstrokestate does a swap, Sets the StrokeOverprint which is OP | 22:38.21 |
| | and then we do another swap which will fill overprint_alt | 22:38.55 |
| | taking a break | 22:40.03 |
| | bbiaw | 22:40.04 |
| Robin_Watts | mvrhel_laptop: I'm just off to bed. | 22:44.02 |
| | but the idea is that we swap in the appropriate set of colors/colorspaces/opm's etc before doing the drawing operation. | 22:44.34 |
| mvrhel_laptop | I see | 23:08.32 |
| | ok just verified that it is NOT a mix up between the op and OP settings | 23:20.47 |
| | something else is wrong | 23:21.01 |
| | and I found the graphic state that is getting set that is at least causing the issue. interestingly it is also setting a halftone pattern | 23:25.53 |
| | but that has no effect | 23:28.24 |
| | this file sucks | 23:45.21 |
| | Forward 1 day (to 2015/03/13)>>> | |
IRC Logs