| | <<<Back 1 day (to 2011/10/20) | 2011/10/21 |
| mvrhel2 | aha! its a clist issue | 00:12.55 |
| | I will finish this up in the evening | 00:13.02 |
| | clist is mucking up the dash cap attributes | 00:13.15 |
| | bbiaw. cub scout meeting tonight... | 00:13.45 |
| henrys | mvrhel2:yes that is a known deficiency I thought it was documented somewhere. | 00:25.28 |
| mvrhel2 | henrys: we seem to have the settings for it in the graphics lib and we are getting correct results (at least for my one test case) in non clist mode and wrong results in clist mode | 00:32.22 |
| | I will dig a bit more tonight | 00:32.35 |
| | have to go now | 00:32.44 |
| sebras | good night. | 01:01.38 |
| henrys | alexcher? | 02:12.12 |
| mvrhel2 | henrys: so it appears it is just the clist case where all the caps are set to the same as the start cap | 03:57.27 |
| | why would we have it that way | 03:57.42 |
| | there is a a comment even in the code that we make this assumption | 03:58.39 |
| | I am going to go ahead and try to make it work properly | 03:58.58 |
| SoobNauce | printing? | 04:01.48 |
| Fandekasp | hello | 04:44.10 |
| ghostbot | what's up | 04:44.10 |
| Fandekasp | hu this bot ask questions ? weird :P | 04:44.33 |
| mvrhel2 | henrys: you there? | 05:43.52 |
| | so I have the dash caps ends start and stop business working. it was just broken in the clist case it appears. | 05:44.22 |
| | there is one additional issue which relates to the putting of an end cap and then end of a white dash | 05:45.25 |
| | portion | 05:45.29 |
| | when the path ends there | 05:45.33 |
| | for some reason my windoze xps viewers don't seem to do it the way that they used to do it. I am thinking that microsoft may have changed this | 05:50.22 |
| | need to look at the spec | 05:50.31 |
| | hmm I wonder who these guys are http://www.xpsviewer.com/websites/xpsviewer/Default.aspx | 05:52.21 |
| henrys | yes I'm here I must be thinking of something else that we didn't support for xps. | 05:54.13 |
| | if you run the setup and send me the exe I'll search it. I'd rather not boot windows. | 05:58.50 |
| mvrhel2 | henrys: from my reading of the spec, I think with this fix we are doing it correctly | 05:58.54 |
| | and iirc that is what it used to be when I would render it with explorer, but right now my machine is doing something different. | 05:59.29 |
| | let me push this to see if all is well as this change is in the graphics lib | 05:59.43 |
| henrys | okay | 05:59.57 |
| mvrhel2 | clist reading and writing specifically | 05:59.57 |
| henrys | morning chrisl | 06:42.22 |
| chrisl | morning henrys | 06:42.42 |
| LaoLang_cool | morning all | 06:43.33 |
| LaoLang_cool | is in the afternoon here... | 06:43.48 |
| henrys | india? | 06:45.52 |
| LaoLang_cool | China :) | 06:46.55 |
| henrys | saw your fix mvrhel2 funny that hasn't come up before. | 06:50.11 |
| mvrhel2 | yes, I am surprised too | 06:50.24 |
| | thats it for me. | 06:53.15 |
| kens | night mvrhel2 | 06:53.27 |
| mvrhel2 | see you all tomorrow. (or later today) | 06:53.28 |
| henrys | Ah I see start, end caps wasn't supported all along, robin_watts added it Dec 4 2009 and didn't do banding. | 06:56.35 |
| | goodnight all | 06:59.18 |
| kens | night henrys | 06:59.24 |
| henrys | ah glad you're here we wouldn't want to be unsupported ;-) | 06:59.50 |
| kens | :-) | 06:59.56 |
| | Looks like it wasnt' too hectic overnight | 07:00.08 |
| chrisl | kens: that's the mupdf commercial release up on the web site, and pages updated to match, if you want to let Raed know | 07:52.12 |
| kens | OK I'll pen him en email now (will check it first so I know I'm sending the right URL) | 07:55.30 |
| | tor8 is up very early | 07:58.33 |
| tor8 | kens: furniture delivery... my new sofa has arrived! | 07:59.36 |
| kens | From Ikea ? :-P | 08:00.01 |
| tor8 | thankfully not! | 08:00.10 |
| kens | You mena there are alternatvies in Sweden ? | 08:00.27 |
| tor8 | plenty of alternatives :) | 08:00.37 |
| kens | :-) | 08:00.40 |
| tor8 | in fact, I'm replacing my old crappy IKEA sofa with something a lot better | 08:00.51 |
| kens | Our sofa i axctually from Ikea :-) | 08:01.19 |
| tor8 | my main issue with ikea sofas, apart from the sometimes dodgy quality, is that the vast majority of them have too short backs | 08:01.56 |
| kens | Interesting. | 08:02.04 |
| | The reason we bought ours from Ikea is because it has amuch higher back tan the sofas on sale elsewhere at the time. | 08:02.31 |
| | This was a few years ag now mind you | 08:02.44 |
| tor8 | well, that is interesting! :) | 08:02.50 |
| kens | I really hate low backed sofas | 08:03.13 |
| tor8 | yeah, I bought extra neck-pillow/supports for the new sofa | 08:03.59 |
| | http://www.ikea.com/se/sv/catalog/products/S09874337/ this is what I used to have (in a different color) | 08:04.12 |
| kens | Well, you are taller than me. | 08:04.13 |
| tor8 | very high back, but not very comfortable otherwise | 08:04.21 |
| kens | Oh :-( | 08:04.29 |
| kens | is amused to see Ikea listings in actual Sedish | 08:05.14 |
| tor8 | the names are the same! :D | 08:05.32 |
| kens | Yes, but it all looks so much more sensible that way | 08:05.42 |
| chrisl | That's looks a little like my sofa, but mine's a twenty year old Ligne-Rose sofa bed - bugs me that it doesn't have arm rests! | 08:05.55 |
| tor8 | yeah, the lack of arm rests hurts comfortability a lot | 08:06.23 |
| kens | I can't evern remember what our sofa is called, I doubt Ikea still seel it and I don't have any pictures to hand | 08:06.25 |
| tor8 | http://www.em.com/web/mobler_soffor/Webb/Produkter/Soffor/HAAG_2H2_oppet_avslut_hoger-41464.aspx?ArticleID=6e977cd4-9aa7-4216-bd4d-de21eec65acd this is the new one, with added bits on top to rest your head on (whatever they're called ... too early in the morning for my vocabulary to work) | 08:07.37 |
| chrisl | Nice. I'd struggle to fit that in my living room :-( | 08:08.22 |
| kens | suspects there may be a term in English, but has no idea what it would be | 08:08.27 |
| chrisl | Headrests? | 08:08.44 |
| kens | I suspect that there may be a specific sofa-related term | 08:09.01 |
| chrisl | In a car, they'd be headrests | 08:09.14 |
| kens | Our car doesn't come with a sofa :-) | 08:09.38 |
| | I was thinking of a word like 'aglet' you kow the metal bit on the end of a shoelace. something highly specific like that | 08:10.14 |
| tor8 | in swedish they're called necksupports | 08:10.17 |
| chrisl | We used to have a pickup with a bench seat - nearly a sofa........ | 08:10.24 |
| tor8 | literally translated, of course | 08:10.29 |
| kens | The do in fact seem to be called headrests | 08:10.47 |
| | At Ikea in the UK and other sofa vendors | 08:11.15 |
| | Eg: | 08:11.49 |
| | http://www.barkerandstonehouse.co.uk/nottingham_Detail1.php?ID=1158&Store=Newcastle | 08:11.50 |
| | which looks spectacularly uncomfortable to me | 08:11.50 |
| chrisl | Okay, time to context switch from "hating html mode" back to "hating UFST mode"........ | 08:14.06 |
| kens | phew, my latest cluster test seems to be OK. So now I can go on and try to find out why these fonts don't always report the correct CIDs from the GlyphDirectory. | 08:15.20 |
| chrisl | puts off "hating UFST mode" a little by fetching coffee........ | 08:15.50 |
| kens | Great, I have a fix for the GlyphDirectory problem. But now that the text isn't missing I can see that the Arabic text is incorrectly spaced :-( | 09:05.57 |
| Robin_Watts | kens: Dunno if you were around when I mentioned GitExtensions yesterday. | 10:07.32 |
| | It's a plugin for visual studio that lets you do git stuff from inside VS. | 10:07.53 |
| kens | I read it in the logs | 10:08.04 |
| guilhas | yoyo ppl | 10:12.16 |
| | anyone here? | 10:12.22 |
| kens | Quite a number | 10:12.33 |
| guilhas | lol | 10:13.05 |
| | anyone from mupdf | 10:13.11 |
| | ? | 10:13.13 |
| Robin_Watts | mmm | 10:13.24 |
| guilhas | i normaly use the terminal to navigate my files | 10:14.45 |
| | and i want to be able to open pdfs in background | 10:15.09 |
| | but this "mupdf () { mupdf "$@" &}" is not working | 10:15.45 |
| | mupdf:1: maximum nested function level reached | 10:16.22 |
| | anyone? | 10:16.42 |
| Robin_Watts | guilhas: Sorry, I don't follow. | 10:17.22 |
| kens | Some kind of arcaner shell stuff ? | 10:17.43 |
| Robin_Watts | Indeed. | 10:17.49 |
| guilhas | lol | 10:17.58 |
| Robin_Watts | but if mupdf works when invoked normally, and the problem is with some strange mechanism being used to invoke it, I'm not sure what he wants us to do. | 10:18.27 |
| kens | does not speak those runes | 10:18.57 |
| chrisl | I'd guess, from the error, that the mupdf command is recursively calling itself...... | 10:19.01 |
| Robin_Watts | guilhas: I think the problem is that: fred () { fred "$@" & } is recursing within itself. | 10:19.20 |
| | Try using: fred () { mupdf "$@" & } | 10:19.45 |
| chrisl | Or (in bash, at least) use an alias - that should avoid the recursion...... | 10:20.31 |
| guilhas | yeah | 10:21.42 |
| | it worked | 10:21.54 |
| | can you explain again why? | 10:22.04 |
| | the conection went down | 10:22.16 |
| | thx a lot! | 10:22.27 |
| Robin_Watts | You're setting up a rule that says: "when asked to execute mupdf, actually execute mupdf "$@" & | 10:22.44 |
| | and then to execute that it's saying: "Ah, I have a rule to execute mupdf, let me follow that..." and you end up with mupdf "$@" "$@" &. | 10:23.38 |
| | & | 10:23.49 |
| | and so on. | 10:23.51 |
| chrisl | guilhas: what shell are you using? | 10:24.27 |
| guilhas | so cool, now i recall this is not the first time i have this problem | 10:26.28 |
| | zsh | 10:26.35 |
| tor8 | guilhas: your function definition shadows the command, you're building a recursive function | 10:27.15 |
| guilhas | a problem nothing to do with the development actualy xD | 10:27.28 |
| tor8 | try this: mupdf() { command mupdf "$@" } instead | 10:27.38 |
| | the "command" should prevent it from looking at functions and builtins -- but it may be a bashism that doesn't exist in zsh | 10:28.06 |
| | or just use an absolute path or rename the mupdf executable | 10:28.22 |
| guilhas | also worked. linux is so cool xD | 10:29.00 |
| | and easy logic as soon as you understand it :) | 10:29.49 |
| kens | Hmm, my network seems to have gone to sleep, so I'm going to reboot the router. Be rightback. | 10:30.06 |
| guilhas | tanks got to go | 10:30.07 |
| kens | That seems better | 10:32.55 |
| kens | liikes today's BOFH | 10:34.01 |
| tor8 | Robin_Watts: your ipod touch, does it have armv7 or only armv6? | 13:19.13 |
| Robin_Watts | It's a 3G one. | 13:25.57 |
| | http://www.everymac.com/systems/apple/ipod/ipod-faq/ipod-processor-type-portal-player-samsung.html | 13:27.12 |
| | The newly introduced third-generation iPod touch contains a S5L8922X series processor, which is a slight numerical increment over the processor in the iPhone 3GS. | 13:28.35 |
| | Believed to be a member of the ARM cortex-A8 family. So ARM v7. | 13:29.08 |
| tor8 | right. because the first gen stuff only has arm v6, and apple likes their fat binaries with multiple architectures in one. | 14:10.37 |
| | guess what happens to mupdf's embedded droid sans fallback and cmap data... | 14:11.07 |
| | Robin_Watts: so I'm considering whether to compile for only arm v6 or require arm v7 | 14:11.26 |
| | and what the app store policy is for arm v6 only apps... | 14:11.45 |
| Robin_Watts | likes@ | 14:11.49 |
| | ? | 14:11.51 |
| | You mean links ? | 14:11.55 |
| tor8 | no, I meant likes, as in being fond of | 14:12.10 |
| | macosx universal apps with both ppc and intel code in the binary | 14:12.24 |
| Robin_Watts | Right. | 14:12.30 |
| tor8 | and ios apps with both arm v6 and v7 | 14:12.40 |
| Robin_Watts | So the cmap data gets put in twice? | 14:12.44 |
| tor8 | yup. it's code so gets duplicated. | 14:12.57 |
| Robin_Watts | Hmm. | 14:13.15 |
| | Ordinarily I'd recommend you just built for v6. | 14:13.24 |
| tor8 | the mupdf app is 12mb, but if we restrict to one format it's only the usual 6 | 14:13.26 |
| Robin_Watts | because no compiler makes use of the NEON stuff worth a damn - except possibly for FP. | 14:13.50 |
| | Morning henrys. | 14:15.19 |
| | Yes, I added start/end caps specifically for xps. At the time I did it, I hadn't had the pleasure of meeting banded mode yet :) | 14:15.45 |
| | And I opened a bug with the problem with endcaps at the end of dashed paths at the time. | 14:16.18 |
| henrys | howdy | 14:18.27 |
| ghostbot | hello | 14:18.27 |
| henrys | Robin_Watts:I can't believe that was 2 years ago almost - time flies. | 14:19.37 |
| Robin_Watts | mmm. Was one of the first things I did. | 14:20.02 |
| henrys | alexcher:you debugged the customer's postscript program, nice. | 14:22.00 |
| | kens:seems like more problems come in on your watch feel free to leave some. | 14:36.43 |
| kens | Its OK henrys | 14:37.56 |
| | I'm still looking at the VMerror one, I've done the others | 14:38.08 |
| | It does always seem to get busy when Marcos takes vacation | 14:38.37 |
| | Well the customer's file gets a memoray allocation failuer on my machine using their setup, or a crash in gc_reloc_struct_ptr from pdf14_device_rloc_ptrs in a vmreclaim, just like the last file they sent with loads of separations. | 14:45.58 |
| henrys | did you run with -Z? | 14:47.29 |
| kens | No, I ran it under a debugger | 14:47.40 |
| | I can try -Z if you like, will take a minute | 14:47.52 |
| henrys | I guess just assign it to ray_laptop he is working on another one of those. | 14:48.27 |
| kens | I suspect its the same problem. | 14:48.35 |
| | -Z produced nothing, should it ? | 14:48.46 |
| henrys | well the ? checks objects | 14:49.19 |
| kens | So, -Z? then | 14:49.29 |
| henrys | you can specify options in the debugger. | 14:49.38 |
| Robin_Watts | kens: "-Z?" not "-Z" :) | 14:49.39 |
| kens | Yes is what I meant, and yes I can specify options in the debugger | 14:50.04 |
| henrys | you should get "invalid object" message | 14:50.06 |
| kens | Its slower, but no messages. The executable curls up and dies silently instead | 14:51.18 |
| | Looks like adding that makes it work :-P | 14:52.16 |
| | Hmm, no, no output, looks like it just dies silently that way. | 14:53.21 |
| henrys | well I'd just assign it to ray_laptop at this point ... | 14:53.40 |
| kens | I'm going to attach it to the other bug, I think its the same problem (modulo the memory exhaustion caused by massie MaxBitmap) | 14:53.45 |
| henrys | lucky him | 14:53.46 |
| kens | finsally digs out from under support | 14:57.40 |
| | henrys will uou reply to Wolfgang ? | 15:37.46 |
| henrys | yes I was just doing it | 15:37.56 |
| kens | thanks, I replied to Gemma | 15:38.10 |
| Robin_Watts | needs an mvrhel2. | 15:42.46 |
| henrys | now if these whiners will leave me alone for a few minutes I can do real work. | 15:43.01 |
| | I think mvrhel2 is enjoying xps bugs ... | 15:44.01 |
| Robin_Watts | Aha. Morning mvrhel2. | 15:52.26 |
| | I've just changed copy_plane to copy_planes locally, and wanted to talk to you about it. | 15:53.05 |
| mvrhel2 | good morning | 15:53.21 |
| | ok | 15:54.22 |
| Robin_Watts | I've repurposed the 'plane' field from the end of copy_plane to be 'plane_height'. | 15:55.03 |
| mvrhel2 | was there not a height parameter already? | 15:55.56 |
| Robin_Watts | That means that the source data for plane n can be found at base + n*raster | 15:55.57 |
| | That means that the source data for plane n can be found at base + n*raster*height | 15:56.08 |
| | (sorry) | 15:56.10 |
| henrys | alexcher:you can just send a source tar ball to chrisl and he will create the public branch. | 15:56.11 |
| Robin_Watts | That means that the source data for plane n can be found at base + n*raster*plane_height | 15:56.16 |
| mvrhel2 | ok that makes sense | 15:56.44 |
| Robin_Watts | There was a height already, yes, but I need to allow for copying from a subrectangle of data. | 15:56.55 |
| | So I had to dive into the clist stuff. | 15:57.07 |
| | You were sending a plane of 255 to mean 'copy_mono'. | 15:57.19 |
| | I've changed that to be a plane_height of 0. | 15:57.27 |
| mvrhel2 | a plane of 255? | 15:57.49 |
| | that does not sound too intuitive | 15:57.59 |
| Robin_Watts | You wrote the clist code for this, right ? | 15:58.03 |
| mvrhel2 | oh. in the clist | 15:58.11 |
| | that is possible | 15:58.13 |
| | nothing is intuitive in that | 15:58.19 |
| Robin_Watts | 255 was a sensible value,as 0...n can be used for plane numbers. | 15:58.33 |
| mvrhel2 | yes | 15:58.43 |
| | I remember now | 15:58.45 |
| Robin_Watts | A plane_height of 0 makes no sense, so seems sensible. | 15:59.00 |
| | (if you see what I mean) | 15:59.09 |
| mvrhel2 | yes | 15:59.10 |
| | like my assumption that we would not run into 255 planes | 15:59.29 |
| | 265 I mean | 15:59.37 |
| | 256 | 15:59.41 |
| Robin_Watts | But I had a question... it looked to me like you could only send depth=1 planes ? | 15:59.42 |
| mvrhel2 | good grief | 15:59.44 |
| | that may be the case now | 15:59.59 |
| | as that is the way the ht code is all written which drove this | 16:00.19 |
| Robin_Watts | See line 930 of gxclrast.c | 16:00.51 |
| | (at least it's line 930 for me) | 16:01.01 |
| | depth=1; | 16:01.05 |
| | can we make that depth = tdev->color_into.depth ? | 16:01.15 |
| mvrhel2 | hold on. i dont even have the project open yet | 16:01.15 |
| Robin_Watts | fetches caffiene. brb. | 16:01.27 |
| | kettle on... | 16:02.24 |
| | Does this seem like an interface you can work with ? | 16:03.05 |
| mvrhel2 | sorry got distracted reading marcos' blog | 16:04.13 |
| | Robin_Watts: I think we could do the change on line 930 that you wanted. and the interface sounds fine | 16:05.20 |
| Robin_Watts | Cool. I'll run some more tests on this. | 16:05.57 |
| mvrhel2 | the change at line 930 may have some issues though | 16:06.04 |
| Robin_Watts | This planar stuff is like whack a mole. Every time I squash one bug, something else goes wrong... | 16:06.23 |
| kens | Heading off now, support to henrys. Have a good weekend everyone | 16:06.28 |
| JoeJulian | I've got a pdf that I'm trying to print that segfaults ( http://fpaste.org/d7aJ/ ), but only when it's run from cups. If I run it directly it produces the right output. version 8.70-6.el5_7.3 | 16:06.35 |
| Robin_Watts | Have a good one kens. | 16:06.35 |
| mvrhel2 | if we have some source data that is 1 bbp and we are heading out to a target that is RGB would likely be a problem | 16:06.37 |
| | bye kens | 16:06.41 |
| Robin_Watts | mvrhel2: Then you should be calling copy_mono, right? | 16:07.00 |
| mvrhel2 | true | 16:07.07 |
| | ok | 16:07.09 |
| chrisl | JoeJulian: you should get a newer Ghostscript - in 9.04 we fixed some significant problems with the cups device. | 16:07.42 |
| mvrhel2 | I think it would be fine to do that change | 16:07.47 |
| Robin_Watts | copy_plane is copy_color, but with planar data to a planar outut device. | 16:07.54 |
| mvrhel2 | since we only do this operation in the ht image code | 16:08.02 |
| | color image | 16:08.07 |
| Robin_Watts | Well, the planar device ends up calling it. | 16:08.15 |
| mvrhel2 | yes | 16:08.21 |
| JoeJulian | Thanks chrisl, I was afraid that would be the answer. :D | 16:08.31 |
| mvrhel2 | ok. so Robin_Watts, I guess I need to get cracking on packing the data all together | 16:08.49 |
| Robin_Watts | If you have a planar pattern tile, and you draw another planar pattern into it, then that can call copy_planar | 16:08.53 |
| chrisl | JoeJulian: I'm not promising it's actually fixed, but that would be my first step | 16:08.53 |
| Robin_Watts | mvrhel2: It might make sense for you to wait until I have a patch to give you. | 16:09.10 |
| mvrhel2 | sounds good | 16:09.17 |
| Robin_Watts | In case I hit *ANOTHER* bug. | 16:09.19 |
| | I need tea. | 16:09.33 |
| mvrhel2 | oh. thanks for pointing me to the XPS bug with the dash joint. | 16:09.50 |
| | I may fool with that one after I finish up the customer XPS issues | 16:10.23 |
| Robin_Watts | mvrhel2: It's unclear to me that there is a 'right' answer to that. | 16:14.48 |
| | My (2 year old) memory of this is that ours looked 'saner'. | 16:15.31 |
| | and changing the code to match the XPS stuff would have broken PS files. | 16:16.10 |
| mvrhel2 | Robin_Watts: I need to review the spec. We are doing the right thing on the path start and end dash cap (when we end right on a dash off). But I did not look at the joint stuff. I remember working on it years ago and had a solution that I thought agreed with the spec. Yes, we will have to add a joint style option or something | 16:17.07 |
| | to keep from breaking PS | 16:17.37 |
| Robin_Watts | It would be interesting to see what XPS does with 'thick lines' too. | 16:18.25 |
| mvrhel2 | what is classified as a thick line? | 16:18.43 |
| Robin_Watts | Consider the following path: 0 0 moveto 1 1 lineto 2 0 lineto. | 16:18.46 |
| | Now stroke that with a linewidth of 100. | 16:18.59 |
| mvrhel2 | oh | 16:19.04 |
| Robin_Watts | With 'no' join we get an X, right? | 16:19.19 |
| mvrhel2 | I don't know what I would get | 16:19.40 |
| Robin_Watts | In PS, all the join styles only affect the top 'V' section of the X. | 16:19.56 |
| | (if you see what I mean) | 16:20.03 |
| | we don't join 'under' the curve. | 16:20.19 |
| mvrhel2 | Robin_Watts: I will need to think about this one a bit later. | 16:22.46 |
| Robin_Watts | Sure. I mention it just as a curiosity. | 16:22.57 |
| | It's a very corner case. | 16:23.02 |
| mvrhel2 | it is an intersesting one. appropriate for a XPS CET test | 16:23.20 |
| Robin_Watts | henrys: As you're wearing the support hat... | 16:30.13 |
| henrys | yes | 16:30.30 |
| Robin_Watts | Gemma is running 8gig of memory in her windows system, so presumably must be running a 64bit version of the OS. | 16:30.47 |
| | If she's only running a 32bit version of gs, then a simple fix might be for her to run the 64bit version? | 16:31.07 |
| chrisl | Robin_Watts: 32 bit OS can use the 8Gb using PAE extensions | 16:35.42 |
| henrys | well I think it just needs to be fixed properly, yes the 64bit exe could seem to work then she reports back to her customer it is fixed and it isn't. We need to get to the bottom of it. | 16:35.45 |
| Robin_Watts | chrisl: Eh? | 16:35.57 |
| ray_laptop | Robin_Watts: which bug ? | 16:36.12 |
| | if it's 692618, I've made progress on the segfault | 16:37.12 |
| Robin_Watts | chrisl: Wow. I didn't know about that. | 16:37.14 |
| ray_laptop | goes to check the logs | 16:37.29 |
| Robin_Watts | ray_laptop: I'm just earwigging based on what I've read on the support list. | 16:37.34 |
| | henrys: Yes, clearly we want to fix it correctly. | 16:37.45 |
| henrys | ray_laptop:this is a different customer but kens attached it to 692618 | 16:37.59 |
| | I'm not sure if he added the extra customer number. | 16:38.20 |
| chrisl | Robin_Watts: PAE extensions lets the OS "map" areas of the address space to different physical memory addressed beyond the normal restriction - so each process still only has 2Gb address space, but several such process can coexist | 16:38.37 |
| | http://en.wikipedia.org/wiki/Physical_Address_Extension | 16:39.01 |
| ray_laptop | henrys: I see another file (that Gemma sent) attached to 692618 -- what other customer ? | 16:39.15 |
| henrys | oh maybe it was the same customer. | 16:39.58 |
| ray_laptop | I have found/fixed a couple of dangling pointers that could cause crashes (I was able to duplicate the crash with certain options) | 16:42.07 |
| | the fixes also get rid of the ilocate messages that the dangling pointers caused during a GC | 16:42.37 |
| | still one misbehaviour without -dMaxBitmap=500000000 | 16:44.13 |
| Robin_Watts | ray_laptop: Should we be using setting ulong to be unsigned long long on windows 64bit ? | 16:45.58 |
| | AIUI, the 'offset' in the clist determines its maximum size. | 16:46.23 |
| | This is currently of type 'ulong'. | 16:46.32 |
| | Which is 64bits on 64bit linux, but only 32 on windows. | 16:46.48 |
| henrys | Robin_Watts:isn't this the same offset that goes to fseek - so should be long right? | 16:55.45 |
| Robin_Watts | Don't we use fseek64 or something? | 16:56.43 |
| henrys | ah yes right. | 16:57.10 |
| Robin_Watts | i.e. if we are limiting ourselves to 32bit offsets, then we are limiting ourselves to 4gig clist files. | 16:57.22 |
| | I know that we support > 4Gig clist files, but maybe only on linux ? | 16:57.40 |
| henrys | yes I thought Igor actually did the 64 bit clist work on 32 bit windows so I'd expect ... | 17:00.04 |
| Robin_Watts | Then I'm confused. Maybe ray_laptop knows what the secret sauce is | 17:01.30 |
| henrys | probably, you are now 64 bit right? so you can't simply set a bp on the gp_ function? | 17:02.00 |
| ray_laptop | Robin_Watts: the clist uses 64-bit | 17:02.05 |
| | We use 64-bit file I/O even on 32-bit platforms. | 17:02.34 |
| henrys | well here offset is an int, how does that work? code = pinfo->io_procs->fseek(pfile, offset, SEEK_SET, fname); | 17:02.55 |
| ray_laptop | one of the bugs (performance) that I just worked on created a 223 Gb clist | 17:02.59 |
| | henrys: what line ? | 17:03.21 |
| henrys | gxclist.c:1288 | 17:03.35 |
| | bbiab | 17:04.27 |
| Robin_Watts | henrys: I don't have a file to hand that creates a large clist :) | 17:04.47 |
| mvrhel2 | bbiaw | 17:05.37 |
| ray_laptop | Robin_Watts: check the file with 692158 | 17:07.20 |
| Robin_Watts | ray_laptop: Can't at the moment, as my tree is in bits all around me, but I will do. | 17:07.51 |
| | so you're saying that clist > 4Gig DOES work on 64bit windows ? | 17:08.11 |
| | or on all windows ? | 17:08.19 |
| ray_laptop | Robin_Watts: np -- I was just making sure you had one | 17:08.22 |
| | Robin_Watts: clist > 4Gb works on 32-bit machines, AFAIK. I'm diverting to look into it. | 17:08.54 |
| Robin_Watts | ray_laptop: Could it be that it works as long as the 'offset' remains within 32bit boundaries? | 17:09.39 |
| | (i.e. the c can be >4 gig, but the b can't? (or the other way around)) | 17:10.05 |
| ray_laptop | but even 64-bit builds should have a problem with an 'int' offset since that is 32-bit on 64-bit platforms, isn't it ? | 17:10.22 |
| Robin_Watts | Yes. | 17:10.30 |
| | The offset in the table (hash_table?) (which is where I originally saw this) is a ulong. | 17:11.06 |
| | but the bit henrys just pointed to is indeed an int. | 17:11.15 |
| ray_laptop | Robin_Watts: I agree that it looks broken. 'clist_data_size' as well | 17:13.27 |
| | the gxclfile.c all has int64_t offset in seek and return value for tell | 17:14.36 |
| | as in gxclio.h | 17:15.58 |
| Robin_Watts | So it's just patterns that will have a problem. | 17:16.16 |
| | as they are the only callers of clist_put_data | 17:16.27 |
| ray_laptop | looks like it never got finished | 17:16.36 |
| | Robin_Watts: maybe the ICC code as well (we'd have to check) | 17:16.52 |
| Robin_Watts | No, only callers are patterns :) | 17:17.13 |
| | and gxclist.h line 114. | 17:18.06 |
| ray_laptop | it looks like mvrhel did 'clist_find_pseudoband' correctly (used int64_t) | 17:18.41 |
| | and the same for clist_read_chunk | 17:19.14 |
| | surprising, since the same person did those functions as did the 64-bit extensions. | 17:21.04 |
| | Robin_Watts: do you want to go ahead and fix it, or do you want me to ? | 17:21.19 |
| Robin_Watts | ray_laptop: The possibility of screwup is lower if you do it. | 17:21.44 |
| | but I'll have a go later if you want. | 17:21.53 |
| | (but it'll be a lot later) | 17:22.21 |
| ray_laptop | BTW, if you use the file from bug 692158, I recommend trimming it down. BTW, it _does_ use patterns, but I never was patient enough to let it run to completion in clist mode | 17:22.28 |
| | Robin_Watts: is there a bug open already for it ? | 17:22.41 |
| Robin_Watts | no, this is just something I noticed in passing. | 17:22.54 |
| ray_laptop | Robin_Watts: OK. I'll open a bug and take assignment | 17:23.09 |
| | sort of surprised that it didn't cause a clang or compiler warning | 17:23.51 |
| ray_laptop | hasn't checked, however | 17:24.05 |
| | Robin_Watts: OK, I opened bug 692623 assigned it to me and tagged it with cust 870 since they have had other LARGE clist files along with the one from 692158 | 17:30.19 |
| | Robin_Watts: thanks for noticing | 17:30.30 |
| Robin_Watts | no worries. | 17:30.39 |
| ray_laptop | off to get coffee. bbiab. | 17:30.53 |
| Robin_Watts | walks dogs to shop, then may have a weekend... | 17:31.05 |
| tkamppeter | I have found a new bug, http://bugs.ghostscript.com/show_bug.cgi?id=692624, probably most interesting to alexcher, as it is a problem with Cyrillic. | 17:59.20 |
| ray_laptop | hmm... no mvrhel | 18:48.43 |
| vtorri | tor8: hey | 18:53.09 |
| | tor8: got a minute ? | 18:53.13 |
| ray_laptop | henrys: when you get around to answering Arnold's question, we should tell him that we handle PDF up through 1.7, with the Adobe PDF 1.8 supplement that corresponds to some features in ISO 32000, and that we can remder the various 'flavors' PDF/A PDF/B linearized, etc. | 19:00.17 |
| | henrys: actually it was Wolfgang that asked (he cc'ed Arnold) | 19:01.01 |
| henrys | ray_laptop:I think he was statisfied with what I gave him, he wanted to know if he could report a bug for an older version. I think that should part of teh documentation no? | 19:03.56 |
| | By the last sentence mean: I think alexcher or you should give a detailed explanation as to what we support so we can simply point folks to it instead of improvising something (as I did). | 19:07.43 |
| | and why the heck aren't we getting compiler warnings on this clist int/long business? | 19:08.45 |
| ray_laptop | henrys: I had that question as well (about no warnings). At least the call to io_procs->fseek should generate a warning if it is returning an int64 into an int. I checked the gxclio.h and the prototype is OK. | 20:05.08 |
| | making good progress on Gemma's issues. | 20:06.03 |
| | lunch break now... | 20:06.13 |
| vtorri | when cmapdump is launched during the build of mupdf, there is a .h in the commande line | 20:06.36 |
| | cmapdump ***/file.h *** | 20:06.44 |
| | is that file generated by cmapdump, or generated before ? | 20:07.02 |
| tor8 | vtorri: that's the output file | 20:12.32 |
| vtorri | ok | 20:20.19 |
| | so generated | 20:20.22 |
| | and used later ? | 20:20.26 |
| | (i suppose...) | 20:20.34 |
| | i've not grepped | 20:20.39 |
| pipitas | ab | 22:08.06 |
| | I have a question regarding Ghostscript's way to embed Type1 fonts.... | 22:44.18 |
| | This command creates a PDF which has Courier NOT embedded, naming the font type as "Type1": | 22:44.36 |
| | : gs -o courier-noembed.pdf -sDEVICE=pdfwrite -c "/Courier findfont 32 scalefont setfont 100 600 moveto (Courier) show showpage" | 22:44.36 |
| | The next command creates a PDF which has Courier embedded, but now naming the font type as "Type1C": | 22:44.56 |
| | : gs -o courier-noembed.pdf -sDEVICE=pdfwrite -c "/Courier findfont 32 scalefont setfont 100 600 moveto (Courier) show showpage" | 22:44.56 |
| | Question: is there any way to force GS to use Type1 (instead of Type1C) when embedding a Type1 font? | 22:45.12 |
| | Thanks in advance for any hints. | 22:46.58 |
| | Note, I'm on an unstable internet connection right now. But I'll check back in the logs should anyone answer my question while I'm away... | 22:47.26 |
| mvrhel2 | pipitas: you may need to ask this on monday Europe time. most of the font guys are gone for the weekend | 22:47.29 |
| pipitas | mvrhel2: Thx, will do so. I assume I should direct my question to kens if possible? | 22:48.27 |
| mvrhel2 | yes | 22:48.37 |
| pipitas | I made a mistake with my 2nd commandline above. Should have been: | 22:51.20 |
| | : gs -o courier-embed.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -c "/Courier findfont 32 scalefont setfont 100 600 moveto (Courier) show showpage" | 22:51.22 |
| | Forward 1 day (to 2011/10/22)>>> | |
IRC Logs