| | <<<Back 1 day (to 2014/12/18) | 20141219 |
| mvrhel_laptop | ok. now the wacky decode cases are working | 00:53.08 |
| | just need to check the case with cie color spaces and make sure that nothing odd is going on with DeviceN type images, then I am done | 00:53.31 |
| | bbiaw to check those | 00:54.29 |
| kens | Bugzilla ping-pong :-) | 09:50.38 |
| chrisl | TBH, I understand henrys's confusion the TEXT_DO_NONE thing is not really clear at all :-( | 09:55.01 |
| kens | Agreed, but that's what the comment says, and the PCL interpreter makes *no* provision for the text routines returning to the interpreter (not surprisingly). | 09:55.35 |
| | Anyway, back to Henry to decide whether he wants to implement the parameter retrieval, or the full-blown text routines. | 09:56.20 |
| chrisl | It's just, it's caught me out a few times because it still assumes the glyphs will be entered into the cache, even though you're not drawing them on the output..... | 09:56.42 |
| kens | I know, I htink its odd, and I suspect that its caught out people before, which is why that sort of thing happens.... | 09:57.13 |
| | But realistically, *I* can't fix this in pdfwrite. | 09:57.31 |
| chrisl | That's the display device memory use issue fixed..... | 10:00.10 |
| kens | Excellent! | 10:00.20 |
| | I wonder if I should mail the customer or leave it to Marcos..... | 10:01.03 |
| | I'll leave it to Marcos I think, I've had enough of support. | 10:01.28 |
| henrys | ah I missed the TEXT_DO_NONE comment ... thanks kens. Have to suffer through more dreaded parameter code in PCL. | 13:59.01 |
| kens | SOrry henrys, I can't see any way to 'fix' it, if you use TEXT_DO_NONE we end up dropping back to the interpreter without having processed the text, which the PCL interpreter doesn't expect, I think. | 13:59.52 |
| | In PostScript we do this to render unhandled font types to bitmap. | 14:00.25 |
| | henrys if you want to write the code as a utility routine to 'extract one parameter from a device' it might be useful, I seriously considered that. | 14:01.17 |
| | The major obstacle is that the 'special_op' code only works with devices that have been modified (ie the ones we support). For parameters like PreserveTrMode that's OK, because only newer devices will understand those params, but for more common parameters (eg MediaSize) an unsupported/customer device might not work properly | 14:03.05 |
| henrys | kens: my goal was not to have a device dependency at all... set the parameter if the device supports it ... | 14:03.39 |
| kens | Well its no worse than the 'high level device' dependency. I'm doubtful you can do it without any device dependency at all. | 14:04.29 |
| chrisl | Text rendering mode really should be supported in the graphics library...... | 14:05.27 |
| kens | doesn't disagree | 14:06.18 |
| henrys | chrisl: that would do it or a new flage TEXT_DO_INVISIBLE and set the textrendermode for device to support or ignore. | 14:06.58 |
| kens | But in practice I htink we would end up in the same situation I outlined in the bug report. Devices might still call gx_default_text_begin, and that would tehn push the nulldevice, which is where this all breaks down. | 14:07.17 |
| Robin_Watts | Helen has been talking to Sabrina about possible places to stay in Denver. | 14:35.56 |
| | Her eyes were particularly drawn to the $16800 a night place. | 14:36.14 |
| kens | O.O | 14:36.20 |
| | Almost aS MUCH AS GOING TO dAVOS | 14:36.34 |
| henrys | kens on another subject there is no other way to do this is pdf? I'm concerned it displays the text in apple preview I haven't looked at others. Granted Abobe gets it but preview has a pretty good share of pdf consumption. | 14:36.37 |
| kens | henrys, you can do 'white on white', yes but then your point about 'white on black, with transparency' would render visibly. | 14:37.07 |
| chrisl | henrys: report the bug to Apple...... | 14:37.23 |
| kens | Henrys, any way you look at this, this is not a secure approach | 14:37.45 |
| henrys | I don't think it's a bug is it? It's up to the device right? | 14:37.55 |
| kens | Haha | 14:38.01 |
| chrisl | No, it's a bug | 14:38.09 |
| | text rendering mode is *not* optional | 14:38.24 |
| kens | I agree with Apple, because its bitmapped text, so it is neither stroked nor filled, however Acrobat does not render the text. | 14:38.29 |
| Robin_Watts | In an ideal world, text rendering mode should really be something handled by the graphics library. | 14:39.01 |
| | That has implications for transparency though. | 14:39.16 |
| chrisl | kens: Obviously not all tr modes are applicable to all fonts..... | 14:39.17 |
| kens | Robin_Watts : that wouldn't help with Apple Preview | 14:39.20 |
| | chrisl section 5.2.5 in the PDFRM : | 14:40.01 |
| | Note: The text rendering mode has no effect on text displayed in a Type 3 font (see Section 5.5.4, Type 3 Fonts). | 14:40.02 |
| | Except that Acrobat *does* apply Tr 3 at least | 14:40.16 |
| norbertj | henrys: good morning . I think I found a memoryleak in gp_ntfs.c in gp_enumerate_files_close(), the pfen->pattern is not freed. | 14:40.20 |
| chrisl | kens: Yes, and we generally accept the implementation over the spec - despite my arguing otherwise at various times | 14:40.47 |
| kens | Indeed! | 14:41.00 |
| | I think Acrobat is wrong and Apple is correct, but there you go | 14:41.15 |
| norbertj | henrys: it is commented out, but should be executed before freeing pfen. It is not much (seems to be only used in enumerating over the standard 80 fontfiles). | 14:41.22 |
| | henrys: but stil. | 14:41.30 |
| | still | 14:41.36 |
| henrys | Robin_Watts: oh vail well yea... but she sent you a condo you can split with paul and linda for 400 a night US which is pretty good. | 14:41.52 |
| chrisl | kens: In fact, I think one of the cases where I argued the point was applying tr to type 3 fonts! | 14:42.03 |
| kens | :-) | 14:42.12 |
| Robin_Watts | henrys: Yes, she's sent lots of really useful stuff. | 14:42.44 |
| henrys | hi norbertj, a bug is always best. | 14:42.58 |
| kens | We're still not definite for Denver yet though I think ? | 14:43.10 |
| norbertj | henrys: ok will enter one. | 14:43.16 |
| Robin_Watts | We have not had it confirmed by official channels, no. | 14:43.22 |
| kens | Fingers crossed, the Alps are currently snowless (more or less) | 14:43.40 |
| henrys | kens: have you been to the rockies? | 14:45.23 |
| | to ski? | 14:45.27 |
| kens | Not to ski or for any other reason :-) | 14:45.37 |
| | We did consider riding there last year, but it turned out to be awkward | 14:45.54 |
| henrys | march should be good but if you wanted to absolutely sure you could ski you can plan on going to higher eleavations like A-Basin. | 14:47.45 |
| kens | Higher ? :-O | 14:48.16 |
| norbertj | henrys: bug 695752 submitted. This is my last hour at work (this year), so a Merry Christmas and Happy NewYear to you all. | 14:48.20 |
| kens | Merry Xmas Norbert | 14:48.29 |
| chrisl | norbertj: happy holidays! | 14:49.01 |
| Robin_Watts | Norbert: Have a nice break! | 14:52.11 |
| henrys | norbertj: take care norbertj happy holidays | 14:52.59 |
| | kens: coming from sea level may not be the best idea. some folks are okay with it: http://arapahoebasin.com/ABasin/media/resources/fun-facts.aspx | 14:53.40 |
| kens | Crumbs, 11,000..... | 14:54.13 |
| henrys | closes in *JUNE* | 14:54.19 |
| Robin_Watts | 11,000ft is for pussies :) | 14:54.23 |
| kens | will be interested to see Robin ski-ing at 11,000 feet :-) | 14:54.39 |
| henrys | vail is much lower, but this guarantees snow. | 14:55.04 |
| kens | I htink I'll wait until a bit closer to the time :-) | 14:55.18 |
| Robin_Watts | height is practically irrelevant to how well I'd ski, I fear :) | 14:55.20 |
| kens | Umm, maybe, though turning blue and passing out probably doesn't help | 14:55.40 |
| chrisl | Robin_Watts: could make a difference to how far you'd fall..... | 14:55.53 |
| Robin_Watts | bar stools are all the same height, right? | 14:56.13 |
| kens | From the looks of that site, you could fall a long way :-) | 14:56.14 |
| | Hmm what are the rules on drinking and ski-ing in the US ? | 14:56.43 |
| chrisl | Positively encouraged! | 14:57.04 |
| Robin_Watts | It's fine, but only if you're open carrying at the same time. | 14:57.04 |
| kens | is unconvinced, I've heard the US pistes are tightly patroilled | 14:57.31 |
| | Well, by lax European standards anyway | 14:57.43 |
| henrys | it really is a problem and drunk kid on a snowboard is really dangerous to everyone. | 14:57.46 |
| | s/and/a | 14:58.05 |
| kens | Actually you can say that without the 'drunk' too | 14:58.06 |
| Robin_Watts | seriously, sea level to 11000 will make you feel weird. We did sea level to 13000 when we went to La Paz, but immediately descended to 10000 or so to sleep. | 15:02.12 |
| | if you properly acclimatise no one fit enough to go skiing should really have problems at 11k though. | 15:02.51 |
| kens | Oh 11,00 was the bottom of that piste, the top was 13,000 | 15:02.58 |
| henrys | yea most folks skiing there are acclimated to something above 5K to starts. | 15:03.06 |
| | s/starts/start | 15:03.18 |
| Robin_Watts | Sleeping at 15,600 was "interesting". | 15:03.51 |
| | They give you candles, but there's barely enough oxygen to get them lit. | 15:04.15 |
| kens | I don't think I fancy that height, given that I'm technically asthmatic. I *really* don't want to leave the mountain on a helicopter, it looks very embarassing | 15:04.55 |
| Robin_Watts | In ecuador we drove from 8500 to 16400 and getting out of the car there really felt bad. couldn't walk more than 100 yards without feeling knackered. | 15:05.46 |
| henrys | yea I can't even rap my head around how the everest and other himalayan climbs are doable at all without oxygen. anything above 14 and everything is so labored. | 15:06.01 |
| Robin_Watts | but we hit 17000 (just) in the last trip, and because I'd acclimatised over about a week by that stage, it was fine. | 15:06.14 |
| | Helen cheated and used diamox (and still needed 5 mins on an oxygen cylinder) | 15:06.34 |
| kens | I'll let you go to the top of the mountain and take pictures then, I'll just stay on the lower slopes | 15:07.10 |
| Robin_Watts | henrys: Yeah, but I rather suspect that there would be far fewer deaths on everest if people actually always climbed without oxygen (or kept oxygen for emergency descents only) | 15:07.33 |
| | henrys: Presumably you've read "Into Thin Air"? | 15:08.03 |
| henrys | I firmly believe nobody belongs on everest at all... | 15:08.30 |
| | with or without oxygen. | 15:08.47 |
| Robin_Watts | henrys: yeah. But before we all leave, can we pick up the trash? | 15:08.52 |
| henrys | Robin_Watts: yea great book. | 15:08.57 |
| Robin_Watts | I also recommend "The Climb". | 15:09.06 |
| henrys | Robin_Watts: you mean the dead bodies too? | 15:09.29 |
| Robin_Watts | Krakauers book blames a climber called Boukreev (at least partly). | 15:09.46 |
| tor8 | henrys: leave the dead bodies for future archeologists... | 15:09.55 |
| kens | Nah, leave the bodies for future archaeologists | 15:10.01 |
| tor8 | kens: I knew I'd spelled that wrong... | 15:10.30 |
| Robin_Watts | and "The Climb" is Boukreev's account of the same incident. I'm much more inclined to think that Boukreev did everything right. | 15:10.33 |
| kens | tor8 you're assuming I spelled it correctly ;-) | 15:10.46 |
| Robin_Watts | henrys: Yeah. | 15:10.48 |
| tor8 | kens: my spelling looked funny as soon as I'd hit send | 15:11.01 |
| kens | Well, its a funny word :-) | 15:11.17 |
| Robin_Watts | We've looked at holidays to Everest base camp before, but I've been massively put off by the fact that supposedly it's a horrible mess of trash and human excrement now. | 15:11.35 |
| | That and the fact there is no wifi. | 15:11.48 |
| chrisl | Robin_Watts: "a horrible mess of trash and human excrement" - might as well holiday in Runcorn ;-) | 15:12.41 |
| henrys | I can see going to base camp, I think the ascent is too unpredictable for even the best climbers. | 15:13.12 |
| Robin_Watts | henrys: It's not a 'climb' as such (the only sections where you do real mountaineering are in the icefall and on the hilary step). | 15:13.58 |
| | And on both those places the sherpas fix lines for you. | 15:14.15 |
| henrys | it's not that it's the weather. One storm and you're done. | 15:14.40 |
| Robin_Watts | So it's really a slow plod up and down the mountain (several times in order to acclimatise yourself). | 15:14.41 |
| | And all that while gambling on the weather, yes. | 15:14.55 |
| | The problem is, it's become something that any reasonably fit, reasonably wealthy fool that's prepared to risk their life can tick off a life list. | 15:15.58 |
| henrys | and do it on the backs of economically exploited sherpas. Doesn't make sense to me. | 15:18.50 |
| | but I can't voice that too loudly in my area lots of mountaineers here... I know quite a few folks who've done it. | 15:20.07 |
| Robin_Watts | Yes, I heard nightmare stories about sherpas when I was in Nepal. | 15:21.33 |
| | Lots of people hire on as sherpas with no experience. | 15:21.50 |
| | And they end up doing everything with little or no equipment (none of the right clothes etc), | 15:22.09 |
| | Loads of them die every year. | 15:22.15 |
| | But they do it because it's the only way they can get enough money to live. | 15:22.58 |
| jogux | henrys: so... mupdf packaging for iOS. it would nice if it was packaged as a proper framework; eg. I believe this is a competitor: https://pspdfkit.com and that's really nicely packaged from what I remember last time I looked at it. | 15:32.27 |
| Robin_Watts | Right. MuPDF for android. | 15:34.15 |
| jogux | henrys: for Android; I think a nice packaging is stuck behind Robin's "full jni" idea. most android developers don't groke ndkbuild.py or jni and would hugely prefer a pre-compiled binary, but the API (aiui) isn't currently rich enough for htat to be possible. | 15:34.32 |
| Robin_Watts | What we *really* need/want is for the MuPDF C api to be exposed through JNI as a java interface. | 15:34.36 |
| | I have code that's on the way there. | 15:34.55 |
| | fred could maybe pick that up and push on with it. | 15:35.04 |
| jogux | I don't think there's currently a nice android studio example for android (though I've lost track of the state of android studio wrt to ndk) | 15:35.47 |
| henrys | okay sounds like 2 good projects to start him on we'll give it a go. | 15:36.14 |
| Robin_Watts | jogux: There is not. The only example code with mupdf on android is the android viewer itself. | 15:36.17 |
| | henrys: If he wants to tackle the JNI stuff, he should talk to me, and I'll get him a copy of what I've done so far. | 15:36.45 |
| jogux | for iOS mupdf it might also be good to do a cocoapod (which should be a few hours work at most) as a lot of, urm, non-engineers find that easier to handle. and it plays to our strength of open code (pspdf doesn't have a free/open version) | 15:37.21 |
| henrys | okay I don't know what his schedule is yet throgh the holidays but I expect he'll have questions when he gets started. | 15:41.14 |
| Robin_Watts | henrys: I'll be here on and off all the time (except when I go to Berlin) | 15:41.50 |
| jogux | if he wants to ask me anything next week he's probably best to email. I'll likely be around Monday UK time. | 15:41.53 |
| Robin_Watts | (So, off most of 25th/26th, and 29-2nd or something) | 15:42.12 |
| jogux | henrys: if Fred is free does that mean there's a lovely Mac OS X mupdf build submitted to the mac appstore? :-) | 15:45.51 |
| henrys | jogux: so he should be able to do the framework such that you just choose the platform right? | 15:47.32 |
| | or do we need 2 projects? | 15:47.55 |
| jogux | henrys: 'framework' in the sense I mentioned is an mac & iOS thing. probably not actually possible to share one between the two. There's not really a 'mac' mupdf that could be packaged like that I think (it'd be x11 or qt neither of which fit neatly into a proper mac app) | 15:48.56 |
| henrys | jogux: oh it's not friendly to XQuartz | 15:50.30 |
| | ? | 15:50.31 |
| jogux | XQuartz isn't even bundled by Apple anymore, it's an oddity for geeks now basically :-) | 15:51.09 |
| | I don't think xquartz and standard mac ui components are mixable | 15:51.28 |
| henrys | jogux: so you could have a project to build all of mupdf's tools and such | 15:52.17 |
| jogux | you could, I would argue that would be of more benefit to people that wanted to do development /to/ mupdf, rather than people that wanted to use it. | 15:53.01 |
| henrys | is that what you were requesting? I don't think we want to get into doing a full blown display on os x but I guess that would be nice. | 15:53.35 |
| | jogux: so you just want a library on mac os x? | 15:55.39 |
| Robin_Watts | henrys: We already have a library on macos x. | 15:55.50 |
| | It has the standard mupdf C API. | 15:56.10 |
| jogux | henrys: I have two suggestions, I may be confusing by intertwining them :-) | 15:56.14 |
| henrys | Robin_Watts: right but as I understand it, it's not the sort of thing you can drop into an xcode project. | 15:56.26 |
| Robin_Watts | henrys: Indeed, it is not packaged for xcode in that way. | 15:56.44 |
| jogux | henrys: suggestion 1) we should package mupdf for iOS so that it looks like iOS developers expect and is easy to drop into an app I'm writing, ie. a nice framework | 15:56.53 |
| tor8 | jogux: no, please no more project files that need to be kept up to date along with the makefiles... | 15:56.56 |
| Robin_Watts | But frankly, neither is any other library that you'd get in the unix world (like say jpeglib) | 15:57.06 |
| jogux | tor8: I would (probably) not advocate that, indeed. nothing I'm suggesting *requires* that | 15:57.20 |
| tor8 | it's bad enough with me forgetting to update the win32 vcproject files every other time... | 15:57.43 |
| henrys | tor8: we have fred now ;-) | 15:58.10 |
| jogux | henrys: suggestion 2 is that we do a proper release of whatever qt thing fred has done that works on mac os, as a proper mac app for end-users. | 15:58.14 |
| tor8 | the unix makefile uses $(wildcard) so that hardly ever needs updating | 15:58.15 |
| henrys | jogux: we are doing a proper release of the qt stuff anyway. | 15:59.35 |
| jogux | henrys: great! :) | 15:59.41 |
| | I keep on mentioning that because I wanted a proper mac build of mupdf :-) | 16:00.04 |
| | s/wanted/want/ | 16:00.08 |
| Robin_Watts | AIUI, the needs and wants of mobile developers are different to that of desktop developers. | 16:03.18 |
| | desktop developers pretty much want the standard C level API. | 16:03.29 |
| | mobile developers want 'a PDF display component' that they can drop into their apps. | 16:03.52 |
| | i.e it's not the C level API they want, so much as a "PDF viewing mode" they can kick their apps into and out of. | 16:04.16 |
| | So it's the UI of our viewer that they want. | 16:04.35 |
| pedro_mac | Iâd agree with that | 16:04.35 |
| henrys | for ios is this what we are talking about doing: https://developer.apple.com/library/ios/technotes/iOSStaticLibraries/Articles/creating.html | 16:04.55 |
| Robin_Watts | And that (AIUI) is best offered by doing a framework or a cocoapod, right? | 16:05.10 |
| henrys | s/doing/doing? | 16:05.15 |
| Robin_Watts | henrys: No. That's exactly what they don't want, AIUI. | 16:05.35 |
| jogux | henrys: I think that is part ot | 16:06.15 |
| | part of it | 16:06.23 |
| Robin_Watts | If I'm following, that is just a simple static library build of mupdf that will enable programmers to make the usual C API calls. | 16:06.24 |
| jogux | robin_watts: you can bung obj-c stuff in there too | 16:06.40 |
| Robin_Watts | mobile developers don't want that, because if that's all they had, they'd still have to redo all the UI. | 16:06.43 |
| jogux | and graphic resources | 16:06.52 |
| | actually maybe that's not it. just a sec. | 16:07.14 |
| Robin_Watts | The zooming, the page caching, the icons, everything that we've already done in the ios viewer layers. | 16:07.19 |
| | They want a jpeg viewer app, they don't want jpeglib. | 16:08.03 |
| jogux | henrys: apple's doc don't seem to mention it. http://kodmunki.wordpress.com/2014/11/07/universal-cocoa-touch-frameworks-for-ios-8/ | 16:08.08 |
| | robin_watts: yes. probably the main API we should expose from our framework would be a UIViewController | 16:08.33 |
| henrys | but they would use that if the application was just embedding mupdf for say pdf -> png and they'd deal with the output. | 16:08.39 |
| Robin_Watts | henrys: If they want the mupdf C level api that they can drive to do pdf->png, then what you describe is perfect. | 16:09.26 |
| | BUT it's also trivial to do already. | 16:09.34 |
| jogux | henrys: I was thinking the same way Robin was; the framework would expose a iOS UI component that can display pdf files. | 16:09.50 |
| | that is what I would imagine most iOS people who want mupdf would want; ie. viewing pdfs within their app. | 16:10.13 |
| Robin_Watts | Android, due to the way it's intent system works, kind of already has MuPDF in the required form. | 16:10.40 |
| | The problem there is that the exposure of the capabilites of the MuPDF core to the java level is very uneven. | 16:11.07 |
| | which means that people wanting to do modifications/customisations have to battle JNI. | 16:11.37 |
| rayjj | Just in time for chrisl to go on holiday, I opened a new segfault for him (or kens) high level device problem, but dangling pointer to font cache -- currently assigned to chrisl | 16:12.20 |
| Robin_Watts | It would be much nicer if we offered a consistent java interface, both because it would make the Android app more customisable, and because it would allow java developers to drive MuPDF programmatically. | 16:12.24 |
| henrys | well what if the application wanting to use mupdf already has a full blown ui. Isn't using ours going to be an awkward switch for the user. It seems we have 2 kinds of users. | 16:13.19 |
| chrisl | rayjj: probably one for kens I'm pleased to say..... | 16:13.40 |
| Robin_Watts | henrys: If people want to do their own UI from scratch, then yes, they want to use the existing mupdf C level API. | 16:14.04 |
| tor8 | I can imagine that people wanting to drop in a PDF viewing component based on mupdf wouldn't be interested in all the advanced editing and annotation features | 16:14.17 |
| henrys | right and we do want to make the API xcode friendly right? | 16:14.36 |
| Robin_Watts | If people want to reuse our UI, then they will want a nicely packaged "component". | 16:14.41 |
| | henrys: Speaking personally, no :) | 16:14.50 |
| | XCode is the work of Satan. | 16:15.00 |
| tor8 | the idea (at least as I see it) is that if we get the JNI layer up, it'll be a lot easier for people to write various android UI components | 16:15.01 |
| | and do all that in Java code, which is a lot easier | 16:15.18 |
| henrys | Robin_Watts: you'd think I wouldn't be fool enough to ask you that. | 16:15.21 |
| jogux | robin_watts: I would bet most iOS developers that want to do a new UI would take ours and tweak it, rather than trying to understand the C API and how to fit it into UIKit. | 16:15.28 |
| Robin_Watts | jogux: Yes, I absolutely agree. | 16:15.47 |
| tor8 | henrys: jogux: and iOS developers probably just want a UIView that they can drag and drop in Interface Builder | 16:15.53 |
| Robin_Watts | Desktop developers probably want the C level API. | 16:15.54 |
| | Mobile developers probably want a packaged PDF display component. | 16:16.12 |
| tor8 | iOS developers who want to write their own can just use the current C level API | 16:16.18 |
| jogux | tor8: my understand is that these does UIViewController is the core building block (as opposed to UIView) | 16:16.31 |
| tor8 | future iOS developers will scratch their heads and ask why Swift can't find it... | 16:16.34 |
| jogux | s/does/days/ | 16:16.36 |
| tor8 | jogux: yeah, probably true | 16:16.48 |
| henrys | anybody played with swift? | 16:16.59 |
| tor8 | heavens no | 16:17.03 |
| Robin_Watts | henrys: Honestly, it's pretty trivial to make the existing mupdf distro work in xcode. | 16:17.06 |
| jogux | if we do a framework, it /should/ be usable from swift. | 16:17.06 |
| | (without too much, if any, extra work I mean) | 16:17.33 |
| Robin_Watts | You drop the C files in, and build it, and you get a library with the required interface. | 16:17.42 |
| | There is no clever 'packaging' required. | 16:17.55 |
| henrys | Robin_Watts: so maybe the C API stuff just needs some documentation? | 16:18.49 |
| Robin_Watts | If you do want to provide a special ready to go xcode subproject (or whatever it's called in freaky-xcode-world parlance) then we could do that, but that's *exactly* what tor8 said he didn't want to have to deal with - another project to keep in sync. | 16:18.58 |
| | henrys: The C API stuff has some documentation. It could be better, but then couldn't all documentation be better. | 16:19.32 |
| | Possibly what's needed is a "here's how you build this in Xcode" step by step guide. | 16:19.50 |
| jogux | even for the C API, we could present as a framework. it is easier to handle than a library + bunch of headers. | 16:19.52 |
| Robin_Watts | jogux: Right, but that would be one more thing to keep in sync. | 16:20.09 |
| jogux | robin_watts: possibly. I'm not sure. It can still use the existing makefiles to do the core build. | 16:20.32 |
| Robin_Watts | jogux: Well, that would be nice. | 16:21.06 |
| | (my experience of xcode is that it likes to break the way it interfaces with makefiles every release, but maybe hell has frozen over and they've stopped that) | 16:21.38 |
| jogux | when you're looking for third party iOS components, it's easy to tell the ones where the people actually care about iOS and know what they're doing on iOS. | 16:21.57 |
| | and I've dealt with far far too many of the former :-( | 16:22.25 |
| Robin_Watts | For ios, I absolutely think that a packaging of a "MuPDF based viewing component" is a worthwhile thing to do. | 16:23.14 |
| | Cos ios devs like plastic colored blocks they can plug together. | 16:23.31 |
| henrys | coffees | 16:25.01 |
| rayjj | Robin_Watts: I like that. The "design" is more influenced with how the colored blocks look together and how easily they snap together rather than what the end result is like | 16:26.10 |
| henrys | anyway we certainly have enough to get fred started thanks everybody. | 16:29.54 |
| Robin_Watts | henrys: My only concern is that with the 'do a framework release for macosx' (i.e. a nicely packaged static lib and headers), unless fred knows our objections, he'd do the 'naive' thing of dropping everything into xcode and making a new xcode project that doesn't rely on the makefiles. | 16:31.24 |
| | so he should definitely talk to us before charging off on his own. | 16:32.08 |
| | (he seems to be an infrequent visitor to irc) | 16:32.29 |
| henrys | he's not going to the naive thing because he'll read the IRC discussion in the logs first. I'm going to have him start attending Tuesday meetings and I imagine he'll show up more frequently. He worked a lot with michael and I through email for gsview. | 16:33.43 |
| Robin_Watts | fab. | 16:33.55 |
| | sounds ideal then. | 16:34.08 |
| henrys | although I'm not crazy about the makefiles if it is going to harm us like it does in studio where we can't use popular plugins and such. | 16:35.15 |
| Robin_Watts | what popular plugins can't we use in studio? | 16:39.18 |
| henrys | most recently I wanted to use the 64 bit checker that I told you about it won't work if nmake is under the hood for some reason. | 16:40.07 |
| Robin_Watts | Ah. | 16:40.31 |
| | Probably cos it wants to fiddle the compile line that's used to add some extra flags. | 16:40.53 |
| jogux | henrys: I was tempted to mention gyp again but thought better of it ;-) Sometime I'll have a play with it and see if it's actually as good as they claim and /then/ figure out if anyone else can be convinced ;) | 16:46.10 |
| | in theory it'd let us have a central single place from which makefiles/visual studio/xcode/etc are generated. | 16:47.00 |
| henrys | cmake is looking better and better to me. | 16:47.23 |
| jogux | and the latter *should* behave exactly as an actual proper native thing. | 16:47.28 |
| henrys | sabrina is strarting up her new imac be right back. I didn't get the low end one that looked like a dog, I was wondering why it was so cheap. | 16:48.12 |
| jogux | henrys: when I looked a while back only gyp generated proper native files (cmake generated something like a vsproj... but not like one you'd actually make). maybe that's different these days. | 16:49.08 |
| | henrys: did you get the retina one in the end? :-) | 16:49.17 |
| Robin_Watts | I've only ever dealt with gyp once, and that was for V8. NEVER AGAIN. | 16:53.44 |
| mvrhel_laptop | mornign | 16:57.35 |
| | morning. | 16:57.40 |
| | kens: are you there? | 17:00.21 |
| pedro_mac | henry: and apologies for encouraging sabrina to get the most expensive one ;) | 17:00.37 |
| mvrhel_laptop | oh actually, never mind kens | 17:00.46 |
| kens | mvrhel_laptop : only in spirit | 17:00.48 |
| | LOL | 17:00.54 |
| mvrhel_laptop | kens: so do you think you will go skiing if we go to Denver for the meeting? | 17:02.33 |
| kens | If we go to Denver, then yes definitely | 17:02.54 |
| henrys | jogux, pedro_mac no just got the beefier processor 2.9GHZ | 17:03.05 |
| mvrhel_laptop | I just bought a new snowboard, but we are off to a terrible start of the season here. Nothing close by is open yet. hardly any snow in the mountain | 17:03.07 |
| kens | Alps are greeen :-( | 17:03.20 |
| mvrhel_laptop | well march in CO should be good | 17:03.40 |
| henrys | you guys may need to find a new sport soon ;-( | 17:03.57 |
| mvrhel_laptop | yes | 17:04.05 |
| McErroneous | Hi , i do " gs -sDEEVICE=gdi -OutputFile=gdi.prn Address.ps" and i get an "ERROR undefinedfilename in Address.ps", version is gs v8.15.2. | 17:36.47 |
| kens | so that file dfoes not exist by that name in that directory | 17:37.06 |
| McErroneous | the file Address.ps exists in my home-directory... | 17:37.46 |
| kens | And are you running that command from your home directory ? | 17:38.05 |
| McErroneous | which is my wd (working directory), let me recheck for misspellings | 17:38.21 |
| kens | Also -sDEEVICE is incorrect | 17:38.32 |
| McErroneous | this time i get a ERROR: /invalidfileaccess in --.outputpage-- | 17:40.34 |
| kens | So you don't have permissions to write that file in that location (gdi.prn) | 17:40.56 |
| | Also tghat is an (ancient) ESP fork of Ghostscript, we don't support that. | 17:41.41 |
| McErroneous | i go mad by times, i do not have permission in my home-directory ? should i use full-path ? | 17:41.52 |
| | i go mad by time ... | 17:42.09 |
| kens | Maybe the file is locked by another process, how should I know ? Its your system | 17:42.23 |
| McErroneous | thank you..., for trying | 17:43.01 |
| | back..., got it, it was the fault of an option namely this gs-version accepts -sDevice= instead of -sDEVICE=.... i hate it... | 17:53.38 |
| | last time it was the otherway around | 17:54.00 |
| | thanks.. | 17:54.23 |
| kens | Like I said, that's ESP Ghostscript, not Ghostscript. | 17:55.16 |
| McErroneous | do you mean it is not Ghostscript GPL ? | 17:56.13 |
| kens | Its a fork | 17:56.20 |
| | SO its not Ghostscript, its ESP Ghostscript | 17:56.34 |
| McErroneous | a fork of Ghostscript GPL ? | 17:56.48 |
| kens | Yes a very oldf (7 years) fok of Ghostscript | 17:57.07 |
| mvrhel_laptop | brb | 18:05.23 |
| | Forward 1 day (to 2014/12/20)>>> | |
IRC Logs