| | <<<Back 1 day (to 2015/04/12) | 20150413 |
| kens | Good grief, the gx_device_finalze routine calls the device finalize before it calls closedevice...... | 09:20.27 |
| chrisl | That sounds counter intuitive..... | 09:22.52 |
| kens | It certainly tripped me up | 09:23.02 |
| | Because I'm unsubclassing in finalize (the 'final' part made me think it was the last thing to hjappen) and then my device's close routine gets called..... | 09:23.32 |
| chrisl | So, in this case "finalize" isn't final.... of course, there could also be an implicit finalize method from the memory manager, too | 09:24.11 |
| kens | It is essentially coming form the memory manager, in response to a restore (the end of job restore). Its just annoying nomenclature that the 'finalize' routine is not final. | 09:24.50 |
| chrisl | I mean you could also define the device struct descriptor with a finalize method, called before the memory is freed | 09:25.56 |
| kens | I thnk its the same method in each case. | 09:26.23 |
| | At least in tat case the finalize would actually be final. | 09:26.48 |
| chrisl | The device finalize is stored explicitly in the device structure | 09:26.58 |
| kens | Ah I se what you mean | 09:27.16 |
| chrisl | I rather feel the finalize method in the device should be deprecated (and subsequently removed). | 09:29.49 |
| kens | I'm not at all certain that any devices actually use it..... | 09:30.09 |
| chrisl | In which case..... | 09:30.29 |
| kens | Yeah but I'd have to go check, it would take a while. | 09:30.50 |
| chrisl | I'll add it to my list of things to discuss in June | 09:31.31 |
| kens | Ah you have a list ? Excellent :-) | 09:31.39 |
| | At least now I've stopped the crash by rejigging the order I do things. | 09:32.01 |
| | io devices seem to use it. | 09:33.12 |
| | pattern accumulator device uses it too | 09:34.47 |
| | In a horrible clist way | 09:35.04 |
| chrisl | In which case, I assume it's not being called immediately before the device is freed? | 09:35.25 |
| Robin_Watts | tor8: Hi. | 09:35.31 |
| kens | No it isn't | 09:35.35 |
| tor8 | Robin_Watts: morning | 09:35.42 |
| Robin_Watts | We have 2 problems with the android build of the rc, I believe. | 09:35.46 |
| chrisl | So, it's not a finalize method, then - what nonsense :-( | 09:35.53 |
| tor8 | okay... | 09:35.56 |
| Robin_Watts | Load an image, tap the screen, boom. | 09:35.56 |
| | and I'm not sure epub is hooked up. | 09:36.06 |
| kens | Actually, I can't tell from inspection how its beign used. Its decrementing a gx_device_clist_writer so it may be just before the pattern accumulator is freed. | 09:36.32 |
| chrisl | If that's the case, then it should use the "proper" finalize in the struct descriptor | 09:37.24 |
| kens | The eprnfs.c file contains an eprn_finalize routine that doesn't seem to be a finalize routine | 09:37.33 |
| | Weird comment in gdevcmykog.c: | 09:38.24 |
| | "/* Even though cmykog_device_finalize is the same as gx_device_finalize, */ | 09:38.35 |
| | "* we need to implement it separately because st_composite_final */ | 09:38.35 |
| | "* declares all 3 procedures as private. */ | 09:38.35 |
| | Seems a *lot* of devices say something like that | 09:39.30 |
| chrisl | Possibly should be using gs_public_st_composite_final | 09:39.52 |
| kens | And although the tiffsep device says that, it isn't true, it actually does do some other stuff | 09:39.56 |
| | chrisl yeah I'd say that was correct. | 09:40.10 |
| | SO it looks like tiffsep at least does do stuff with the finalize method. | 09:40.35 |
| pipitas | Short question about GXPS: is it still maintained? | 09:41.48 |
| chrisl | Short answer: yes | 09:41.59 |
| kens | But not much used. | 09:42.16 |
| pipitas | chrisl: but probably not top priority? | 09:42.21 |
| chrisl | pipitas: no, not top priority - nobody really cares...... | 09:42.52 |
| kens | Nobody really uses XPS | 09:43.05 |
| | Although bizarrely there is a SO queston about producign 'searchable' PDF form an XPS file. | 09:43.29 |
| pipitas | I've looked at this StackOverflow question: http://stackoverflow.com/questions/29589683/ and concluded that there is a bug in its ToUnicode mapping of fonts | 09:43.42 |
| kens | Oh he's actually supplied files now. | 09:44.03 |
| pipitas | kens: Oh, *I* use it from time to time :) [But then, I'm a "nobody" :-) ] | 09:44.23 |
| kens | I bet even you don't use it much. I can't recall the last tmie we had a bug report on it | 09:44.48 |
| pipitas | kens: Feel free to tell me off if I'm wrong in my analysis (I'm always willing to learn) | 09:45.06 |
| kens | IDK I haven't looked, for some reason SO didn't tell me he'd added the files | 09:45.22 |
| chrisl | I thought there were known to be issues with the way gxps passes glyph information into the graphics library? | 09:45.22 |
| pipitas | Oh, there is even a bug already addressing the ToUnicode stuff: #693945 | 09:45.54 |
| kens | Ah well, there you are then. You can get brownie points by directing the poster to that bug report | 09:46.33 |
| | I see I even attached a minimal patch | 09:47.53 |
| chrisl | heads out - back shortly...... | 09:48.36 |
| pipitas | kens: in the process of acquiring your brownie points :) | 09:58.07 |
| kens | Consider it payment for editing my posts | 10:02.55 |
| pipitas | KenS: If you mind me editing your SO posts (mainly to improve formatting), do tell. I'm sorry if you feel insulted by this, and will stop doing it. (I also most of the time upvote your postsâ¦) | 11:07.36 |
| kens | pipitas, I didn't mean it that way. Like I said, payment for improving the posts | 11:10.37 |
| | Because I'm lazy with formatting | 11:11.02 |
| | M network is not happy today, I keep falling off. | 11:11.57 |
| tor8 | chrisl: which commit did you make the jbig2dec 0.12 release from? | 12:02.24 |
| | chrisl: I think we're missing a git tag for it | 12:02.33 |
| Robin_Watts | tor8: I'm buried in SOT stuff at the moment. Any chance you can look into those 2 problems? | 12:03.01 |
| chrisl | tor8: erm, that's possible..... | 12:03.50 |
| tor8 | Robin_Watts: I'm still waiting for my android tablet to charge... | 12:04.21 |
| | Robin_Watts: I will take a look and see what I can do | 12:04.38 |
| Robin_Watts | Ta. | 12:05.08 |
| tor8 | chrisl: or should I just tag the oct 31 commit? | 12:05.18 |
| chrisl | tor8: oh, I meant to ask you and forgot.... I didn't know how to apply a tag, as I don't think I can push to the jbig2dec repo.... | 12:05.45 |
| | tor8: yeh, f2af865a would have been the one the release came from, so you can tag that | 12:06.13 |
| tor8 | ah, right. I think I've set it to read-only except for me (so we don't get any accidents) | 12:06.15 |
| chrisl | Is there a way to make just master read-only? | 12:07.11 |
| tor8 | chrisl: not that I know of | 12:08.32 |
| | the crontab job runs git-subtree in /home/tor/src/jbig2dec and then does a git fetch to pull that into the /home/git/jbig2dec.git | 12:09.05 |
| chrisl | tor8: okay, how about if we make a "jbig2dec-git" user on casper? And only that user can commit? | 12:09.24 |
| tor8 | chrisl: or a git-admin group? | 12:09.49 |
| chrisl | tor8: that would work, I suppose. | 12:11.01 |
| tor8 | or just a jbig2dec-git group with you and me in it | 12:11.11 |
| chrisl | That's a better idea, yes, that'll work | 12:11.49 |
| tor8 | Robin_Watts: poop. google's not making life easy... | 12:51.35 |
| | android-ndk-r10d-linux-x86_64.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found | 12:51.40 |
| pipitas | KenS: So I take it you don't feel uneasy seeing your SO posts spell-checked and pimped by me on occasions? | 13:21.48 |
| rayjj | morning, all | 14:13.39 |
| kens | Mornign rayjj | 14:13.46 |
| rayjj | oops. Did chrisl really leave ? | 14:14.00 |
| kens | Yeah seems you scared him off. | 14:14.11 |
| rayjj | I was going to ask him if he looked at parse and render times for the cust 532 timings he collected | 14:14.40 |
| kens | Or, given the way people are droppig off the channel today, possibly we have a limit of users and you just pushed us over it, meaining someone has to fall off | 14:14.42 |
| rayjj | I've been on for about 35 minutes, so I didn't push him off AFAICT from my chatzilla that shows join/leave noise | 14:15.47 |
| kens | was joking.... | 14:16.04 |
| rayjj | kens: Oh, sorry | 14:16.15 |
| | kens: more likely he did leave because he didn't want to be queried about cust 532 :-) | 14:16.47 |
| kens | That I would understand :-D | 14:17.13 |
| rayjj | hi, chrisl: I was going to ask you if you ooked at parse and render times for the cust 532 timings he collected | 14:26.49 |
| chrisl | rayjj: I timed the entire process | 14:29.25 |
| rayjj | chrisl: so you didn't capture the -Z: output (with 871 it goes into /temp/z.out, with 906 it's on the console window) | 14:30.27 |
| chrisl | rayjj: no, I did the timings at the windows command prompt | 14:31.02 |
| rayjj | chrisl: that's what I use since it skips a lot of their start up/shut down time which is variable | 14:31.11 |
| chrisl | rayjj: I was getting a lot variations running from the VS gui, so I wanted to run direct. I could redo the timings with -Z: but I doubt it will change my conclusions | 14:32.46 |
| kens | I admit I didn't read the thread too closely, but I was under the impression that Chris' timings on the two simulators didn't really show that great a difference between 8.71 and 9.06 anyway | 14:32.47 |
| rayjj | chrisl: but at this point, we are still waiting to hear about your suggested experiment (using the 871 FAPI code on 906) on the target | 14:33.18 |
| chrisl | rayjj: TBH, there should be not practical difference in using the 8.71 FAPI code on 9.06, with the patch I gave them on Friday. | 14:34.14 |
| | rayjj: baring in mind that what they are using on 8.71 is really the 9.0x FAPI code anyway....... | 14:35.58 |
| rayjj | chrisl: my timings were without your changes, but _did_ have the changes/enhancements I'd given them for 906 to speed up 1-bit rendering. Only after looking at what they sent you did I realize that the 906 sim they poster for you did not have those changes | 14:36.07 |
| | chrisl: right, since the fapiufst stuff you had given them along the way was incorporated even in 871 | 14:37.04 |
| kens | Chris's timings (over multiple runs) indicated a difference for page 4 between 8.71 and 9.06 of 0.7 seconds, out of an average time of 14.97 seconds,so less than 5%, whereas page 5 was faster with 9.06. | 14:37.56 |
| chrisl | rayjj: what they had right from the first use of UFST was the later FAPI code, ported back to 8.71 - they *never* used the FAPI code that shipped with 8.71, since it didn't work | 14:38.06 |
| kens | Because that was hte FAPI code before Chris and I worked it over :-) | 14:38.44 |
| chrisl | rayjj: my intention is to leave this with Len now..... I'm fairly well convinced that there isn't an issue in the FAPI code, and I don't want to waste our/my time stabbing around in th dark just because they can't do proper profiling :-( | 14:42.12 |
| | On the other hand, if you feel there might be useful data in it, I'll rerun my timings with the -Z: output instead of the end-to-end execution times | 14:44.31 |
| rayjj | chrisl: no, don't bother. I agree that we need to get timing from Len on the target | 14:58.42 |
| chrisl | Heading out..... | 15:01.04 |
| leot | hello to the entire ghostscript community | 16:14.55 |
| | curious regarding the new mupdf-1.7rc1 release I read the changelog and tested it... It works good and more curious I saw that now mupdf also supports epub... Trying it (e.g.: this epub is freely available under a CC license: http://www.wumingfoundation.com/italiano/Wu_Ming_Armata_dei_Sonnambuli.epub ) I get the following error when trying to open it: | 16:17.36 |
| | error: css syntax error: unexpected character (OEBPS/Styles/style001.css:6) | 16:17.41 |
| | mupdf: error: cannot open document | 16:17.44 |
| | (I'm on NetBSD-current and pkgsrc-current) | 16:18.06 |
| | the 6th line of style001.css contains that: «src: url(../Fonts/DejaVuSerif.ttf);» | 16:18.34 |
| Robin_Watts | leot: Hi. | 16:19.05 |
| | I suspect it's the krazy « character. | 16:19.34 |
| leot | the "«" and "»" are mine :) | 16:19.49 |
| Robin_Watts | It's really a question for tor8... tor8? | 16:19.51 |
| | oh, right. | 16:19.55 |
| leot | (for completeness this is the entire file: http://sprunge.us/eahO) | 16:20.41 |
| Robin_Watts | Ah. I suspect the problem is that we dislike being asked to fetch fonts from url's. | 16:22.08 |
| | Do you have the font locally? | 16:22.22 |
| leot | Robin_Watts: yes, the .epub contains it | 16:22.28 |
| | and the relative path is correct | 16:22.36 |
| Robin_Watts | ok. I wasn't involved in the epub stuff, so this is all guesswork on my part :) | 16:23.00 |
| leot | NP :) | 16:23.09 |
| Robin_Watts | What happens if you remove url(blah) and replace it with "blah" ? | 16:23.18 |
| leot | let's try! | 16:23.25 |
| | Robin_Watts: I can confirm that it works :) | 16:30.12 |
| Robin_Watts | excellent. Thanks. | 16:30.19 |
| leot | Robin_Watts: should i fill a bug report or will you take care of that? | 16:30.33 |
| Robin_Watts | If you could, I would be very grateful. | 16:30.43 |
| | I'm buried in other stuff. | 16:30.50 |
| leot | NP | 16:30.51 |
| | Robin_Watts: i'm filling the bug report... Can I mention you and maybe the IRC log? | 17:46.32 |
| Robin_Watts | leot: Please do. | 17:49.32 |
| leot | thank you :) | 17:49.40 |
| Robin_Watts | Please attach the file to the bug. | 17:50.09 |
| | It's always a pain when people give URLs of files, cos murphys law says that they will then get moved :) | 17:50.34 |
| leot | heh, ok... Wu Ming is a famous italian (group of) author and when they share their books usually the EPUB will be available forever... But in Murphy's laws probably there are not words like "forever". So I will attach it. :) | 17:52.48 |
| | done: http://bugs.ghostscript.com/show_bug.cgi?id=695922 | 18:00.39 |
| | thank you very much Robin_Watts | 18:01.01 |
| Robin_Watts | Looks great, thanks! | 18:01.08 |
| mvrhel_laptop | this wpf vertical scrolling business with rescaling is driving me crazy. basically the last thing holding up the beta | 19:13.57 |
| | as far as I am concerned | 19:14.03 |
| | marcosw: for the logs. did we ever hear back from the customer about bug 695845? | 19:14.42 |
| | bbiaw | 19:14.44 |
| pipitas | Robin_Watts: Are there any special targets to make in order to get the mupdf EPUB viewer built from current Git (on OSX Mavericks)? | 20:53.47 |
| jrgifford | howdy ghostscripters - does anyone know how to compile a portable binary? i need it to live in a path that will change depending on where the application is deployed (might be /opt, might be /home/user/app, who knows). | 21:31.56 |
| rayjj | jrgifford: first, which product ? gs or mupdf ? | 21:54.14 |
| | jrgifford: in general gs is "self contained" although on many distros, they build with shared libs (which we haven't convinced them to abandon), but gs _can_ easily be build without shared libs. The other files (fonts, cmaps, iccprofiles, etc.) are always built into gs by default, so there should not be any CWD or installation location dependency | 21:56.37 |
| jrgifford | rayjj: gs itself | 21:57.18 |
| | Ok. So if I build it myself from source, I should be able to move that directory around without any issues? | 21:57.46 |
| rayjj | jrgifford: as far a 'which' gs you pick up depends entirely on you $PATH variable and which one it finds first. To find out: which gs is your friend | 21:57.51 |
| | jrgifford: you need the files in the 'bin' directory only, AFAIK, just 'gs' | 21:58.53 |
| jrgifford | (I can't use the prebuilt binary, our auditing team doesn't like binaries of unknown origin being loaded into production.) | 21:58.59 |
| | rayjj: ok. I'll give that a shot. | 21:59.06 |
| | Thanks! | 21:59.08 |
| rayjj | jrgifford: in the interest of full disclosure, some libs are not dynamically linked (because they aren't supported or because they have known, documented, flaws -- security or otherwise). | 22:00.19 |
| | jrgifford: or because we are the "upstream" maintainer anyway, such as jbig2dec | 22:00.49 |
| | (although I understand that some distros even dynamically link that and are at least two revs "down" from out releases due to ?laziness?) | 22:01.43 |
| jrgifford | Fair enough | 22:02.46 |
| rayjj | jrgifford: the most contentious at the current time (AIUI) is openjpeg since we've sent important patches upstream and they seem to be slow to be incorporated in that project. ISTR, some of those were important. | 22:04.41 |
| | jrgifford: basically, if you build it with the 'autogen.sh' and your system police don't notice a static lib that is linked in, you're good to go. For specifics about the build, known dynamic lib problems that persist with distors, etc. contact "chrisl" here (he's at GMT +0,, so asleep now) | 22:07.03 |
| Robin_Watts | pipitas: No special targets. Building on macos for macos ? | 23:40.05 |
| | Forward 1 day (to 2015/04/14)>>> | |
IRC Logs