| | <<<Back 1 day (to 2014/08/21) | 2014/08/22 |
| rayjj | re the recent support query from cust 501 -- I assume that this is their "esign" package, but don't know. | 00:04.13 |
| | have to take my son to piano. bbiaw | 00:05.06 |
| popl | mupdf++ | 07:19.21 |
| | :) | 07:19.25 |
| Robin_Watts | popl: ok... | 07:59.24 |
| kens | Good giref 'we already tried all the things you suggest, but didn't bother to tell you....' | 09:35.26 |
| chrisl | I'm confused... I don't see anything relating to Ghostcript in there? | 09:37.37 |
| kens | There isn't, exactly. But they are using the ghostscript.inf file (renamed to imm-something.inf | 09:38.09 |
| chrisl | Oh. We should never have included that :-( | 09:38.51 |
| kens | I'm thinking it was a very unfortunate inclusion, yes, that's the thing that keeps getting the 'do you do a signed driver' question as well :-( | 09:39.25 |
| | From teh Googling it looks like some OEMs ship pre-installed versions of Windows with bits missing. This seems to be particularly common with TCP/IP printing (which they are doing) but also seems to occur with just about any printer (ntprint.inf missing) | 09:41.47 |
| | Of course, this is not *our* problem..... | 09:42.04 |
| tor8 | Robin_Watts: kens: which gs file has the grayscale/colorness test? | 12:50.24 |
| kens | IIRC they uploaded it to picas, and it wasn't small | 12:50.42 |
| tor8 | kens: sorry. I mean the source code test function, not the test file | 12:51.06 |
| | the one with the fuzzy grayscale test | 12:51.22 |
| kens | Oh, then I don't know, sorry | 12:51.23 |
| tor8 | kens: okay, thanks anyway. | 12:51.31 |
| kens | Looks like its somewhere in the ICC code | 12:55.39 |
| | Seems to use a merthod in the icclink called is_color | 12:57.04 |
| | tor8 in gsicc_monitorcm.c gsicc_mcm_monitor_rgb | 12:59.20 |
| tor8 | kens: fab! thanks. | 12:59.53 |
| kens | I have to say the 'slop' looks hard-coded | 13:00.08 |
| tor8 | DEV_NEUTRAL_8 yeah | 13:00.21 |
| kens | Yep that's it | 13:00.27 |
| | Its set at 5 in gscms.h | 13:00.59 |
| Robin_Watts | tor8: I addressed some of the issues in my current patch. | 13:05.57 |
| | I need to look at the other things you mentioned. | 13:06.06 |
| tor8 | Robin_Watts: I'm bashing on it as well, based on your latest pushed from yesterday | 13:07.07 |
| Robin_Watts | oh, ok, cool. | 13:07.14 |
| tor8 | maybe I should have notified you, in case we step on each others toes... | 13:07.19 |
| Robin_Watts | no harm done, I'm in SOT mode atm. | 13:07.34 |
| tor8 | Robin_Watts: ah, okay. I thought you had done more today... | 13:07.55 |
| | I'm trying to make it simpler to follow so we can keep it as an example of how to write a simple device | 13:08.24 |
| Robin_Watts | tor8: I was pleased with how small the shading handling was :) | 13:13.35 |
| tor8 | Robin_Watts: you should see how small I managed to make it ;) | 13:15.13 |
| | I had to waste a full 6 lines just to pack and unpack the void* struct with the arguments | 13:15.14 |
| | but yes, the shade interface even with the prepare/process split is surprisingly lean | 13:15.43 |
| henrys | tor8, Robin_Watts do you guys have a few minutes to talk about doing epub? | 13:38.03 |
| Robin_Watts | absolutely. | 13:38.41 |
| tor8 | henrys: yes. | 13:38.47 |
| henrys | IMHO if we do it tor8 should do it, at least it needs to be in-house, which means tor8 for now. | 13:39.43 |
| tor8 | henrys: I still have the old epub project that we half-started a few years ago, and I've kept it from bit rot | 13:40.44 |
| Robin_Watts | The only argument against that would be if we could license something in that was in a form tor was happy to maintain (and from what he's said, that's not the case), so I agree. | 13:40.54 |
| henrys | how long have you known tor8? ;-) | 13:41.20 |
| tor8 | yeah, I looked at the Sumatra epub reader and it's heavily integrated with their C++ code base and windows | 13:41.26 |
| | henrys: I've used it to scrub crappy formatting in epub books :) | 13:41.46 |
| Robin_Watts | AIUI, the existing code we (tor) has will open epub books and parse them, but doesn't do any layout ? | 13:42.17 |
| tor8 | it's amazing the kind of crap you see in epub books coming out from major publishers... | 13:42.24 |
| | Robin_Watts: it parses XHTML and applies CSS formatting properties | 13:42.44 |
| | but doesn't do any actual layout or rendering | 13:42.49 |
| | it just has all the info it needs to do the layout | 13:42.57 |
| Robin_Watts | so it's a question of doing simple CSS based layout into the MuPDF device interface. | 13:43.00 |
| | the device interface takes care of the rendering. | 13:43.18 |
| | So it's "just" a layout problem, right? | 13:43.27 |
| tor8 | yeah, basically what remains is to go from this model of text + css properties to laid out text that we can feed into the mupdf device interface | 13:43.30 |
| | so, text layout, which we sort of need for forms and annotations (and SVG) | 13:43.51 |
| henrys | the problem is if we take money for it, then we have a rigid schedule and we have one person on mupdf right now. Thatâs my only concern with going forward. | 13:43.52 |
| tor8 | Robin_Watts: more or less. there's also parsing the table of contents and other metadata cruft in epub but that should be fairly easy stuff | 13:44.39 |
| Robin_Watts | henrys: Right, but time for tor to complete this is likely to be < time for potential customer to integrate a random other system, I would have thought. | 13:44.45 |
| | We (as yet) have no idea what timescales, quality requirements, $$$ etc is from the potential customer. | 13:45.37 |
| henrys | tor8: so we can schedule it as if it were a part time project 20 hours a week, I suppose but if we do this as long as tor8 realizes he may not be able to pass on an important customer bug | 13:45.40 |
| tor8 | henrys: I'm sorry, that didn't parse | 13:46.25 |
| henrys | tor8: if an important bug comes in you donât get to say sorry Iâm doing epub. | 13:46.50 |
| tor8 | henrys: right. | 13:46.56 |
| Robin_Watts | Have we had any important customer bugs come in for mupdf recently? It's feeling quite stable. | 13:47.35 |
| | Time to break it! :) | 13:47.40 |
| tor8 | Robin_Watts: Shhh! | 13:47.54 |
| | no, it's been real quiet on the mupdf bug front since the 1.5 release | 13:48.10 |
| | I expect the major bug squishing pass I did for that paid off :) | 13:48.26 |
| | Robin_Watts: something else, if we get this html layout thing working, we have a non-webkit solution for reflow | 13:49.22 |
| henrys | Robin_Watts: I usually like to talk miles out of taking money. It takes all the pressure off and we undertake projects because we believe they will make the product more attractive in the marketplace. Doing that should trump whatever we would have gotten from the customer. But I guess I could go either way on this one. | 13:49.22 |
| Robin_Watts | tor8: yeah. | 13:49.36 |
| | henrys: Having epub definitely would seem to make mupdf more attractive in it's target market. | 13:50.05 |
| tor8 | and we have to bash the document interface into allowing non-fixed page layout style documents :( | 13:50.08 |
| | there's a real lack of solid ebook viewers ... all the free ones are cr*p and the paid ones are not much better, and locked into their specific walled garden book stores | 13:50.56 |
| henrys | tor8: I use calibreâs a bit and it seems okay, but the rendering is weak fonts looks crappy. | 13:51.33 |
| Robin_Watts | If I was implementing an ebook reader, to be able to buy a solution in that did epub/pdf would be attractive. | 13:51.37 |
| tor8 | so I think there is at least an open source angle for doing it; selling it into the book stores will depend on how fierce a grip adobe has with their drm | 13:51.40 |
| | henrys: the calibre one is the best of the lot; and that's saying something.... | 13:52.02 |
| Robin_Watts | book stores would tend to like to build their own walled garden, hence do their own DRM. | 13:52.23 |
| tor8 | Robin_Watts: from what I've seen, all the minor ones are all bought into the Adobe ecosystem | 13:52.51 |
| | $0.2 of every ebook purchase goes directly into the pocket of Adobe IIRC | 13:53.04 |
| | unless it's a DRM free ebook | 13:53.14 |
| henrys | how useful would the layout engine be for projects other than epub? | 13:53.29 |
| tor8 | henrys: it would improve our reflow story | 13:54.00 |
| Robin_Watts | It would be required for SVG. | 13:54.00 |
| tor8 | and subsets of it would be needed for SVG and to improve the robustness of our forms work | 13:54.28 |
| Robin_Watts | I dunno if we're ever going to support XML based forms in PDF, but I think maybe layout would be needed for that. | 13:54.54 |
| tor8 | Robin_Watts: multi-line text areas need layout (even if it's just plain unstyled text) | 13:55.22 |
| | doing the formatted rich text, I think it uses RTF syntax? I haven't looked. | 13:55.35 |
| Robin_Watts | If we ever wanted to do rudimentary HTML display we would need it (and CSS gets us a long way) | 13:55.37 |
| henrys | thatâs what I thought and was something that really makes the project more appealing. | 13:56.49 |
| | itâs hard to sell a commercial case for epub to miles (and stay honest) | 13:57.38 |
| Robin_Watts | presumably when we have the layout side of things done, it means that other formats (like MOBI etc) might be possible with less pain too. | 13:57.48 |
| | epub is not going to change mupdf overnight, no. But I could believe it being more of a tipping point for a potential client than XPS is. | 13:58.33 |
| henrys | Now Iâll just talk to Miles and figure out if is really keen on billing the customer. Much nicer to do this without a schedule unless tor8 feels really confident about putting down some dates. | 14:00.37 |
| tor8 | henrys: if I were to drop everything else, I'd be confident in saying we could have non-embarrassing epub support by christmas | 14:01.24 |
| | ironing out all the odd css and html quirks could suck up a huge amount of time, but I expect that won't be necessary (given the low bar the competition has already set for us) | 14:02.12 |
| Robin_Watts | henrys: I think billing the customer is important. Otherwise they might back out :) | 14:02.18 |
| | Also, given the customer, they will probably have their own test files for us to look at. | 14:02.43 |
| tor8 | and getting it to do non-latin/greek/cyrillic text would also be a later project | 14:02.57 |
| | speaking of that, is there any word from URW? | 14:03.07 |
| | yes, having files from a customer to drive priorities and expectations would help a lot | 14:03.38 |
| henrys | tor8: I can check with them but they arenât late yet. | 14:03.40 |
| Robin_Watts | henrys: For the avoidance of doubt... I will hold off sending any messages to the customer until you say otherwise. | 14:03.52 |
| tor8 | henrys: what is the expected date? | 14:04.31 |
| pedro_mac | vaguely remembers picsel doing an epub prototype in SO quite a while back. That might fit into the âembarrassingâ category though ;) | 14:05.20 |
| henrys | tor8: it was âmonthsâ, Iâll search email when weâre done here. | 14:05.46 |
| tor8 | henrys: I'm not antsy, but it would be nice if we could get them in for the 1.6 release | 14:06.10 |
| henrys | so we certainly need a test suite. It would be great to get that from the customer, I see this http://www.epubtest.org/testsuite/ but that looks too small to be anythnig comprehensive | 14:08.07 |
| | actually it does look like a pretty good test. | 14:11.37 |
| | maybe tor8 can go through those tests and see if he can do whatâs there by the christmas date. Iâd prefer that to the ânon-embarrasingâ description ;-) | 14:14.57 |
| | tor8: urw were vague they said a few weeks. Let me ping them again. Since that time I asked them for wingdings which they stated would be 4 weeks. | 14:18.41 |
| | s/were/was | 14:18.53 |
| tor8 | henrys: that test suite is full of difficult and unusual stuff that I haven't seen in any real life PDFs | 14:20.41 |
| | like mathml and embedded svg | 14:20.47 |
| | s/PDF/epub/ | 14:20.55 |
| | and embedded audio and video and stuff like that | 14:21.13 |
| henrys | tor8: in ibooks it just says plugin required for that stuff. | 14:21.43 |
| tor8 | and javascripting and forms and all kinds of stuff. I don't think the Kindle or Kobo or Sony ereaders do any of this :) | 14:22.13 |
| | oh yay, media overlays | 14:23.44 |
| henrys | tor8: much of it does seem to work in ibook actually. | 14:23.55 |
| | tor8: if we are going to charge the customer we need a description of what we are going to do. | 14:24.37 |
| Robin_Watts | but we can hopefully cull that from what the customer wants to give us. | 14:25.33 |
| tor8 | Robin_Watts: henrys: I would say EPUB 2.0 (and explicitly not EPUB 3.0 which is what adds all this crap) | 14:25.54 |
| Robin_Watts | They are considering Readium, apparently. | 14:26.10 |
| henrys | tor8: I see a google code project from epub 2 | 14:27.55 |
| tor8 | Robin_Watts: readium is based on the chrome browser | 14:28.32 |
| | so I think matching their functionality is a bit out of our league | 14:28.50 |
| Robin_Watts | I don't think that's true. | 14:29.11 |
| tor8 | EPUB 3 has fixed layout ... why the hell not just use PDF then? | 14:29.12 |
| Robin_Watts | (about it being based on chrome) | 14:29.21 |
| henrys | http://code.google.com/p/epub-conform/ is epub 2 | 14:29.30 |
| tor8 | Robin_Watts: well, it's a chrome extension | 14:29.32 |
| | or maybe they have several projects | 14:29.45 |
| Robin_Watts | There is a Readium Chrome extension, yes. | 14:29.46 |
| tor8 | Anyway, I need to pop out for a while. I'll check back later. and I expect we'll need to study the landscape a bit more before we decide on a target level. | 14:30.39 |
| Robin_Watts | Readium SDK Core C++ library is cross platform and implemented largely in native code with some JS/Java/C# impementations where necessary. | 14:30.49 |
| henrys | Robin_Watts: in the meantime you can tell the customer we are studying the project, and ask if they have testfile, benchmarks⦠concrete objectives they need to meet for the project. | 14:35.42 |
| Robin_Watts | sure. | 14:35.59 |
| RonL | rayjj - can I follow up on my request for a DNS entry here? | 14:36.24 |
| henrys | good morning RonL | 14:36.54 |
| Robin_Watts | Morning RonL. | 14:37.05 |
| RonL | good morning | 14:37.05 |
| Robin_Watts | an artifex.com dns address? | 14:37.16 |
| RonL | yes. the web developer building a new smartoffice website has requested an A Record be made for smartoffice.artifex.com (he needs two actually) | 14:38.00 |
| | the other one he needs is for "sohost.artifex.com" | 14:38.31 |
| Robin_Watts | Ok, generally rayjj is the man for DNS requests... | 14:39.33 |
| Robin_Watts | waves fresh coffee under the webcam to try to wake him up... | 14:39.52 |
| RonL | I could use some of that coffee too - and I'm already awake! | 14:40.44 |
| kens | I see those idiots are back again, clearly they have no understanding of PDF files. | 14:41.21 |
| kens | will leave them for rayjj :-) | 14:41.37 |
| Robin_Watts | kens: I am tempted to reply to that post now, as it's to do with MuPDF and I've just been changing the device in question... | 14:45.06 |
| kens | Robin_Watts : I'm sure ray won't mind...... | 14:45.22 |
| chrisl | Like "it works on PDFs....." | 14:45.37 |
| kens | Robin_Watts : you may want to think carefully before you reveal your existence to them :-) | 14:47.07 |
| Robin_Watts | what? They might mail me back and drag me away from smart office? :) | 14:47.37 |
| chrisl | Robin_Watts: did you resolve the issue with the red space character? | 14:47.56 |
| kens | You may find SOT preferable in time...... | 14:47.57 |
| pedro_mac | reckons kens hasnât spent lon enough looking at SO ;) | 14:50.13 |
| kens | thinks pedro_mac hasn't spoent time dealing with these customers :-) | 14:50.30 |
| pedro_mac | kens: I feel your pain, but its a tough call ;) | 14:51.22 |
| Robin_Watts | chrisl: I did not. I feel that is a case where it's acceptable for us to give the wrong answer. | 15:03.45 |
| RonL | Hi rayjj | 15:07.17 |
| rayjj | RonL: Hi. | 15:08.47 |
| | RonL: I assume you are here to ask me about getting the DNS records you requested ? | 15:09.16 |
| rayjj | didn't really need a question mark for that :-/ | 15:09.37 |
| RonL | yes - I'm going out of town for a week beginning tomorrow so I wanted to follow up | 15:09.47 |
| rayjj | RonL: sorry. I've been working on a customer issue. I'll take a look at doing it now | 15:10.45 |
| RonL | Thank you - I'm sorry to have to bother you.... | 15:11.41 |
| Robin_Watts | rayjj: I just replied to the customer about the Mudraw color detection. | 15:12.17 |
| rayjj | RonL: np. I just took care of it (I think) We'll have to wait for "up to 24 hours" to see if it propagates, but I just did nslookup smartoffice.artifex.com and it resolved properly for me | 15:19.44 |
| | Robin_Watts: thanks. We probably should change gs over to use a selectable tolerance as well | 15:21.07 |
| | we had done it for ex-cust 801 and since they went away (for a while, at least) we (mvrhel or I) never did any enhancements. | 15:22.04 |
| | RonL: Let me know (phone call is OK) if you don't see it resolve for you by the time you leave. | 15:23.03 |
| RonL | Thanks rayjj. I'll check too. I'm going to send a email note to the developer, and cc you. I want to invite him to contact you if he has any questions/requests while I'm away | 15:23.24 |
| rayjj | If I do this often enough, it doesn't fade into 'backup storage' and it's easier :-) | 15:23.49 |
| RonL | (if that's ok with you) | 15:23.53 |
| rayjj | RonL: Fine, but please have him cc Miles so we keep him in the loop (I'm sure a little extra Artifex related emails in with all the spam won't bother him too much) | 15:24.44 |
| RonL | will do.... | 15:25.01 |
| rayjj | kens: can you take a look at the two small patches on http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=summary | 15:26.49 |
| kens | rayjj I did, was just talkgint to chrisl about the ICC one | 15:27.10 |
| rayjj | kens: the first (about the tags) was a customer 532 fix I wanted to get into our code (in case they ever upgrade). The second is the fix for the stale pointer issue (OutputICCProfile) | 15:28.04 |
| RonL | rayjj - just ran a DIG on both virtual domains, and they did indeed resolve correctly. THANK YOU! | 15:30.10 |
| rayjj | kens: sorry -- I hadn't finished looking at the logs | 15:30.15 |
| RonL | bye | 15:30.22 |
| rayjj | kens: I don't see the discussion in the logs. What is your (and chrisl's) on the changes, please | 15:34.13 |
| kens | rayjj on the phone, not irc | 15:34.35 |
| | I'll reply in the logs in a bit | 15:34.52 |
| rayjj | kens: OK. | 15:34.59 |
| | chrisl: seems that kens left without replying -- can you summarize what you guys discussed, please ? | 16:15.36 |
| mvrhel_laptop | morning | 16:17.39 |
| rayjj | oh, kens, I thought you had left for the day (weekend) | 16:23.57 |
| | morning, mvrhel_laptop | 16:24.04 |
| kens | internet hiccup | 16:24.24 |
| mvrhel_laptop | morning rayjj | 16:24.27 |
| rayjj | I'm struggling with what to tell cust 532 about gs TilingType. For the most part forcing TillingType to 2 looks like Adobe and mupdf, but there are strange ones that bmpcmp shows up. I'm inclined to make a parameter to tell gs to UseTiliingType, and have gs default to TilingType 2 (at least for PDF) | 16:28.20 |
| | one of the strangest ones is tests_private/comparefiles/PP0001G0.pdf -- with mudraw, the background isn't smooth unless I set -b 0, and I see patterns appear on the "people", depending on the resolution. Acrobat shows patterns as well | 16:32.51 |
| | with gs, and forcing TilingType 2, the clothes disappear on the people at 72 dpi :-) | 16:33.33 |
| | but at least the background is nice an smooth (similar to mupdf with -b 0 ) | 16:36.22 |
| Robin_Watts | vaguely remembers losing lots of time to TilingType in my early artifex days. | 16:37.19 |
| rayjj | Robin_Watts: yeah, there's a lot of comments and ugly (IMHO) #if 0 code in their with your fingerprints | 16:41.35 |
| | IMHO, #if 0 code should have a lifetime limit | 16:42.03 |
| Robin_Watts | rayjj: yeah. | 16:42.21 |
| | henrys, tor8: apparently, they want the moon on a stick, tomorrow. | 16:46.22 |
| kens | not topday ? | 16:46.38 |
| henrys | why does epub exist? - pdf for fixed format else html | 16:49.42 |
| rayjj | henrys: I suspect that the epub folks wanted (at least initially) a simpler standard they could control without all the HTML cruft. | 16:51.06 |
| henrys | video and audio are just plugins that we can hand off to the platform, right? or is there more to it? | 16:51.37 |
| Robin_Watts | Video and audio as plugins, probably. | 16:51.56 |
| | I agree, PDF for fixed format, epub for reflowable, but why is the spec moving the other way? | 16:52.33 |
| rayjj | kens: Please see: http://bugs.ghostscript.com/show_bug.cgi?id=695420#c7 I am inclined to open this as a separate bug since iti is unrelated to OutputICCProfile | 16:52.40 |
| Robin_Watts | Everyone likes their ereaders configured differently. | 16:52.46 |
| rayjj | does mupdf have a plugin interface for strange stuff (video, audio, 3dif, ...) from PDF's ? | 16:53.43 |
| kens | rayjj that has to be a separate bug. | 16:54.19 |
| rayjj | kens: OK. Thanks. That's what I thought. | 16:54.35 |
| kens | With respect ot your 2 commits; I can't commit on the tag one, I don't know anything about the tag stuff. | 16:54.37 |
| | Re the ICC string, I did look through it, and frankly the setpagdevice code is ugly as anything. | 16:55.06 |
| rayjj | kens: np. That's probably better for mvrhel_laptop since it is pdf14 transparency related | 16:55.08 |
| | kens: no kidding! | 16:55.21 |
| kens | The whole setup there looks wrong, we should not be ignoring the return value form the device except for a few 'special' cases! | 16:55.30 |
| | OTOH, your fix is the only sensible thing to do in the immediate term. | 16:55.45 |
| | Initially I considered a few other ways to fis the memory problem, but they would all end up with teh OutputICCProfile being incorrect in the page device dictioanry. The only way to get that correct is to add it to the list of special cases. | 16:56.30 |
| henrys | oh letâs put setpagedevice in C on and off the agenda 45 times for next few years. like the old days. | 16:57.09 |
| | feeling nostalgic | 16:57.21 |
| kens | I'd like to spend soem time (when I can spare some) to look more closely at the setpagdevice code. Frankly, creating a dictionary with all the device keys in it, then piclking out just a few special ones is pretty much exactly the opposite of what we should be doing. | 16:57.51 |
| rayjj | kens: OK. I struggled with it. Having PS dicts point to strings that are not "owned" by the PS environment (and GC) seems wrong. It works OK for "static" strings (probably) | 16:58.10 |
| kens | rayjj, that's a separate issue. To me that also feels wildly wrong | 16:58.39 |
| | I think at the very least we shold copy the strings, not just point to them | 16:59.10 |
| | But like I said, with the way setpagdevice works, doing that would simply leave the OutputICCProfile with the wrong information in it. | 16:59.57 |
| rayjj | kens: that's why I tripped over the ProcessColorModel stuff -- Those are strings in the executable space ( dev->color_info.cm_name = "DeviceGray" ) | 17:00.14 |
| | kens: at least adding OutputICCProfile to the 'dynamic' set of keys gives us the correct results | 17:01.16 |
| kens | If there isn't a good reason for maintaining a separate dictionary for the page device, I'd prefer to use the one returned from getdeviceparams. Even if there is a reason for maintaining a separate dictionary, IMO the 'specials' should be the keys we *don't* copy, not the list of keys we do copy..... | 17:01.33 |
| | rayjj yes, that's what I'm saying, I could see other ways to fix the memory problem, but they would leave the value incorrect in the dictionary. With the barking mad way the code works now, there's no other solution than using the dynamicppkeys hack | 17:02.24 |
| rayjj | kens: setpagedevice has arcane rules in the PLRM about 'stickiness' and what to do when _some_ of the parameters are rejected. | 17:02.52 |
| kens | FWIW I did today trip over the corrupted string problem using a device other than pdfwrite as well, so this is clearly a more widespread problem than it first appeared. | 17:03.10 |
| | rayjj, yes, but that doesn't affect *current* page device...... | 17:03.28 |
| rayjj | I think (but am not sure) that the dict was part of the attempt to be able to unwind from problems | 17:03.50 |
| kens | Hmm..... | 17:04.01 |
| | I'm unconvinced, but possibly. Even so, the returned values from getdeviceparams should, IMO, *always* take preference to the stored ones in currentpagedevice, otherwise the values it returns are lies | 17:04.44 |
| rayjj | but devices are 'supposed' to reject all params if any are bad (not that they all do that properly, particularly contrib ones, and cups is suspect as well) | 17:05.05 |
| kens | rayjj, yes but that only affects *set* pagedevice, this is all in *current* pagedevice | 17:05.38 |
| | I'm going to have to run now, but if henrys is OK with adding this to the agenda for the next meeting I think it would be worth talking about (even if it is for the umpteenth time, its the firs occasion that its been *my* problem ;-) | 17:06.13 |
| henrys | sure kens | 17:06.35 |
| rayjj | /me admits to not having dug into this for about 10 years, and wasn't party to the original /design/ | 17:06.48 |
| kens | I'm fairly convinced (chris thinks so too) that the dynamicpppkeys looks very much like a post facto hack when someone realised the 'design' didn't work. | 17:07.36 |
| rayjj | kens: it probably isn't worth bothering everyone with -- it mostly just affects you, chris and I | 17:07.37 |
| kens | agrees, but think the same could be said of the other products :-) | 17:08.02 |
| | GOt to dash..... | 17:08.08 |
| Robin_Watts | rayjj, kens: I looked at rayjj's commits yesterday. I was happy with the tag one, but couldn't comment on the other :) | 17:08.14 |
| rayjj | me too. bbiaw ... | 17:08.22 |
| | Robin_Watts: thanks | 17:08.31 |
| Robin_Watts | rayjj: MuPDF does not have a plug in protocol as such, because MuPDF is not an app. | 17:08.54 |
| | MuPDF renders bitmaps. The app (written by the customer) then displays those. | 17:09.25 |
| | Overlaying video etc onto that is down to the user. | 17:09.47 |
| henrys | bbiab | 17:10.52 |
| qasim52 | hey | 18:22.45 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 18:22.45 |
| qasim52 | any MuPDF developers here? | 18:23.00 |
| | I was wondering if you could help me implement MuPDF in an iOS Project | 18:23.51 |
| tomty89 | https://itunes.apple.com/hk/app/mupdf/id482941798?mt=8 ? | 18:26.54 |
| qasim52 | The github project | 18:27.30 |
| | I want to use it as a PDF reader in a project I already made | 18:28.06 |
| | https://github.com/muennich/mupdf | 18:29.09 |
| | Do I just import all the files and try it from there?, I get a lot of compiler error | 18:45.38 |
| | s | 18:45.39 |
| | I can't seem to figure out how to integrate it with an already made project | 19:09.52 |
| | unless it's not built to be integrated in any projects | 19:15.52 |
| Robin_Watts | qasim52: hi | 19:16.13 |
| qasim52 | hi | 19:16.47 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 19:16.47 |
| qasim52 | kk | 19:17.04 |
| Robin_Watts | You certainly can use MuPDF within your own projects. | 19:17.12 |
| qasim52 | I'm having a lot of trouble with it then | 19:17.34 |
| Robin_Watts | We provide an example viewer for ios, that wraps the MuPDF library. | 19:17.44 |
| qasim52 | where's that? | 19:17.58 |
| Robin_Watts | Are you attempting to start from the viewer? Or are you writing your own app to call the library? | 19:18.01 |
| qasim52 | Writing my own app | 19:18.17 |
| Robin_Watts | platform/ios/ I would guess. I don't touch ios. | 19:18.24 |
| qasim52 | I tried that but couldn't go past it | 19:18.49 |
| | I got a load of compiler errors | 19:19.00 |
| Robin_Watts | You tried what and couldn't go past it? | 19:19.02 |
| qasim52 | I tried to replicate the sample project within my own app | 19:19.42 |
| Robin_Watts | Right. What sort of errors? Can you pastebin them? | 19:20.04 |
| qasim52 | just when it tries referencing frtiz.h | 19:20.57 |
| | one sec | 19:21.03 |
| Robin_Watts | qasim52: Well, unless I'm missing something obvious, it sounds like you've probably not got the include paths setup right. | 19:21.37 |
| qasim52 | wait maybe that would be it!, how would I set that up? | 19:22.04 |
| Robin_Watts | qasim52: FIIK. I won't touch xcode, it's horrible. | 19:22.27 |
| | But you almost certainly want to make sure that 'include' is on the include paths. | 19:22.58 |
| qasim52 | alright, I'll research a bit and see if that could be done | 19:23.35 |
| | yeahh you're right xcode isn't fun at all | 19:23.45 |
| | I'll try reimplementing it quickly | 19:24.38 |
| mvrhel_laptop | hi henrys | 21:59.39 |
| | did you see my email? | 21:59.44 |
| | Forward 1 day (to 2014/08/23)>>> | |
IRC Logs