| <<<Back 1 day (to 2012/09/20) | 2012/09/21 |
jbicha | can any one help me understand https://bugs.launchpad.net/bugs/1050602 ? imagemagick works if I use gs 9.05 but not 9.06 | 00:34.20 |
mvrhel | cool. I have the DeviceN output profile stuff working | 05:44.10 |
| it works even when the colorants are in or not in the source document. for example, if you have a output profile with Orange and Violet and those are not in the document you get seps for orange and violet | 05:44.58 |
| if they are in the document and the names all match then that works too (only one set of orange and violet seps) | 05:45.18 |
| plus you can with a simple #def setting restrict the output to only the colorants defined in the icc profile | 05:45.44 |
| or let all the spots go through | 05:45.57 |
| need to clusterpush to make sure nothing explodes | 05:46.24 |
| need to also get to work on being able to test these things in weekly manner | 05:59.43 |
| done for the night... | 06:02.21 |
tor8 | Robin_Watts: ping. | 07:53.31 |
| morning kens | 07:56.17 |
kens | HI tor8 | 07:56.26 |
| Copmputer habing a panic attack.... | 07:56.33 |
tor8 | oh⦠and here I was all happy that I was up before you! | 07:56.48 |
kens | Lol | 07:56.55 |
| I was here more than an hour ago | 07:57.05 |
| Then my primary and secondary displsy suddenly swapped. | 07:57.22 |
| Had to do some fiddling to put it back so I can work sensibly. | 07:57.41 |
tor8 | that's ⦠annoying I can imagine | 07:57.53 |
kens | Given they are different sizes and resolutions, yes :-) | 07:58.08 |
| I think my PC might be warning me its time I bought a replacement.... | 07:58.25 |
tor8 | kens: could be just the graphics card, but if your PC is older than mine (you said it was 5 years) then I think it's about time | 07:58.53 |
kens | Its a little over 5 years now | 07:59.06 |
| SO yes, probably past time, but I *hate* setting up a new system :-( | 07:59.23 |
tor8 | can't you reuse the hard drives? | 07:59.47 |
| or does windows go nuts if you change motherboard without reinstalling? | 08:00.04 |
kens | Yes, but its re-installing everything on Windows I dislike | 08:00.07 |
| And given that I'm planning quite a chnage, Windows woudl sulk I'm sure | 08:00.35 |
| Still, its one way to clean up Windows. | 08:01.16 |
tor8 | I made a habit to reinstall from scratch at least once a year so I kept my backups up to date so the pain when I'm forced to do a reinstall won't be so bad. | 08:01.22 |
kens | My backups are up to date, but since the introduction of the Registry, re-installing applications is essential. | 08:02.15 |
tor8 | the week after is frustrating though, when you run into all the annoyances and have to go into the control panel every few hours to change some stupid setting | 08:02.18 |
kens | I usually find its several months before I've re-installed all the tools I use 'sometimes' | 08:02.44 |
| On the plus side, I htink I've found a supplier that will build me a system the way I want it. | 08:03.19 |
tor8 | I just ordered new components to assemble a new system myself. Going to cannibalise some of the better parts that I recently replaced, like the passively cooled power supply and graphics card. | 08:04.54 |
kens | Yeah Robin_Watts said he builds his own system, but I cant be bothered these days. | 08:05.22 |
tor8 | well, Robin likes tinkering with toys :) | 08:05.51 |
kens | sigh, just been told the family PC isn't working.... | 08:05.56 |
tor8 | my sympathies... | 08:06.05 |
kens | It could be worse, it could be a 'my computer is broken' phone call from my father.... | 08:06.36 |
chrisl | Robin_Watts: (for the logs) If you prefer adding the -DAUX build flag to the stub definitions, I have no issue with that. If you want me to make the build changes, let me know and I'll do it on Monday | 08:38.10 |
chrisl | is off to get bored silly listening to someone drone on about mortgages, pensions, insurance...... <sigh> :-( | 08:40.38 |
Robin_Watts | pong | 09:22.02 |
| tor8: ^ | 09:22.13 |
tor8 | Robin_Watts: morning. a few outstanding things with mupdf I want committed before I go hide in gtk+ | 09:22.54 |
Robin_Watts | ok. | 09:23.04 |
tor8 | did you look at paul's latest master commits? | 09:23.12 |
| 1) update the camp and font files | 09:23.21 |
| 2) third party git submodules | 09:23.27 |
Robin_Watts | not yet, sorry. | 09:24.18 |
tor8 | I've written some scripts to check and compare unicode coverage for the fallback font with the CID cmap character sets | 09:24.29 |
| there is a DroidSansFallbackFull.ttf which adds 6k characters in the CJK Ext A block | 09:24.57 |
| and is 1.6M bigger | 09:25.03 |
| with that font, we're "only" missing about 4k characters that have encodings in the adobe cid cmaps | 09:25.57 |
| as opposed to 10k with the current droid sans fallback font | 09:26.10 |
kens | Maybe we should be adding the new one to GS too | 09:26.41 |
tor8 | you think it's worth taking the hit? I have no idea how common the cjk ext a block is, and I got no diffs on our sane tests | 09:26.45 |
Robin_Watts | tor8: How would you feel about a build switch? | 09:27.20 |
tor8 | Robin_Watts: ship both and #ifdef? | 09:27.48 |
Robin_Watts | yeah. | 09:27.52 |
tor8 | I have considered it | 09:27.59 |
| question is, will anyone care enough? | 09:28.13 |
Robin_Watts | CJK devs might :) | 09:28.36 |
tor8 | well, I think our default should be the big one if we're going to make it available | 09:28.56 |
| but it will bloat the binary a fair bit too | 09:29.31 |
Robin_Watts | yeah. For the PC we probably don't care. | 09:30.14 |
| For android, we could have the default the other way? | 09:30.25 |
tor8 | for android, maybe we should use the system shipped font instead? | 09:30.59 |
Robin_Watts | That would be a nice option, yes. | 09:31.10 |
tor8 | maybe even for iOS | 09:31.13 |
| given we can find a suitable font there | 09:31.24 |
| pdf_lookup_substitute_cjk_font can easily have a bit of #ifdef voodoo i it without complicating things too much | 09:32.08 |
Robin_Watts | sounds good. | 09:32.26 |
tor8 | oh, and I ought to update the iOS app yet again. damn new iPhone 5 has a different screen size | 09:33.04 |
| and no, I'm not capitalising those words manually | 09:33.13 |
| *grumbles about mountain lion* | 09:33.22 |
| takes forever to turn off the autospelling everywhere | 09:33.45 |
| Robin_Watts: two commits on tor/master | 09:36.59 |
Robin_Watts | Let me look at those now. | 09:47.12 |
tor8 | Robin_Watts: once those are ok:d I'll push the submodule commits to tor/master for review | 09:47.44 |
Robin_Watts | Have you looked at/pushed pauls? | 09:48.05 |
tor8 | Robin_Watts: I haven't | 09:48.26 |
Robin_Watts | ok, so you're pulling in the full fallback font with the second patch? | 09:49.15 |
| I worry that unconditionally including only the large one with bother people concerned with rom size. | 09:49.39 |
| s/with/will/ | 09:49.46 |
tor8 | Robin_Watts: alright, then I'll redo that one with an #ifdef which defaults to the big font | 09:50.07 |
Robin_Watts | cool. | 09:50.14 |
| Otherwise, I can see nothing to object to. | 09:50.29 |
| I'm looking at pauls stuff now | 09:53.06 |
tor8 | Robin_Watts: hmm, having both means messing with the pregen scripts though | 09:54.20 |
Robin_Watts | howso? | 09:54.32 |
tor8 | oh well, may as well generate both headers and just include one of them based on ifdef | 09:54.36 |
Robin_Watts | yeah, that sounds reasonable | 09:54.48 |
| OK, all Pauls commits look reasonable. | 09:58.31 |
| tor8: I'll push pauls, and the first of yours. | 09:59.03 |
| That'll keep the cluster busy for a bit :) | 10:02.55 |
tor8 | Robin_Watts: mudraw.c:285: warning: itneger constant is too large for 'long' type | 10:03.00 |
Robin_Watts | Is that your birthday? | 10:03.45 |
| yeah. | 10:03.58 |
| I probably need a cast in there. | 10:04.15 |
tor8 | oh noes, I'm too old! I overflow integers :( | 10:05.35 |
| tor/master updated with new fallback font ifdeffy stuff | 10:05.57 |
kens | Hmm, did someone change the output format of tiffsep ? | 10:07.34 |
| filenam format... | 10:07.41 |
Robin_Watts | tor8: Do we embed BOTH DroidSans and DroidSansFallback{,Full} ? | 10:31.54 |
| Doesn't DroidSansFallback include DroidSans ? | 10:32.06 |
tor8 | Robin_Watts: yes. droidsans has greek and cyrillic and extended latin. droidsansfallback doesn't have even full latin-1 | 10:32.31 |
Robin_Watts | OK, so they are complementary. | 10:32.54 |
| OK. so that looks fine. | 10:33.15 |
tor8 | yeah. I have thought about merging them into one, but the result always ends up bigger if I use fontforge to do it | 10:33.22 |
Robin_Watts | Are the submodules commits ready to go ? | 10:33.27 |
tor8 | Robin_Watts: I think so, if you have tested them | 10:33.38 |
Robin_Watts | I haven't. Will do so now. | 10:33.47 |
| No thirdparty v8. | 10:35.13 |
tor8 | no, I left that one out of it | 10:35.26 |
| it's too big to include by default, IMO | 10:35.35 |
| we may want to do v8 as tarball snapshots to keep the size of what you need to git clone down | 10:36.47 |
Robin_Watts | tor8: Or we can leave it as is (where people download prebuilt bins for their OS/target) | 10:38.17 |
tor8 | yeah | 10:38.40 |
Robin_Watts | oh gawd. This is going to mean cluster hackery. | 10:49.10 |
tor8 | Robin_Watts: yeah. take your time. I'm going AFK for a bit, heading to the post office. back in a while. | 10:49.58 |
Robin_Watts | I may not have the strength for that today. | 10:50.13 |
| Urm... | 10:51.17 |
| Did you actually add DroidSansFallbackFull.ttf? | 10:51.47 |
| yes. So where has it gone in my local version? | 10:52.28 |
| my bad. | 10:59.29 |
| tor8: The v8 project hadn't been updated. I've fixed that here. | 11:13.16 |
| restarting chatzilla. | 11:16.28 |
| How strange. Something in the dashboard is sorting the jobs into a screwy order. the cluster queue internally has it right | 11:18.23 |
| That's better. | 11:23.58 |
kens | aha mvrhel ping | 11:40.16 |
miha_ | would anyone know, when mupdf android app calls public static native boolean authenticatePasswordInternal(String password); what encoding is actually used to decrypt pdf? utf-8? | 11:57.17 |
| i guess it get byte[] from String and use it as (AES) key? | 11:58.24 |
Robin_Watts | miha_: that sounds plausible. | 12:00.30 |
miha_ | :D | 12:00.40 |
Robin_Watts | I don't think there is any utf8 gubbins in there. | 12:00.44 |
| raw byte values, I think. | 12:00.52 |
miha_ | well String's getBytes return byte[] in platform's default encoding. getBytes(String encoding) returns byte[] in given encoding | 12:02.19 |
| i only tried english letters and numbers so far :) | 12:02.29 |
| it works. | 12:02.53 |
| i ask, cause iText asks for byte[] key at encrypting pdf... http://itextpdf.com/examples/iia.php?id=219 | 12:04.18 |
Robin_Watts | Same set of bytes then, I'd assume. | 12:05.46 |
miha_ | not necessarily, if itext generates encrypted pdf on PC and mupdf reads it on android | 12:06.34 |
| or windows/linux combo | 12:06.46 |
| for me, windows uses CP1250 encoding, linux uses utf-8 (on another linux, it would be iso latin 2) | 12:07.56 |
| english letters and numbers are safe, though :D | 12:08.21 |
Robin_Watts | encryption is done based on raw byte values. | 12:08.42 |
| i.e. unencoded. | 12:08.49 |
| So it's certainly not expecting utf8 etc. | 12:09.56 |
miha_ | yes, but native function accepts String, not byte[].. and i'm not yet comfortable with reading mupdf lib :) | 12:10.12 |
Robin_Watts | miha_: That may well be my fault, as I'm not comfortable with the java bits of android :) | 12:11.14 |
miha_ | MuPDFCore.java, public static native boolean authenticatePasswordInternal(String password); | 12:11.25 |
| :D | 12:11.30 |
Robin_Watts | lunchtime. | 12:12.09 |
tor8 | miha_: the PDF spec is very vague, so if you use non-ascii characters in a password in an encrypted PDF, you're probably going to be unable to open it on any other system than the one you created the PDF on. | 12:13.36 |
miha_ | tor8: you have a point. is there any limit on password length? is it used directly as key, or hashed first? | 12:18.14 |
tor8 | miha_: it's hashed, so no limit on length | 12:18.59 |
miha_ | thank you a lot! | 12:20.47 |
tkamppeter | Can someone look at http://bugs.ghostscript.com/show_bug.cgi?id=693348, this is a major problem in our Ubuntu Quantal release. | 14:10.42 |
kens | Give me a minute | 14:11.46 |
jbicha | tkamppeter: thanks! | 14:11.47 |
Robin_Watts | tkamppeter: Debug build works under windows for me. | 14:13.00 |
kens | Me too, let me try the release code | 14:13.38 |
| Robin_Watts : release build of 9.06 under WIndows seg faults. | 14:14.29 |
| That's the actual released code. | 14:14.44 |
| Let me try a release build of current code | 14:14.52 |
Robin_Watts | kens: OK. Let me try a profile build. | 14:14.58 |
kens | needs to do a rebuild... | 14:15.10 |
chrisl_away | 9.06 is crashing in the image interpolation code - so it's probably fixed | 14:15.19 |
kens | Ah, thought you weren't here chrisl | 14:15.32 |
chrisl_away | Just passing through...... | 14:15.40 |
| I'm heading out again in 15-20 minutes | 14:16.10 |
kens | Robin_Watts : your ifx of 20-08-2012 looks plausibl;e | 14:16.12 |
Robin_Watts | kens: What SHA? | 14:16.27 |
kens | 1 sec | 14:16.47 |
| d527eade5778811475ea8be4cbba4eeec573b28a | 14:16.56 |
| setting -dNOINTERPOLATE to the 9.06 release works fine. | 14:17.09 |
Robin_Watts | yeah. tkamppeter, you could try applying this patch and see if it solves it: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=d527eade5778811475ea8be4cbba4eeec573b28a | 14:18.18 |
kens | If that's the culprit its a very simple patch | 14:18.24 |
chrisl_away | tkamppeter, kens, Robin_Watts: yep, d527ead fixes the crash for me | 14:19.55 |
kens | Thoguht it might | 14:20.33 |
| Current code is OK in debug and release versions. | 14:20.57 |
chrisl_away | I can't believe I'm having to do a special build of GS for Gemma for output file names - I mean.... really?!?!? | 14:21.34 |
kens | What can I say.... | 14:21.46 |
| As I said in my mail, its a pity they won't do builds themselves. | 14:22.15 |
Robin_Watts | chrisl: I think you should say no. | 14:22.16 |
| It's reasonable for us to do builds if there are crashes. | 14:22.34 |
chrisl_away | Marcos has already told her we're doing it..... | 14:22.40 |
kens | must have missed that email | 14:22.58 |
Robin_Watts | It's unreasonable of them to expect us to rebuild to avoid them having to change their app. | 14:23.01 |
| me too. | 14:23.04 |
kens | Also, I'm not happy about sending that change without Michael saying why he changed it. | 14:23.23 |
| Perhaps it was an oversight, but maybe it was something else. | 14:23.44 |
chrisl_away | No, we discussed it, and everyone involved agreed the tiffsep1 names made much more sense | 14:24.13 |
kens | Really ? My memory must be worse than usual. | 14:24.29 |
tkamppeter | Robin_Watts, thank you very much, the patch fixes it for me. | 14:25.06 |
chrisl_away | kens: Well, maybe you weren't "involved" - but including the plate name in the output file name seems pretty sensible to me! | 14:25.20 |
Robin_Watts | tkamppeter: You're welcome. | 14:25.33 |
| (kens found the patch :) ) | 14:25.43 |
kens | chrisl_away : sure, but chaning the '.' to a '(' seems less so. The code looks to me like process names were supposed to be name.process.tif and seps name(sep).tif, but that's not how it actually works. | 14:26.30 |
chrisl_away | kens: true, but thought the change was just to "how the tiffsep1 naming works". Still, it shouldn't be beyond your average bear to handle a file name change! | 14:28.25 |
kens | Ah, marcos' mail just arrived | 14:28.41 |
| Oh God and a question about yet another format of PDF/A I've never heard of | 14:28.57 |
chrisl_away | I still have the source archived for the last build I did for Gemma, but it will still have to wait until Monday...... | 14:29.17 |
kens | Well, that's what Marcos told her | 14:29.32 |
| Crumbs tkamppeter beat me to closing the bug report :-) | 14:30.42 |
| Thanks Till | 14:30.47 |
chrisl_away | kens: Hmm, I had it in my mind that Gemma's company was a support only customer, but her mail sounds like distribution | 14:32.32 |
kens | chrisl Yes I wondered about that. | 14:32.46 |
| They are definitely support only | 14:32.55 |
chrisl_away | Might worth pinging Miles on it? | 14:33.13 |
kens | I could be the 'English as a foreign language' thing | 14:33.14 |
Robin_Watts | Gemma is from Leeds :) | 14:33.23 |
kens | Yeah but her mail was described as 'Chinglish' by her | 14:33.35 |
| Sorry that was another mail | 14:33.55 |
Robin_Watts | It sounds to me like they are wrapping gs in an app and distributing it. | 14:34.05 |
| Possibly having the app done by someone in china. | 14:34.25 |
kens | It could be an in-house thing, so no distribution | 14:34.40 |
| Not obvious to me, maybe Miles/Scott know | 14:34.53 |
chrisl_away | "some customers are not able to move to a new version of the app" doesn't sound "in-house", to me. | 14:35.29 |
Robin_Watts | She keeps talking about... what chrisl said. | 14:35.37 |
kens | I'd have to agree | 14:35.41 |
tor8 | Robin_Watts: so you good with the submodule stuff now, or the cluster needs more work? | 14:35.46 |
Robin_Watts | tor8: I have a version locally that works. | 14:35.57 |
kens | chrisl punt it to Miles, I have to go and read an ISO spec :-( | 14:36.03 |
chrisl_away | kens: could you do me a favour, and mail Miles - I really have to head out again | 14:36.27 |
Robin_Watts | tor8: I haven't pushed it because I haven't looked at the cluster yet, and I'm deeply into gs/lcms stuff at the moment. | 14:36.33 |
kens | chrisl OK | 14:36.41 |
tor8 | Robin_Watts: okay, no rush | 14:36.49 |
chrisl_away | thanks - off now! | 14:37.00 |
Robin_Watts | I've got Radu talking me on skype at the moment. | 14:37.05 |
| He wants to know if mupdf supports the use of thumbnails for fast rendering. | 14:37.21 |
tor8 | I've always skipped over the parts of the spec that talk about thumbnails | 14:38.01 |
Robin_Watts | I said no. | 14:38.05 |
| I dealt with thumbnails at Picsel. | 14:38.13 |
| We *could* do a 'getPageThumbnail' call that returned a pointer to the jpeg data if there was one. | 14:38.30 |
| but that's nasty, as it means that callers have to cope with decoding/scaling/rendering etc. | 14:38.56 |
| A better approach might be to do 'getDisplayListFromThumbnail" that returned the thumbnail data as a displaylist, so they can render it all with the same calls that they would use to render normal pages. | 14:39.42 |
| Anyway, not proposing to code it now, just thought I'd mention my thoughts. | 14:40.06 |
ray_laptop | Robin_Watts: so the display list would just be the image ? | 14:40.14 |
tor8 | Robin_Watts: well, if (and that's a big if) we do it I'd suggest having a run_thumbnail_page call which mirrors the normal run_page call | 14:40.19 |
Robin_Watts | ray_laptop: Yes. | 14:40.20 |
| tor8: right. | 14:40.40 |
tor8 | but uses the thumbnail if available | 14:40.44 |
| and maybe sets some flags to skip images or something else if there is no thumbnail | 14:41.03 |
| like text "greeking" and skip color conversions and draw images as solid blobs | 14:41.27 |
Robin_Watts | I think we'd be better with a scheme that just didn't render anything if no thumbnail available. | 14:41.42 |
tor8 | but I wouldn't recommend it | 14:41.43 |
Robin_Watts | The purpose of this would be so that if you load a document in a viewer that can show all the pages, it can quickly show the thumbnail before doing the (slow) rendering. | 14:42.19 |
ray_laptop | Robin_Watts: I would think that would be enough, since the app can always decide to render the contents to a thumbnail sized image, right ? | 14:42.33 |
| Robin_Watts: but if the PDF didn't have thumbnails, that would be slower | 14:43.00 |
Robin_Watts | I'm confused as to what you're agreeing with ray. | 14:43.20 |
tor8 | ray_laptop: I think that's what apple's preview does, creates thumbnails on the fly if they aren't embedded. it's very slow and can cause big hickups | 14:43.33 |
Robin_Watts | My proposal is that there would be some call to 'render page from a thumbnail', that would render using the thumbnail if present (hopefully fast), and if no thumbnail present would do nothing. | 14:44.23 |
| That way any app can quickly get thumbnails (or create blank pages for itself). | 14:44.57 |
ray_laptop | tor8: right, so you agree that _we_ should not (by default) provide a thumbnail by rendering the contents. We only 'get' the thumbnail image | 14:45.16 |
Robin_Watts | tor8's suggestion of doing a 'low quality' render bothers me, as I fear that may be almost as slow as doing it properly (what will file reading etc) | 14:45.40 |
tor8 | I'm with Robin_Watts here, creating a thumbnail behind the scenes will be slow and not what I want to see in an app | 14:45.43 |
Robin_Watts | Right. | 14:45.51 |
ray_laptop | Robin_Watts: I thought you proposed getting the thumbnail as a display list (pootentially empty) | 14:46.01 |
tor8 | it's just what I've seen other viewers do, and I don't like it | 14:46.02 |
Robin_Watts | ray_laptop: If the thumbnail exists, get a display list with it in. Otherwise return nothing. | 14:46.29 |
ray_laptop | if we leave the choice of (painfully slow) rendering thumbnails to a thumbnail sized pixmap, then the app can decide if, or when to do it | 14:47.09 |
Robin_Watts | or perhaps better, as tor8 said, do a 'render thumbnail' call, that might return 'no thumbnail to render'. | 14:47.26 |
ray_laptop | Robin_Watts: that's fine, too (I assume return "nothing" is NULL) | 14:47.42 |
| if we wanted to make it nice for an app, the render_thumbnail could take an argument that enables 'slow' rendering | 14:48.51 |
tor8 | void fz_run_thumbnail(â¦same arguments as fz_run_pageâ¦, int skip_if_no_thumbnail_available) | 14:49.28 |
ray_laptop | the app could then still decide if it just wanted to disable slow rendering (when thumbnails not present) and show blank pages, | 14:49.34 |
| tor8: int not bool ? | 14:49.52 |
tor8 | ray_laptop: c89, no 'bool' type | 14:50.00 |
ray_laptop | tor8: I'm used to gs where we have 'bool' used (even though it is typedef'ed to int) | 14:50.49 |
tor8 | ray_laptop: we don't want to pollute the global namespace in mupdf, so no 'byte' or 'bool' typedefs | 14:51.18 |
ray_laptop | tor8: I applaud that approach | 14:51.52 |
Robin_Watts | OK, thumbnails aren't only jpegs, so the displaylist approach is the right one. | 15:00.21 |
| (displaylist or a function to render them, rather, not returning the data) | 15:00.38 |
mvrhel | hmm it does sound like Gemma's company is shipping an app | 15:15.32 |
kens | THeir app presumably uses GS by forking or similar | 15:15.50 |
| So they can ship GS separately | 15:15.59 |
| Or have their customers download it | 15:16.05 |
sebras | tor8: except in draw/*.c | 15:16.06 |
kens | I have done as chrisl asked and mailed Miles and Scott | 15:16.18 |
tor8 | sebras: what's that? | 15:16.19 |
mvrhel | for all the work we do for them, that is sleazy | 15:16.35 |
sebras | tor8: typedef ... byte; | 15:16.46 |
kens | I'm inclined to agree mvrhel | 15:16.49 |
tor8 | sebras: not visible outside the compilation unit. | 15:17.00 |
sebras | still! | 15:17.06 |
mvrhel | bbiaw | 15:17.11 |
Robin_Watts | They can't be having users download gs. | 15:17.55 |
| because we are giving them custom *commercial* builds, not custom *gpl* builds. | 15:18.16 |
| So if they have 'customers' to which they are giving our builds of gs, then they are distributing it, and are not covered by their license. | 15:19.15 |
kens | Robin_Watts : I've passed it to Miles and Scott | 15:19.42 |
| Maybe they know what's going on and are happy, maybe not | 15:19.53 |
| Main thing is for us to keep Miles and Scott informed I think | 15:20.26 |
| I'll foraward what I sent them to support | 15:21.30 |
henrys | I don't even know what A-2U is, better look it up. | 15:25.37 |
kens | PDF/A with Unicode | 15:26.12 |
| I've just read the spec again | 15:26.15 |
henrys | kens:ah thanks for the email answer | 15:26.21 |
Robin_Watts | kens: (and anyone else) When you forward such things to miles/scott in future could you copy tech in please? That way 1) we all know that it's been done, and 2) we can see what they say in response. | 15:27.03 |
kens | Robin_Watts : in this case chrisl asked me to do the mail here.... | 15:27.23 |
| I usually copy support, not tech though | 15:27.36 |
Robin_Watts | OK. support would be better, probably. | 15:27.51 |
henrys | that's what we agreed to do send stuff off to miles and scott and cc support and scott should do the same when he writes to the customer. | 15:30.54 |
Robin_Watts | And kens email has just arrived. Sorry, I thought it hadn't got copied. | 15:31.39 |
kens | I do forget sometimes :-( | 15:32.16 |
| OK Goodnight all | 16:39.02 |
| have a good weekend | 16:39.07 |
henrys | I'll be headed out for a longish bike ride today and will work this evening instead I'll be reachable by cell. | 16:43.53 |
mvrhel | road or mt bike? | 17:15.38 |
henrys | road I haven't mt biked in some time now. | 17:16.12 |
mvrhel | have a good ride | 17:16.31 |
henrys | thanks | 17:16.44 |
frafl | Hello, is there anybody from the mupdf team? | 18:36.54 |
Robin_Watts | sure. | 18:42.12 |
frafl | I want to ask two things | 18:44.55 |
| 1. If I use pdf_write_document, shall I set the locale to "C" beforeor ? Otherwise it writes "," for floats instead of ".". | 18:47.52 |
| Or is this a bug in pdf_object.c ? | 18:48.27 |
Robin_Watts | That's probably a bug, yes. | 18:49.30 |
frafl | This (of course) only happens, if my normal locale is not US English. | 18:49.53 |
ray_work | frafl: we have customers and users worldwide, so avoiding locale problems is important to us. | 18:51.35 |
frafl | The second one: Could you point me to the place where the annotation rendering happens (especially InkAnnotations)? | 18:51.47 |
| I create ink annotations with your lower level API and can see them afterwards in Poppler and Preview (OS X) and now I'd like to modify my code, so that I can see them in mupdf too. | 18:53.58 |
Robin_Watts | So are you creating appearance streams? | 18:56.16 |
frafl | No | 18:56.30 |
Robin_Watts | If you're creating appearance streams, then we should render them already. | 18:56.31 |
| If not, then you need code to synthesis appearance streams from the annotations. | 18:56.53 |
| What version are you using? the release version (1.1?) or git ? | 18:57.07 |
frafl | git, 3 or 4 days old | 18:57.29 |
Robin_Watts | the latest git code includes some support for forms. As part of that we have some annotation synthesis, but not for all types. | 18:57.49 |
ray_work | I don't think gs _or_ mupdf does the 'Inklist" (Ink) annotations | 18:59.21 |
frafl | ah ok, but if it's no bug (e.g. missing value) in my code, i can render the annotations using Qt | 18:59.33 |
Robin_Watts | IF you look in pdf_load_annots (pdf_annot.c) you'll see that we read the AP and AS entries. | 18:59.46 |
| Yeah, we call pdf_update_appearance there. | 19:00.25 |
ray_work | frafl: generally, AP (apperance streams) are more versatile and most widely supported by viewers (even old versions) | 19:00.30 |
Robin_Watts | That is where you'd do appearance synthesis. | 19:00.38 |
| At the moment we only handle checkboxes, listboxes/comboboxes and test widgets. | 19:01.11 |
| You could extend that code to do your stuff too. | 19:01.20 |
ray_work | frafl: generating an AP with moveto/lineto/curveto/stroke instead of an Inklist should be easy | 19:01.31 |
Robin_Watts | ray_work: Nicest solution (from our point of view) would be to add synthesis code that converts from inklist to a stream of pdf operators. Then we'd cope with pdfs with inklists in. | 19:02.33 |
ray_work | frafl: relying on "implementation dependent" rendering of annotations will not be portable. "Stamp" annotations is another one to be avoided | 19:02.39 |
| Robin_Watts: I was mainly recommending what's best for generating more "portable" PDF that looks the same across the widest range of rendering engines | 19:03.35 |
| Robin_Watts: for mupdf and gs, I agree, converting the inklist into moveto/lineto/stroke, etc. would not be too hard, but then people will say "It doesn't look like ___ (Acrobat or other PDF renderer)" | 19:04.58 |
frafl | ah, so the annotation is just a "hint", if there is now apperance stream? | 19:05.36 |
| appearance streams | 19:06.15 |
| appearance stream | 19:06.18 |
ray_work | Robin_Watts: particularly Ink which seems VERY vague in the spec. Linewidth seems particularly ill-defined (unless I missed something) | 19:07.50 |
| frafl: AP/AS aren't totally foolproof since the spec says "handlers may ignore this entry and provide their own appearances", but they generally are respected for 'static' annotations. Annotations that are interactive -- all bets are off. | 19:09.41 |
frafl | Ignoring them was what I did, when I read the specs :) | 19:10.59 |
ray_work | frafl: and some renderers generate the appearance when viewing, but use the AP when printing. | 19:11.55 |
| frafl: but you also ignored all the warnings "implementation dependent" ;-) | 19:12.20 |
| the Endeavor shuttle is flying by shortly. Going outside to watch it... | 19:13.00 |
| frafl: but if you want to add synthesis code to mupdf to draw the Inklist -- great! | 19:13.53 |
frafl | @ray_work: No, I read them: not as a warning, but as a license to implement them quite freely (on the reading side) | 19:15.22 |
ray_work | Robin_Watts: I was wrong above, ghostscript _does_ handle InkList (.pdfinkpath). Just uses linewidth 1 and 1 linecap 1 linejoin | 19:16.37 |
| but ghostscript gives priority to the AP if present in the Ink annotation | 19:17.06 |
| frafl: wide open implementation includes doing nothing :-) | 19:18.04 |
frafl | I'll look at it -- i will probably not use that myself, since I render the page to an image and like to change the paths afterwards, without rerendering the entire page | 19:18.27 |
| @ray_work: Too open to be useful as a note-taking app ;) | 19:19.54 |
ray_work | frafl: the AP spec says that you implementations may ignore the AP as long as they provide their own appearance, so presumably that implies that providing a 'nothing' appearance doesn't qualify the intent of the spec | 19:20.07 |
frafl | I have to go and eat something, thanks for your great help! | 19:22.45 |
sebras | I'm still amazed at how much interest there is for PDF annotations... I wonder why..? | 20:02.38 |
| are people often scribbling notes in their pdfs or what's the use case? | 20:03.06 |
| Forward 1 day (to 2012/09/22)>>> | |