| | <<<Back 1 day (to 2011/11/23) | 2011/11/24 |
| Bogus8 | does anyone know of a device that will work with an Epson Workforce 1100 on Windows 7? | 03:42.43 |
| | I'm getting something more akin to half-tone LINES (vertical) when I try to print a PS file out of Ghostview. | 03:43.23 |
| | Prints to PDF with halftones (thought a bit kooky) but when I select Windows GDI it gives me the vertical lines instead of dots. | 03:44.07 |
| Gigs | epson is still in business? | 06:15.31 |
| mvrhel | henrys: I ran my first file with the unmanaged color approach | 06:48.14 |
| | the solution that I took worked pretty well with the existing color achitecture. | 06:48.34 |
| | basically, our dumb cmm returns a link that contains the color remap procs for the device along with any UCR/BG information that may be needed | 06:49.39 |
| | the link structure has some procs that are swapped out so that we end up going through the device remap methods instead of the lcms methods | 06:50.43 |
| | need to do a bit more work to handle all the buffer methods that we currently do with the real CMM which is planar/chunky in and planar/chunky out. | 06:51.40 |
| | but it seems to be working. | 06:52.00 |
| | have a good thanksgiving. | 06:52.10 |
| henrys | morning kens | 07:51.21 |
| kens | Hi henrys, why aren't you in bed ? | 07:58.23 |
| | Its Thanksgiving already with you isn't it ? | 07:58.38 |
| | Thanks for looking at that PCL bug henrys, I was going to look at that one today, you've saved me a heap of trouble there. | 07:59.48 |
| henrys | oh glad I could help | 08:05.51 |
| kens | Well I'm sure you spotted the ROPs much faster than I would have | 08:06.22 |
| henrys | yes I should get to bed. Ya'll will probably be on your own tomorrow. Good luck | 08:06.37 |
| kens | Goodnight ! | 08:06.45 |
| henrys | We have the go ahead now to push back on your favorite customer. | 08:06.58 |
| kens | I have so many to choose from.... | 08:07.18 |
| henrys | the one we discussed at the meeting. If it seems something can be put off as an enhancement go ahead. | 08:07.57 |
| kens | aha, right thanks. | 08:08.04 |
| henrys | off to bed good night | 08:09.37 |
| kens | Night henrys, have a good Thanksgiving | 08:09.54 |
| Robin_Watts | tor8: Just opened an xps rendering bug. I think it's come to you by default. | 14:53.06 |
| | It's not customer driven or anything, just something I noticed in passing, | 14:53.19 |
| tor8 | Robin_Watts: right | 14:55.05 |
| | radial ppacity? | 14:55.42 |
| Robin_Watts | radial shading, with opacity. | 14:56.15 |
| chrisl | Robin_Watts: after discussing the memory alignment stuff on Tuesday, I did a bit of digging, and x86(_64) has optional alignment enforcing, too - but it's no use to us for "large scale" testing :-( | 14:58.20 |
| Robin_Watts | yeah, compilers are known to make use of unaligned transfers in funky ways on x86. | 14:59.10 |
| chrisl | Yep, it's rather annoying, given that another memory alignment issue was reported on Tuesday :-( | 15:00.11 |
| | tor8: I've taken the leap - all but one of my Linux boxes are running xfce, the last one will switch the next time it needs a reboot. | 15:01.57 |
| tor8 | chrisl: is it an improvement over gnome or what you were running before? | 15:13.41 |
| Robin_Watts | tor8: bug 692429... | 15:13.51 |
| | It looks to me like we are using sorted dictionaries... | 15:14.03 |
| tor8 | yeah, sebras made a patch for that, I guess we forgot to close the bug | 15:14.40 |
| chrisl | tor8: Yes, *much* snappier, and I prefer the look too. I was using Ubuntu's normal desktop environment, but with Metacity instead of compiz, and all the "bells and whistles" switched off. | 15:16.11 |
| Robin_Watts | tor8: The only problem I can see with the current implementation is that during dictionary building we do a LOT of memmoves. | 15:16.43 |
| tor8 | Robin_Watts: yeah, if it's a large unsorted dictionary that can be the case | 15:17.36 |
| | if it's pre-sorted that shouldn't be the case | 15:17.36 |
| Robin_Watts | yeah. | 15:17.36 |
| | according to git blame, sorted has been there since 2004! | 15:31.21 |
| | oh, right, I see. | 15:32.42 |
| tor8 | we had post-creation sorting, but that wasn't always used and it doesn't help the creation phase | 15:34.06 |
| | another way to speed it up would be to allow duplicate entries | 15:34.23 |
| | not checking for existence before tacking on new entries could speed it up a lot | 15:34.46 |
| Robin_Watts | but then you'd need to check for duplicates on the next use. | 15:35.37 |
| | If you're inserting into a sorted list, then the checking for duplicates comes for free. | 15:35.58 |
| sebras | tor8: am I even allowed to close bugs? | 15:55.08 |
| Robin_Watts | sebras: No, but we should have done. | 15:55.36 |
| sebras | Robin_Watts: good to know, that I haven't erred at least. | 15:56.57 |
| Robin_Watts | tor8: One of Zenikos bugs has an (incomplete) patch to add Optional Content support. I'm tempted to extend that to something more capable. | 17:06.41 |
| tor8 | Robin_Watts: yeah, go ahead. | 17:06.58 |
| | I think I want to finish off the text branch, then merge the context branch and start on the android port after that. | 17:07.43 |
| Robin_Watts | ok. | 17:07.54 |
| | The context port is (mostly) merged. | 17:08.06 |
| | I've pushed a patch from zeniko (bug 692506) to my repo. | 17:08.26 |
| tor8 | Robin_Watts: pushed | 17:11.28 |
| Robin_Watts | Thanks. | 17:11.41 |
| kens | Night everyone | 17:14.59 |
| tor8 | night kens | 17:15.05 |
| malc_ | tor8: hi, around? | 18:41.17 |
| Robin_Watts | malc_: Can I help? | 18:58.03 |
| malc_ | Robin_Watts: well, few things | 18:58.46 |
| | Robin_Watts: a) yes, the bug you just closed is fixed indeed | 18:59.01 |
| Robin_Watts | (In general on here, best to ask questions, rather than to ask to ask :) ) | 18:59.12 |
| malc_ | b) there are some significant regressions in current mupdf HEAD | 18:59.14 |
| Robin_Watts | Which one ? | 18:59.17 |
| malc_ | large dicts one | 18:59.24 |
| Robin_Watts | ok. | 18:59.28 |
| | b) tell me about the regressions... | 18:59.42 |
| malc_ | c) fz_outline is not good enough as a replacement for pdf_outline | 18:59.44 |
| | pagenumber alone is not sufficient (or let's put it this way, pdf_outline provided much more fine positioning and this is now lost with fz_outline) | 19:00.15 |
| | Robin_Watts: http://gittup.org/tup/build_system_rules_and_algorithms.pdf page number 1, and other pages too | 19:01.04 |
| | half of the text just isn't there | 19:01.11 |
| Robin_Watts | OK, I can't really comment on c). Tor made the change. | 19:01.19 |
| | Can you open bugs for b and c etc please? | 19:01.31 |
| malc_ | yes he did, for XPS's sake apparently | 19:01.36 |
| Robin_Watts | I'll look at b) as soon as I finish with what I'm doing now. | 19:01.54 |
| malc_ | well, i thought maybe i'm misunderstanding something and wanted to ask tor to clarify.. he wont be around anytime soon? | 19:02.40 |
| Robin_Watts | malc_: I'm sure he will be around later, yes. | 19:03.31 |
| | but I can't say when. | 19:03.43 |
| malc_ | as for opening bug for b) can you perhaps confirm that page 1 is misrendered (weird machine here) | 19:03.48 |
| Robin_Watts | opening bugs with all the details on is certainly not wasted time. | 19:03.59 |
| | Sure. | 19:04.02 |
| | yes, I can confirm a problem. | 19:05.24 |
| malc_ | filling | 19:05.28 |
| Robin_Watts | I bet it's my clipping change. | 19:05.30 |
| malc_ | fwiw f788271e01f5c0ba97bc4ad561ae546ac11017c1 is okay | 19:05.46 |
| Robin_Watts | My fear is that 54d7093may have broken it, but that's just a wild guess really. | 19:07.52 |
| malc_ | App store release will have to wait a bit methinks... | 19:10.44 |
| Robin_Watts | Ah, not 54d7093 | 19:31.56 |
| tor8 | malc_: the change to fz_outline is not completely finished. A patch to add a destination rectangle would not be rejected. I just want to have the same API for the outline tree and links between pdf and xps. | 19:32.13 |
| | Robin_Watts: if there is a big regression with the clipping change, now would be the time to fix it. the app store review is still in the queue | 19:33.51 |
| Robin_Watts | tor8: Am bisecting now. | 19:34.09 |
| | but it's not the clipping change. | 19:34.38 |
| malc_ | tor8: one has to know both(pdf xps) to make the change.. i don't feel qualified | 19:34.53 |
| tor8 | my sane tests are in a shamble, my computer died over the weekend and my new laptop isn't set up properly after the lion fiasco | 19:35.07 |
| malc_ | tor8: what went wrong with lion? | 19:35.41 |
| tor8 | it sucked, royally. bugs everywhere, broken compiler tool chain etc | 19:36.07 |
| | and the UI changes ... ugh. | 19:36.37 |
| malc_ | what compiler toolchain has to do with lion i wonder :) | 19:36.38 |
| tor8 | well, ar and ld have regressed to the same state they were back in 10.2 ... you *must* run ranlib on a libfoo.a archive, and re-run ranlib if you copy or move it. | 19:37.57 |
| | and incremental ar update to add object files breaks the archive too. | 19:38.25 |
| malc_ | just use linux or bsd | 19:39.46 |
| tor8 | I wish I could... but then there's this pesky issue of having to do iOS development getting in the way | 19:40.25 |
| malc_ | wallen gardens are cool.. or so i've heard | 19:42.14 |
| tor8 | they're the hip thing to do these days, or so all the cool kids say | 19:42.44 |
| malc_ | tor8: btw. i've needed to watch something which required flash so used the hip and cool mac i have in the house.. tried their preview app on some pdfs and couldn't help but notice that it somehow caches the pdf pages (an operation which could require hopgobs of memory).. any idea what might be their magic? | 19:45.41 |
| tor8 | using big chunks of memory? that seems to be the apple way of doing things :) | 19:46.21 |
| malc_ | tor8: heh :) not an option for me though.. 512M RAM and no swap here | 19:47.04 |
| tor8 | well, swap would only slow things down anyway :) | 19:47.26 |
| malc_ | that's why it's disabled | 19:47.38 |
| Robin_Watts | ok, so I'm confused. git bisect has lead me back to the clipping thing. | 19:48.53 |
| | Let me try that again. | 19:49.00 |
| | oh, no, I understand. | 19:50.15 |
| | So it *is* the clipping change. I'll look to fix that. | 19:50.26 |
| malc_ | tor8: http://repo.or.cz/w/llpp.git/blob/dfcb1cbec81dcd09ff4fec8f058621598e37e3f1:/link.c at line 795 begins my outline processing code, you think variation on this should be added to pdf/pdf_outline.c and the fz_outline expanded with a coordinates of the link (you said rectangle though) | 19:55.09 |
| tor8 | malc_: there are a handful of different destination types in pdf | 20:00.51 |
| malc_ | tor8: i've covered everything i saw in my pdf collection.. but anyway apparently i was spot on when i said that i'm unqualified | 20:01.48 |
| tor8 | table 8.2 in pdfref17 (page 582) lists them all | 20:02.34 |
| malc_ | pdf_reference_1-7.pdf is a prime example why fz_outline in it's present form just doesn't cut it.. element covering 8.2.1 in outline in particular :) | 20:04.47 |
| tor8 | what's wrong with the current form? it says page 581 which is the right page...? | 20:09.05 |
| malc_ | the page is right, the position _within_ a page is nowhere to be found that's what's wrong | 20:12.20 |
| tor8 | right. well, a point or rect should be enough for most uses. I've never been a fan of how you can specify viewer behavior like zooming factors from links. | 20:14.23 |
| | so actually, just a point (make it the top left corner in the rect case) is probably what I'll do | 20:15.01 |
| malc_ | which is all i use currently, so more than fine with me | 20:15.25 |
| tor8 | and hopefully good enough for sumatrapdf | 20:15.39 |
| | Robin_Watts: any luck with the clip issue? | 20:15.58 |
| Robin_Watts | tor8: am looking now. | 20:22.01 |
| tor8 | Robin_Watts: I'll reject the binary now and upload a new one later when it's fixed | 20:22.24 |
| Robin_Watts | I think it's important that we allow a rectangle, not just a point. | 20:22.26 |
| tor8 | I've just run sane and there are a lot of problems | 20:22.33 |
| Robin_Watts | Imagine a viewer where you hover over a link and it pops up a bubble showing an image of where it goes to - for that you require the rectangle. | 20:23.40 |
| | If the information is there in the file, it should be exposed, IMAO. | 20:23.55 |
| | Oh... me so dim. | 20:27.02 |
| | tor8: 1 line change pushed. Sorry... | 20:30.42 |
| tor8 | ahem :) | 20:31.26 |
| | let me 'sane' it first, then I'll push :) | 20:32.26 |
| Robin_Watts | tor8: You have this 'csi->target' thing. | 20:38.36 |
| tor8 | yeah, feel free to abuse/hack that thing to something better | 20:38.52 |
| Robin_Watts | which you envisage (according to comments) as being 'View' 'Print' 'Export' | 20:38.55 |
| tor8 | yeah | 20:39.09 |
| Robin_Watts | Optional Content groups contain an "Intent" | 20:39.32 |
| | which is either a single name, or an array of names. | 20:39.49 |
| | (p376 of the 1.7 spec) | 20:40.03 |
| | That lists "View" and "Design" | 20:40.12 |
| | and All. | 20:40.23 |
| | I fear I need an 'intent' as well as a 'target'. | 20:41.25 |
| tor8 | page 382, table 4.53 lists an Event for OCGs as well | 20:42.19 |
| | this part of the spec is all a jumbled mess :( | 20:42.31 |
| Robin_Watts | yes indeed. | 20:42.53 |
| | That's why I think we need both. | 20:42.59 |
| | I was thinking about trying to come up with an enum that encapsulates both, but decided that having separate things would be safer. | 20:43.40 |
| tor8 | Robin_Watts: the grid fitting image patch makes type3 fonts look worse | 20:45.16 |
| | some files get uneven baselines | 20:45.39 |
| | anyway, *STUPID* commit pushed | 20:46.12 |
| Robin_Watts | How has that changed behaviour? | 20:46.31 |
| | I didn't think we were gridfitting in any situation where we weren't before... | 20:46.48 |
| tor8 | Robin_Watts: that's what I wonder too, I thought the type3 fonts should be unchanged as well | 20:46.55 |
| | sorry, false alarm | 20:48.02 |
| | the baseline was messed up before too | 20:48.12 |
| Robin_Watts | phew! | 20:48.14 |
| | Does disabling gridfitting give better baselines ? | 20:48.48 |
| tor8 | let me try that after I've compiled and uploaded a new binary | 20:49.08 |
| | to the app store | 20:49.12 |
| Robin_Watts | We could disable gridfitting within type3 glyphs. | 20:52.12 |
| tor8 | I thought we already did that (or well, that your scaler accounted for it and adjusted the scaling) | 20:54.37 |
| Robin_Watts | I can't obviously see that. | 20:55.38 |
| | Right. in fz_draw_fill_image | 20:56.26 |
| | being called for food. That's me done for the night , I think. | 20:58.25 |
| | Happy Thanksgiving everyone. | 20:58.34 |
| tor8 | Robin_Watts: good night! | 20:59.03 |
| | Forward 1 day (to 2011/11/25)>>> | |
IRC Logs