| | <<<Back 1 day (to 2015/11/10) | 20151111 |
| tor8 | Robin_Watts: thinking about the naming, maybe we should rename the fz_store to fz_cache? | 09:54.34 |
| | and that should free up the 'store' name for tracking resources on write | 09:54.53 |
| | or maybe that's just overkill. | 09:54.58 |
| kens | tor8 Robin_Watts does MuPDF enforce any restictions at all on the length of name objects in PDF ? | 10:16.56 |
| Robin_Watts | 2gig, IIRC :) | 10:19.10 |
| kens | :-( | 10:19.16 |
| | Robin_Watts : ping | 14:08.13 |
| Robin_Watts | pong | 14:08.40 |
| henrys | kens, Robin_Watts: scoundrels! | 14:16.11 |
| kens | You can buy me a Mac if you like, but I only use it once a year or less | 14:16.37 |
| Robin_Watts | I have no idea what you're talking about. | 14:16.47 |
| henrys | I updated sabrinas computer to el capitan and it was completely bricked, until I restored the original RAM modules. Glad I didn't toss them. | 14:17.47 |
| Robin_Watts | Really? | 14:20.06 |
| henrys | Robin_Watts: yeah wacko I tried everything then started googling and that was it. | 14:22.06 |
| Robin_Watts | Were the non apple ones a different spec? | 14:22.24 |
| henrys | and I did try just reseating the ram first just to see if that was resetting something. | 14:22.25 |
| tor8 | are you telling me el capitan checked the ram manufacturer and refused to run if they weren't white-listed? | 14:22.45 |
| Robin_Watts | That really smells like apple trying to enforce no-third party stuff. | 14:22.58 |
| henrys | tor8: I don't know that for sure | 14:23.01 |
| Robin_Watts | Which means I am NOT going to update my Macbook. | 14:23.10 |
| tor8 | either way, makes me happy I jumped ship long ago... | 14:23.14 |
| Robin_Watts | Officially it tops out at 4Gig, and I have 8Gig in there. | 14:23.22 |
| | http://apple.stackexchange.com/questions/209439/memory-problem-after-upgrade-to-el-capitan ? | 14:26.35 |
| henrys | I was able to put the new ram modules back after el capitan started, the computer is worthless with the 2 gig setup it had, (old mac book) | 14:26.42 |
| Robin_Watts | henrys: yeah, that's a showstopper for upgrades. | 14:28.35 |
| | henrys: You could buy new memory from crucial, who guarantee it? | 14:29.00 |
| henrys | I bought it refurbished and it's worked fine otherwise, but I don't know if it is the original ram. | 14:29.34 |
| | I wonder how many years we have left of changing anything in a computer anyway | 14:30.51 |
| Robin_Watts | henrys: I'd be tempted to look at how much 8Gig of RAM from crucial costs. | 14:31.06 |
| | I got 8Gig for my macbook a while ago, and it was less than $100 IIRC, and it's meant the machine is still usable. | 14:31.40 |
| | And if it doesn't work, send it back. | 14:31.46 |
| henrys | Robin_Watts: everything works now, I put the ram upgrade back once el capitan started. | 14:32.20 |
| Robin_Watts | henrys: Changing anything in an apple? Those days have gone already. It's why my new machine ain't an apple. | 14:32.24 |
| | Oh, so it was just during the upgrade? | 14:32.31 |
| henrys | Robin_Watts: yes | 14:32.48 |
| | looking at the new surface pro looks to me like MS is headed in the same direction, you may guys may be using linux ;-) | 14:34.17 |
| kens | Only if MS stops shipping Windows. The problem with Apple is that you can't buy the OS without buying Apple hardware | 14:35.08 |
| | Techncally anyway :-) | 14:35.33 |
| henrys | kens: indeed that is a huge difference. I'm really impressed with what MS has done actually, I think that a better buy than an ipad | 14:39.36 |
| kens | I quite like hte concept, but I haven't help one so I'm not convinvced | 14:40.06 |
| | s/help/held/ | 14:40.16 |
| | But Apple has hte ecosystem, MS doesn't | 14:40.46 |
| tor8 | Robin_Watts: where did you put the apks you built yesterday? | 14:42.46 |
| henrys | pretty soon we'll have smart office running on the surface pro and the ecosystem issue will be solved ;-) | 14:45.46 |
| Robin_Watts | tor8: in my public_html | 15:10.24 |
| tor8 | MuPDF-8[0123].apk? | 15:12.38 |
| Robin_Watts | tor8: yeah. | 15:18.33 |
| tor8 | Robin_Watts: how do I tell which one is which? | 15:25.26 |
| Robin_Watts | 80 is arm, 81 is armv7a , 82 is x86, 83 is mips. | 15:25.58 |
| | Same order as always. It's in the twiki somewhere. | 15:26.08 |
| tor8 | got it | 15:26.31 |
| sebras | Robin_Watts: is this google's numbering scheme or yours? | 15:27.12 |
| tor8 | sebras: http://twiki.ghostscript.com/do/view/MuPDF/AndroidReleases | 15:27.33 |
| Robin_Watts | sebras: When you upload apks to google play, it will serve the highest numbered apk that will work on your device. | 15:27.51 |
| | armv7a devices can run arm exes, so we want the armv7a one to have a higher number so those devices get the more optimised one. | 15:28.45 |
| sebras | Robin_Watts: aha, that makes sense. | 15:28.57 |
| Robin_Watts | Some x86 devices can run arm stuff via emulation, hence x86 > arms. | 15:29.06 |
| thedatas | maybe someone can shed some light on an issue i'm having.. i've tried epstopdf and ps2pdf to convert our eps files to pdfs. final pdf filesize is an issue.. i've tried passing --res= option to epstopdf but doesn't seem to change the filesize at all. if i use ps2pdf and don't pass any parameters, i get a much nicer final file size but with the white border. as soon as I pass -dPDFSETTINGS=/prepress -dEPSCrop to ps2pdf, the filesize increases again from | 15:34.16 |
| | any ideas what I'm doing wrong here? | 15:34.23 |
| kens | Not without sereing an example, no. Also don't use eps2pdf, just use Ghostscript | 15:35.18 |
| | Since pdfwrite won't (generally) render anythign, changing the resolution of rendered objects won't have any effect (and the option is -r for Ghostscript) | 15:35.54 |
| | Ah epstopdf is a Perl script, nothing to do with us, so I have no idea what its doing. Again, just use Ghostscript | 15:36.36 |
| thedatas | ps2pdf -dPDFSETTINGS=/prepress -dEPSCrop 0000944078.eps 0000944078.pdf is the command im using for ps2pdf.. and yep, i also tried passing --gsopt=-r80 in epstopdf but didn't appear to do anything. | 15:36.56 |
| tor8 | Robin_Watts: the apks work on my phone. can you upload them to the app store, please? | 15:37.00 |
| kens | thedatas : Don't use scripts! | 15:37.10 |
| | Use Ghostscript directly. Don't use -dPDFSETTINGS because that sets a bazillion parameters, unless you know what you are doing, these may well be inappropriate. | 15:37.50 |
| | After that, I can't comment without seeing an example file. | 15:38.00 |
| | And it would help to know what version of Ghostscript you are using | 15:38.23 |
| thedatas | I'll dig into straight gs then.. gs version is 9.10 | 15:38.39 |
| kens | Tha'ts old, the current version is 9.18 | 15:38.50 |
| Robin_Watts | tor8: They are there in beta form already. I can push the button to make them public. | 15:39.05 |
| kens | 9.10 is 2 years old | 15:39.09 |
| thedatas | which is probably about the time this server was thrown together and gs just has never been updated.. not my server so i'm not updating it directly.. | 15:40.14 |
| kens | Well, if it doesn't happen with current code all we'll do is shrug and tell you to update. | 15:40.36 |
| Robin_Watts | tor8: Published. It will take a while to propogate. | 15:40.45 |
| tor8 | Robin_Watts: Let's pull the trigger. | 15:40.46 |
| | Robin_Watts: Thanks. | 15:40.51 |
| Robin_Watts | np. | 15:40.55 |
| thedatas | gs -sDEVICE=pdfwrite -dEPSCrop -r150 -o output.pdf input.eps works just fine, filesize ok.. sorry to bother. | 15:54.13 |
| kens | NP, can't really say why there was a problem before though, you could experiment if you like | 15:54.40 |
| | -r150 shouldn't have any effect generally | 15:55.07 |
| thedatas | there's no telling what other additional parameters ps2pdf or epstopdf are passing to gs.. this is my first experience with gs anyways so, complete noob | 15:56.07 |
| kens | ps2pdf doesn't add much, epstopdf, I simply don't know..... | 15:56.37 |
| thedatas | np, thanks again.. | 15:57.33 |
| kens | Robin_Watts : I'm afraid that didn't work :-( | 16:23.00 |
| | heading off ro now, night all | 17:08.13 |
| henrys | mvrhel_laptop: do you remember why the languages (not ps/pdf) need to call gsicc_init_iccmamager()? I'm cleaning some stuff up and like to be rid of that dependency. It looks like ps and pdf let the graphics library handle that init call. | 17:14.06 |
| mvrhel_laptop | henrys: not off the top of my head. let me look | 17:14.41 |
| henrys | mvrhel_laptop: even the way the library does it looks a bit odd actually. Sometime it calls it when a device is set and other times upon installing a color space. Shouldn't it just be init'd along with one of the library init functions? | 17:17.33 |
| | I think chrisl and I talked about this a while back... | 17:18.17 |
| | mvrhel_laptop: he may have some thoughts about how best to do it. | 17:19.01 |
| chrisl | Hmm, I can't remember..... I'd have to look at the code again | 17:19.23 |
| | IIRC, the languages call it to set up and icc manager in the graphics state.... is that correct? | 17:20.01 |
| mvrhel_laptop | yes the manager resides in the graphic state | 17:23.52 |
| henrys | chrisl: I didn't quite parse that. PCL/PXL/XPS allocate a gs_state then immediately calls gsicc_init_iccmanager(pgs) so I'd like that to do be done once in the graphics library. | 17:23.54 |
| | chrisl: I see what you meant nvm. | 17:25.05 |
| chrisl | oh, sorry, should have been "...to set up an icc manager in the graphics state", and where I was going was, that should be done as part of creating the initial graphics state..... | 17:25.31 |
| mvrhel_laptop | yes. I think gs_state_alloc may be a good solution | 17:26.21 |
| chrisl | Hmm, do we want a new icc manager with *every* graphics state? | 17:26.48 |
| mvrhel_laptop | oh no | 17:26.57 |
| | sorry | 17:27.15 |
| | I was looking where gs_state_alloc was called | 17:28.11 |
| henrys | so library context? | 17:28.21 |
| chrisl | Under what circumstances would we expect more than one icc manager to exist? | 17:29.45 |
| mvrhel_laptop | never | 17:29.52 |
| | well not true | 17:30.01 |
| chrisl | Even multi-threaded rendering? | 17:30.05 |
| mvrhel_laptop | thinking | 17:30.23 |
| | there is no manager used by the clist rendering threads | 17:30.41 |
| | the icc profiles are stored in the clist | 17:30.48 |
| chrisl | So, it's only in the graphics state, not the imager state | 17:31.11 |
| mvrhel_laptop | so yes, there is only one icc manager | 17:31.19 |
| henrys | mvrhel_laptop: what was the motivation for putting a call in gs_set_device_no_erase()? | 17:31.50 |
| Robin_Watts | Is it one icc manager per interpreter instance? Or one icc manager per lib instance? | 17:32.55 |
| | If it's per lib instance, why doesn't it live in the lib_ctx ? | 17:33.08 |
| henrys | Robin_Watts: that's what I asked sorry if it wasn't clear | 17:33.57 |
| Robin_Watts | henrys: I could see you asking, I couldn't see it being answered :) | 17:34.31 |
| chrisl | I assume the icc manager doesn't have to worry about save/restore and gsave/grestore | 17:34.41 |
| mvrhel_laptop | henrys: I don;t remember. Let me look at blame | 17:35.10 |
| chrisl | Aren't interpreter instances and lib_ctx instances intimately tied together? | 17:35.41 |
| henrys | mvrhel_laptop: I did that but it wasn't terribly enlightening | 17:35.42 |
| mvrhel_laptop | good grief I guess not | 17:37.42 |
| | I do remember there being some weird situation where the file i/o was not set up and we could not read the default icc profiles | 17:38.32 |
| chrisl | It's probably down to some subtlety of Ghostscript's initialization | 17:39.56 |
| mvrhel_laptop | This had something to do with it | 17:40.10 |
| | Move io_device_table from being a global static in gsiodev.c into | 17:40.15 |
| | the library context. In order to retrieve it we need to update | 17:40.16 |
| | lots of functions to take a gs_memory_t * as well. | 17:40.18 |
| | 6abf140db860f2f4e1fea5b413558bbf47c02697 | 17:40.24 |
| | oh never mind | 17:41.29 |
| | my brain is not working this morning | 17:41.35 |
| | henrys: I do remember there being some odd case though there the io table was not set up and we could not init the icc manager | 17:42.42 |
| | s/there/where/ | 17:42.49 |
| | and that prompted adding the code in gs_set_device_no_erase | 17:43.07 |
| henrys | chrisl, Robin_Watts : one lib context per instance: iapi.c:101 if I'm readinng that correctly. But the languages say PCL/XPS/PXL in today's build share a context if they are integrated together | 17:43.13 |
| mvrhel_laptop | I guess we can pull it out and see if anything fails in the cluster | 17:43.53 |
| Robin_Watts | dusts off the gs source. | 17:44.22 |
| chrisl | henrys: yes, for Ghostscript at least, a few things (like the name table) are stored in the lib context, so it can't be shared between interpreter instances - I rather assume the rule would apply to other languages....... | 17:44.38 |
| henrys | chrisl: the comment in iapi.c explicitly says only stdio is shared. But I've found plenty of strange comments during my recent explorations, I'm wary of all of them. | 17:45.54 |
| Robin_Watts | When an app loads the gs dll, it then requests a new instance. In non GS_THREADSAFE builds we can only offer 1 instance per app. | 17:47.38 |
| chrisl | henrys: well, that is downright wrong: the gs_lib_ctx contains "gs_name_table", and a comment: "hack this is the ps interpreters name table doesn't belong here" | 17:47.47 |
| Robin_Watts | In GS_THREADSAFE builds we offer multiple instances per app. | 17:47.53 |
| | However many instances we offer, we will only create 1 lib_ctx. | 17:48.14 |
| chrisl | Oh that won't work....... | 17:48.26 |
| Robin_Watts | Ah, so the clearest way of expressing the situation is probably, "1 lib_ctx per process, shared between the instances in that process". | 17:49.00 |
| | chrisl: Why won't that work ? | 17:49.06 |
| chrisl | Robin_Watts: we can't share the Postscript name table between interpreter instances | 17:49.23 |
| Robin_Watts | chrisl: Right. So that ought to be hoiked out. | 17:49.36 |
| chrisl | Also, there's probably a few things in the lib_ctx that aren't accessed in a thread safe way | 17:51.01 |
| henrys | I don't see how you can share most of lib ctx | 17:51.10 |
| chrisl | font_dir, CPSI_mode, profiledir, cms_context, fapi_servers and default_device_list | 17:51.51 |
| | Oh, and screen_accurate_screens, screen_min_screen_levels and real_time_0 can't be shared between interpreter instances | 17:52.48 |
| | And probably not top_of_system | 17:53.18 |
| Robin_Watts | Ok, so until that lot is fixed, we can't rely on GS_THREADSAFE working. | 17:53.18 |
| chrisl | Given that the lib_ctx clearly can't be safely shared, I'd say GS_THREADSAFE is wrong, and shouldn't share the lib_ctx | 17:54.24 |
| Robin_Watts | chrisl: Well, the fix for that, is to remove the #ifndef GS_THREADSAFE around the check for multiple instantiation in iapi.c | 17:55.10 |
| chrisl | But then that means we can't share the gs_memory_t which isn't ideal :-( | 17:55.23 |
| Robin_Watts | chrisl: Yeah. | 17:55.45 |
| | MuPDF copes with this. | 17:55.51 |
| | Every new thread 'clones' the context. | 17:55.58 |
| | Which makes a new lib_ctx with the shared things shared (reference counted), and the unshareable things not shared. | 17:56.28 |
| henrys | isn't the only thing we really need to be shared I/O? | 17:56.39 |
| Robin_Watts | I would have thought that shared IO was exactly what we didn't want :) | 17:57.09 |
| | If I'm running multiple instances in a single process, I want to be able to pipe the io for those processes out independently. | 17:57.37 |
| | If we say that we want every instance to have it's own lib_ctx, that might not be a huge change. | 17:58.35 |
| chrisl | I'd have thought all we'd want to share was the memory allocator, but as I say, that's not feasible | 17:59.03 |
| Robin_Watts | At the moment we get the lib_ctx from the gx_memory_t's. hence the gx_memory_t's point to the lib_ctx. Sharing a gx_memory_t would mean sharing the lib_ctx. | 17:59.46 |
| | UNLESS when we create the lib_ctx, we wrap the gx_memory_t's maybe? | 18:00.07 |
| | So that there can be an underlying allocator that is shared, but the instances never see that one directly. | 18:00.33 |
| chrisl | We'd have to have a "special" parent allocator, managed individually | 18:01.09 |
| | TBH, we sort of do that kind of wrapping implicitly already | 18:02.27 |
| | However, back to the original point of this: I think having the icc manager in the lib_ctx makes sense | 18:05.26 |
| henrys | chrisl: I'd be very happy if we could just solve that simpler problem for now. | 18:06.22 |
| | chrisl, mvrhel_laptop I can play with it in the work I'm doing if you want or you two can draw straws. Let me know what you want to do. | 18:06.58 |
| mvrhel_laptop | henrys: please play with it | 18:07.28 |
| | I recall having a lot of issues with that initialization | 18:07.47 |
| chrisl | henrys: I'm fine with that - just let me know if you want me to take it instead | 18:08.16 |
| mvrhel_laptop | some weird things especially with the CET PS test files | 18:08.22 |
| chrisl | mvrhel_laptop: We should be okay creating the ICC manager very early on, even if we don't actually instantiate any profiles until later on | 18:09.20 |
| henrys | mvrhel_laptop, chrisl : sure I'll let you know what I find, hopefully it won't be ugly | 18:12.51 |
| chrisl | henrys: I think the main thing is, if you start hitting the kind of issues mvrhel_laptop stumbled across with the PS test files, punt it to me - I'm probably more familiar with that stuff, and in a better time zone to badger kens about it | 18:14.15 |
| henrys | we'll ask ray to read the logs too, he may know something off the top of head | 18:14.20 |
| | chrisl: yup will do | 18:14.46 |
| Husky_ | Hello, Thank you for the new MUPDF 1.8 release. Will there be a 64bit windows binary precompiled for download as well like it was for the 1.7 release | 18:15.47 |
| Robin_Watts | Husky_: Yes. | 18:19.49 |
| Husky_ | Thank you | 18:20.05 |
| Robin_Watts | tor8 should be handling that, but he's gone for the day. | 18:21.06 |
| henrys | mvrhel_laptop: should the profile cache be moved to lib ctx as well? | 18:26.35 |
| | and link_cache? | 18:27.05 |
| | my view is never put anything in the graphics state unless you want to have your name called a lot. | 18:28.43 |
| mvrhel_laptop | sorry stepped out for a sec | 18:28.59 |
| | henrys: the link cache needs to be accessible during clist call back. will it be fine in lib ctx? Also each thread has its own link cache | 18:30.28 |
| | the profile cache is used during interpreter processing. | 18:30.58 |
| | I suppose it could go in lib ctx | 18:31.25 |
| henrys | mvrhel_laptop: so there must be other state for each clist thread where that link cache belongs? | 18:33.52 |
| | mvrhel_laptop: I'll talk to ray about that one. | 18:34.32 |
| mvrhel_laptop | it is in the imager state | 18:35.06 |
| | oh no | 18:36.01 |
| | its in the clist device | 18:36.06 |
| | oh and then the imager state gets a pointer to it | 18:36.56 |
| | and increments a ref count | 18:37.04 |
| | henrys: So moving the icc manager to the lib ctx | 18:37.50 |
| | if I have a graphic state or an imager state that is a graphic state is the manager accessible in the same way it is now. I am not real familiar with how the lib ctx is set up | 18:39.15 |
| henrys | mvrhel_laptop: yes but there is 1 lib ctx, is there more than one gs imager state per thread for the clist. ie. can multiple clients read all this stuff without conflict? | 18:40.48 |
| | mvrhel_laptop: yes but there is 1 lib ctx, is there more than one gs imager state per thread for the clist? ie. can multiple clients read all this stuff without conflict? | 18:41.02 |
| mvrhel_laptop | yes each time clist_playback_band is called a new imager state is created | 18:42.10 |
| | the link cache can not be shared among the threads since the CMM is not necc. thread safe | 18:42.42 |
| | henrys: I have to head out now. need to go to my uncles for lunch. kids are out of school todah | 18:43.04 |
| | today | 18:43.06 |
| henrys | oh right veterans day, why am I here? | 18:46.30 |
| kens | Robin_Watts : I downloaded that file, I'll try and find time to give it a whirl later | 19:06.43 |
| RandBrittain | Good afternoon! | 19:13.39 |
| | I had a question about muPDF-based readers for Android. I wondered if anybody had any they would recommend other than EBookDroid? | 19:14.06 |
| | I've never quite found a reader for Android that met all my needs the way GoodReader did for iOS. muPDF has admirable performance, but I need a few more features like being able to lock zoom to screen width. | 19:14.54 |
| sebras | RandBrittain: what are the other features you are missing? if you list them (or even better, write an enhancement bug over at http://bugs.ghostscript.com/enter_bug.cgi?product=MuPDF) then the mupdf devs may listen and implement it in the mupdf app. :) | 19:27.51 |
| RandBrittain | Ah, might they? I had understood that mupdf was kind of intentionally minimalist. | 19:34.20 |
| | I could do that. | 19:34.22 |
| | Forward 1 day (to 2015/11/12)>>> | |
IRC Logs