| <<<Back 1 day (to 2013/01/02) | 2013/01/03 |
marcosw1 | emrosenf: the person to ask is Robin_Watts, but he is in the UK and so won't be online for another 6 hours or so. | 02:38.40 |
emrosenf | Many thanks | 02:39.38 |
ray_laptop | alexcher: you are working late ! | 06:37.08 |
| I saw your response to the "qr" bug. I was also somewhat puzzled by this hodgepodge, but I'll post the code needed to overlay these two files, and see if I can get marcos to give me more info or a contact. | 06:46.35 |
Robin_Watts | Morning tor8 | 10:57.59 |
tor8 | Robin_Watts: morning | 10:58.56 |
Robin_Watts | Updated reviews etc online for you when you get a mo. | 10:59.09 |
sebras | tor8: good afternoon! | 12:56.34 |
kens | Hi sebras | 13:00.21 |
tor8 | Robin_Watts: int fz_stream_meta(fz_stream *stm, int key, int size, void *ptr); ? | 13:05.14 |
Robin_Watts | oh, bugger, did that slip through? | 13:05.35 |
| That's part of the pdfwrite stuff. | 13:05.47 |
| Will fix. | 13:05.52 |
tor8 | Robin_Watts: the obj_num_list stuff in the colorspace parsing, why not use the pdf_mark_dict functions? | 13:07.00 |
Robin_Watts | cos these aren't dictionaries. | 13:07.33 |
tor8 | I thought all non-trivial colorspaces (i.e. all except /DeviceRGB etc) were in dictionaries | 13:08.49 |
kens | arrays | 13:09.00 |
tor8 | kens: oh, right. | 13:09.15 |
Robin_Watts | what kens said :) | 13:09.18 |
kens | :-) | 13:09.32 |
tor8 | s/pdf_mark_dict/pdf_mark_object/ then perhaps? | 13:09.37 |
Robin_Watts | We'd have to bloat the object structure for that. | 13:10.07 |
tor8 | or pdf_mark_array, given that it's also a container object so could benefit from the same operations | 13:10.10 |
| to prevent recursions etc | 13:10.24 |
| the new bugzilla looks dreadful :( | 13:10.49 |
| the emails are illegible crap, and the web interface has broken layout everywhere | 13:11.03 |
kens | I tried the 'classic' scheme and IMO its worse | 13:11.07 |
| the emails should be fixed now | 13:11.14 |
Robin_Watts | tot8: fixed commits pushed. | 13:11.20 |
kens | tor8 you may need rto set teh preferences to 'text' in Bugzilla for emails | 13:11.42 |
tor8 | kens: it's either broken ascii art tables (due to gmail using prop fonts) or terrible too small courier font in the body :( | 13:12.46 |
kens | The HTML email (too small courier) looked so bad.... | 13:13.01 |
| But marcos changed it to text only | 13:13.14 |
| For me it works the same as before now | 13:13.29 |
tor8 | kens: the html email could be made to look better by just nuking the nasty html table borders | 13:13.33 |
| and setting a proper sized font and not monospaced for the body | 13:13.45 |
kens | THe teeny tiny Courier body text is terrible | 13:13.47 |
tor8 | but I guess that means hacking the bugzilla code | 13:13.54 |
kens | Especially since its *smaller* than the boilerplate.... | 13:14.01 |
tor8 | kens: I can't even read the tiny courier body text on my windows box. the font hinting completely screws up at that size | 13:14.26 |
kens | I htought at first it was just Eudora, so I switched it to use the Microsoft viewer. THen put it straight back becaus eit was (unbelievably) worse.... | 13:15.35 |
sebras | tor8: at least you are now running a relatively modern bugzilla with fewer security holes perhaps. ;) | 13:15.36 |
kens | The HTML emails are terrible, I don't know who thought up the layout but trhey should be beaten round the head with a UI design guide | 13:16.07 |
| Body text (the bit you want to read) that's smaller then the boilerplate ? | 13:16.29 |
tor8 | kens: very much so! | 13:16.53 |
| but the web interface html looks broken too! http://ghostscript.com/~tor/stuff/bugzilla.png | 13:17.25 |
kens | THat used ot happen before too | 13:17.45 |
tor8 | kens: oh... never noticed it before though | 13:19.50 |
| Robin_Watts: Bug 693503: Fix overlong (seemingly infinite) loop of warnings. ... that the right bug number? | 13:20.51 |
kens | tor8 I have seen it before, but not freqiuently I admit | 13:22.15 |
Robin_Watts | tor8: Yes. | 13:25.36 |
tor8 | Robin_Watts: I thought it might have been related to 693506 | 13:27.57 |
Robin_Watts | No, not knowingly so. | 13:28.30 |
| cluster tests just passed for all those current reviews. | 13:29.09 |
| Zeniko just mailed me about the one with obj_list_num in it, and offers an alternative solution | 13:29.50 |
| http://code.google.com/p/sumatrapdf/source/detail?r=7194# | 13:30.07 |
tor8 | Robin_Watts: I do worry about aborting the bf_range parse early | 13:30.11 |
Robin_Watts | tor8: I'll confess to being slightly at sea there, but it looked OK to me. Can you see a case where we'd go wrong? | 13:31.01 |
tor8 | Robin_Watts: I think I'd be happier with a pdf_mark_array function, seeing as we use pdf_mark_dict similarly | 13:31.16 |
Robin_Watts | tor8: OK. I'll think on it. | 13:31.32 |
tor8 | Robin_Watts: we early out before parsing the array/string that should be mapped | 13:31.58 |
Robin_Watts | ok, so we can safely add a marked flag to arrays without bloating pdf_obj's. | 13:33.29 |
tor8 | is the error one of producing too many warnings in the map_one_to_many loop? | 13:33.30 |
Robin_Watts | tor8: We produce 2 warnings per iteration of that loop./ | 13:33.55 |
| hence the warning suppression doesn't kick in. | 13:34.07 |
tor8 | oh... which are the two warnings? | 13:34.30 |
Robin_Watts | I can't remember. | 13:34.37 |
| I can find you a copy of the file if you want... | 13:34.51 |
| oh, it's on /home/support/693503/*/3192.pdf.SIGSEGV.b0.2438 | 13:35.42 |
tor8 | Permission denied :/ | 13:36.16 |
| oh well, I have sudo access so problem solved. just annoying. | 13:37.55 |
| Robin_Watts: two different alternating warnings with that file | 13:41.03 |
| warning: range limits out of range in cmap Adobe-Identity-UCS | 13:41.20 |
| warning: one to many mapping is too large (60); truncating | 13:41.20 |
| then... | 13:41.23 |
| warning: one to many mapping is too large (60); truncating | 13:41.29 |
| warning: cannot map one to many; table is full | 13:41.30 |
| can't help but think that the file is really broken | 13:41.35 |
Robin_Watts | tor8: oh yes, it's a broken file alright. | 13:42.28 |
| but an infinite seeming loop is still bad. | 13:42.43 |
Robin_Watts | gets lunch. | 13:42.51 |
tor8 | Robin_Watts: yes. I'll investigate some more. | 13:43.23 |
| Robin_Watts: oh, I know why it looks so badly broken... | 13:44.25 |
| <0f00> <0fff> <0f00> | 13:44.34 |
| <1000> <10e00> | 13:44.35 |
| <010010e00> <01ff1 <01001 | 13:44.36 |
| <02001 <02ff1 <02001 | 13:44.37 |
| <03001 <03ff1 <03001 | 13:44.38 |
| error: zlib error: invalid distance too far back | 13:45.15 |
| Robin_Watts: maybe we should give up earlier... here's what happens if I fix the warning duplications: | 13:53.56 |
| error: zlib error: invalid distance too far back | 13:53.57 |
| warning: read error; treating as end of file | 13:53.57 |
| warning: range limits out of range in cmap Adobe-Identity-UCS | 13:53.59 |
| warning: ... repeated 1048578 times ... | 13:54.00 |
| error: expected string or endbfrange | 13:54.00 |
marcosw1 | tor8: the html bugzilla issue you mentioned earlier doesn't happen under firefox: http://ghostscript.com/~marcos/bugzilla.png | 14:39.17 |
| I'll check under chrome later today. | 14:39.52 |
| there are a lot of configurable options relating to display of bugs, it might be something we can fix. | 14:40.23 |
sebras | marcosw1: tor8: it happens both in chromium and firefox depending on zoom-level (ctrl-wheel). | 14:47.05 |
Robin_Watts | zooming in the browser breaks *everything*, IME. | 15:01.01 |
sebras | Robin_Watts: exactly, I can get chrome to look good in 67% magnification, and I can get chromium/firefox to break if I zoom... | 15:08.28 |
marcosw | tor8: I fired up an instance on amazon with the pre-update bugzilla and it renders the html pretty much 100% the same as the new under chrome (i.e. both are formatted badly): http://www.ghostscript.com/~marcos/old_vs_new.png | 16:26.38 |
| I'll leave http://54.235.194.74/bugs.ghostscript.com/ up for a bit, in case people are feeling nostalgic :-) | 16:28.05 |
ray_laptop | mvrhel: How are you doing? I hope you are starting to feel better. | 16:38.35 |
| mvrhel: when you do feel better, I'd like to chat with you about a couple of cust 532's issues. | 16:39.01 |
Robin_Watts | emrosenf: I have never built gs for iOS, as a library or otherwise. | 16:46.40 |
emrosenf | I see. I imagine building it as a library shouldn't be too dissimilar from the OSX Framework target. Do you have any ideas what I would need to do to modify the build scripts? | 16:48.42 |
Robin_Watts | emrosenf: I have no idea about the OSX framework target. | 16:50.04 |
| If it was me, I'd work from the standard makefiles and avoid Xcode like the plague. | 16:50.53 |
emrosenf | Point taken. Thanks. | 16:51.58 |
| Do you know about the general architecture of the build scripts? If I want to set a bunch of CFLAGS for the entire build process, are they passed between the different makefiles or do they have to be set for each different one? | 16:53.01 |
Robin_Watts | emrosenf: chrisl is the expert here, but in general, set CFLAGS (or XCFLAGS) at the top level and they get passed through. | 16:56.12 |
| tor8: New version pushed. | 16:57.18 |
| henrys, tor8, paulgardiner: My memory was that we had vaguely said we'd have a meeting today. I have nothing to report though (other than slowly plodding through the hundreds of failure reports from 395). | 16:58.17 |
henrys | Oh I guess I forgot. I don't have anything really | 17:00.04 |
marcosw | I restored the previous bugzilla look to not underline hyperlinks (unless you hover over them). | 17:02.34 |
henrys | emrosenf:some reason you need gs vs. mupdf which already runs on iOS | 17:03.07 |
| ? | 17:03.34 |
emrosenf | henrys: I am playing with PS and PCL | 17:03.35 |
henrys | emrosenf: that's a good reason | 17:03.53 |
emrosenf | Well I'll stay on the IRC and let you all know about the script i I ever have any success | 17:05.26 |
| There's no info on Google -- perhaps this hasn't been done before | 17:05.51 |
mvrhel_laptop | hi ray_laptop: I am starting to feel a bit better. hopefully I can get a few useful things done today | 17:10.34 |
kens | Goodnight all | 17:23.52 |
ray_laptop | mvrhel: When I made the change to limit the interpolation level for cust 532, I had the interpolate code emit an image (instead of copy_color) and it was going into a pattern-clist as rectangles, but I tripped over a case where the clist reader was using tdev->color_info.depth that was the wrong value. | 17:28.36 |
| mvrhel: I found that I needed to update the clist device's color_info in c_pdf14trans_clist_read_update, then use the cdev->color_info.depth instead of the tdev->color_info.depth. | 17:28.37 |
| mvrhel: but I can't make the HEAD code fail because it either puts HL images into the pattern-clist, or it puts 'copy_color' (if I force interpolation pre-clist). | 17:28.39 |
| mvrhel: but I don't see how a pattern-clist with a fill_rectangle would ever work with the HEAD code. I'm going to try and put together a test case. | 17:28.40 |
mvrhel_laptop | ok. ray_laptop: my head is still fuzzy to be jumping into pattern clists with transparency | 17:29.42 |
| if you have a case that fails though please open a bug for me to look ovr | 17:30.06 |
| over | 17:30.08 |
ray_laptop | mvrhel: OK. I don't blame you. | 17:31.01 |
| mvrhel: are you working on the pdf14_copy_color (or was I supposed to have picked that up) ? | 17:31.40 |
mvrhel_laptop | ray_laptop; no I have been working on ETS stuff | 17:31.57 |
ray_laptop | mvrhel: cust 532 was asking, so if you are tied up with ETS, I'll dive into that next. | 17:32.58 |
mvrhel_laptop | ray_laptop; yes. I want to get this all back to Max. I don't want him waiting on me. | 17:33.34 |
Robin_Watts | tor8: ping | 17:35.50 |
| Forward 1 day (to 2013/01/04)>>> | |