| | <<<Back 1 day (to 2012/08/07) | 2012/08/08 |
| mvrhel_laptop | henrys: are you there? | 02:35.23 |
| | ah never mind henrys I got it figured out | 02:48.22 |
| kens | chrisl did you see the latest 'issue' on the FreeType devel mailing list ? Looks like someone else has found a font which behaves differently with non-zero and even-odd windings. | 07:01.15 |
| chrisl | kens: no, I haven't looked for a while - I'll read up.... | 07:10.49 |
| kens | I just saw it in the mail this morning | 07:11.04 |
| | There's an attached PDF but I haven't tried it yet | 07:11.27 |
| | Yes, GS draws it differently to Adobe Acrobat, and it does indeed look like a widing rule problem | 07:12.19 |
| | The font claims to be Copyright Adobe too, which is pretty poor | 07:13.19 |
| chrisl | I guess I'll reply to the list about it..... | 07:13.48 |
| kens | I have some doubts about that copyright notice though | 07:13.48 |
| chrisl | It might be an Adobe tool that created it - which is equally poor.... | 07:14.37 |
| kens | Maybe, but I'm suspicious, it doesn't look entirely like a real Adobe copyright | 07:15.02 |
| | I thuink I just found my seg fault problem.... | 07:16.20 |
| chrisl | Okay, freetype-devel replied to..... | 07:28.20 |
| kens | Hmm, well that reduced the number of seg faults, by 2000 but there's obviously still something wrong... | 08:09.29 |
| Robin_Watts | Morning tor8 | 09:38.13 |
| tor8 | morning Robin_Watts | 09:38.20 |
| Robin_Watts | There are a couple of things on my repo for review. | 09:38.44 |
| | including the change to the new thirdparty stuff. | 09:38.59 |
| | which all tests out fine (372 freetype differences is all) | 09:39.23 |
| tor8 | Robin_Watts: the try/catch overflow solution is pretty neat | 09:41.14 |
| Robin_Watts | yeah, pleased with that. | 09:41.27 |
| tor8 | I don't see anything obviously bad with the others, but I'm not familiar with the linearisation code (and I'd prefer to remain ignorant, considering your and ken's and of late sebras' swearing) | 09:42.53 |
| | do you want me to upload a new thirdparty zip? | 09:43.21 |
| Robin_Watts | It may not be perfect, but it's a definite progression. | 09:43.28 |
| tor8 | http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html is a bit of interesting news | 09:43.44 |
| Robin_Watts | http://ghostscript.com/~robin/mupdf-thirdparty-2012-08-06.zip | 09:43.54 |
| | When we commit the thirdparty change, we should make that zip file live, yes. | 09:44.16 |
| tor8 | is the mupdf-thirdparty.zip really supposed to have *both* openjpeg-1.5.0 and openjpeg-1.5.0-patched? | 09:46.09 |
| Robin_Watts | tor8: bugger. | 09:46.19 |
| | New version uploading now. | 09:48.41 |
| | tor8: Can you look at Babur's emails to support please? | 09:52.25 |
| tor8 | int'l language support? | 09:52.56 |
| Robin_Watts | I suspect the answer is "the usual app does not support the input methods required, but the underlying code does (as evidenced by the fact the iOS app manages it)." | 09:53.01 |
| | yeah. | 09:53.03 |
| tor8 | the x11/win32 viewer doesn't support fancy text input | 09:53.35 |
| | so your suspicion is correct | 09:53.47 |
| Robin_Watts | OK. I'll send that reply, thanks. | 09:54.01 |
| | If you see me say anything stupid, please speak up :) | 09:54.11 |
| tor8 | it's all due to a lack of using a proper toolkit and being lazy when implementing the text search field | 09:54.24 |
| | speaking of search, the android app should respond to the physical search button as well. is paulgardiner available to work on the android app any more? | 09:55.28 |
| Robin_Watts | tor8: I believe so (it'd just cut into his forms time) | 09:56.12 |
| tor8 | good to know. | 09:58.09 |
| | Robin_Watts: right, so now you've got doubles of all the other source trees instead in the thirdparty zip :) | 10:00.31 |
| | Robin_Watts: does http://ghostscript.com/~tor/mupdf-thirdparty-2012-08-06.zip work for you? | 10:01.32 |
| Robin_Watts | I may just go back to bed :) | 10:01.35 |
| | Looks good to me. | 10:02.32 |
| pipitas1 | chrisl_away: Re. your mail to freetype-devel: You don't need access to CPSI - Acrobat X will do (maybe even Reader, and earlier versions to). You zoom into the 'd' far enough and you'll see the effect (tripping point is 930% -> 931%). | 10:12.25 |
| | Cool thing: someone started to put all German laws into Github using markdown text formatting. Now you can track how the powers that be change the rules: https://github.com/bundestag/gesetze | 10:17.00 |
| Robin_Watts | tor8: So, should I push those commits to the golden repo? | 10:37.19 |
| | (or at least, all but the thirdparty ones?) | 10:37.54 |
| | s/ones/one/ | 10:38.18 |
| tor8 | Robin_Watts: go ahead and push | 10:39.08 |
| | I'll repoint the mupdf-thirdparty.zip symlink | 10:39.30 |
| Robin_Watts | All but the thirdparty one pushed. | 10:41.40 |
| | I need to check what needs to be done in the cluster to make it spot the new thirdparty before I push the last one. | 10:41.55 |
| tor8 | Robin_Watts: if the cluster is using the unix makefile, nothing should need to be done if it downloads and unzips the thirdparty zip in a clean directory each time | 10:43.05 |
| | if it unzips in a dirty thirdparty directory, it'll get confused by seeing multiple versions of each lib | 10:43.26 |
| Robin_Watts | right. Where/When it downloads is what I need to check. | 10:43.37 |
| tor8 | Robin_Watts: okay, for after the release we need to sort the thirdparty stuff using git submodules I think | 10:43.56 |
| Robin_Watts | ok, it downloads it each time, checks the date stamp, and if newer, cleans and unzips. | 10:45.17 |
| sebras | tor8: did you assign the android bugs to paul? | 10:46.11 |
| | tor8: you asked me to do it but I reported lacking permissions to do so. | 10:46.34 |
| Robin_Watts | tor8: Do you need anything from me for the release? | 10:47.54 |
| sebras | hi paul! | 10:49.59 |
| paulgardiner | hi sebras | 10:50.10 |
| Robin_Watts | paulgardiner: tor8 said earlier: "speaking of search, the android app should respond to the physical search button as well. is paulgardiner available to work on the android app any more?" | 10:50.18 |
| | paulgardiner: You probably want to merge master to forms again and grab a new thirdparty.zip from mupdf.com/download | 10:51.18 |
| | That way you should get fewer diffs when you cluster test. | 10:51.32 |
| sebras | paulgardiner: Robin_Watts is ahead of me. also if you want to there are a few mupdf/android bugs I filed for you. :) | 10:52.13 |
| paulgardiner | I'm happy to work on the android app, provided henrys is happy for me to take the time away from forms. I can't see its being a big job. | 10:52.27 |
| | sebras: ah right. Thanks. I can look into those too. | 10:53.02 |
| sebras | paulgardiner: you're welcome. I'm always happy to create more work for others. ;) | 10:53.52 |
| paulgardiner | sebras: very altuistic. :-) | 10:54.53 |
| | sebras: I'm having trouble repeating the behaviour described in the first part of 693228. So for you, does the 2nd page just disappear while performing Step 6? | 11:11.02 |
| sebras | paulgardiner: yes, but that is not a bug. | 11:32.57 |
| | paulgardiner: I'm just dragging with my finger until page two is no longer visible. | 11:33.14 |
| | paulgardiner: the intent is to show that it is possible to drag back and forth between pages in steps 5 and 6, while in step 10 you can not drag back and forth between pages. | 11:33.55 |
| | paulgardiner: does my description make sense to you? | 11:34.21 |
| paulgardiner | Ah sorry. I get it now. | 11:34.24 |
| sebras | paulgardiner: no problem. it's kind of hard to describe UI inputs concisely and in an easy to understand way. :) | 11:35.27 |
| paulgardiner | Actually the bugged behaviour is a side effect of something intentionally added to avoid zooms causing page flicks. I wonder if there is another way to avoid the flicks but still allow dragging. | 11:36.33 |
| | sebras: that was the only description I had trouble it, and I think it was more me than the description. :-) | 11:37.15 |
| sebras | paulgardiner: cool, so you can reproduce all the issues? some of those bugs you might just be able to close with a statement that it works as we expect it to. I just wanted to mention it so that we take conscious decisions. | 11:45.20 |
| paulgardiner | Yes. All make sense. It would be nice to fix them all - but some might require heroic measures not worth the reward. Either way, good to have them documented and considered, as you say. | 11:48.44 |
| sebras | paulgardiner: cool. I have never really looked at the android code so I'm really just reporting these as a plain user. | 11:50.28 |
| paulgardiner | Best that way I think. I reckon whether to consider something a bug shouldn't be decided on the basis of how hard it is to fix or what caused it. | 11:52.12 |
| kens | Hmm, well that's another 4000 seg faults squashed, only 1200 to go :( | 11:53.09 |
| paulgardiner | kens: Sounds like you are winning at least. | 11:54.44 |
| kens | paulgardiner : yes, its progress, even if it is slow :-) | 11:58.23 |
| sebras | paulgardiner: ah, no that's true but usually I attempt to solve the problems I find, but there's just too much preparations for me to solve issues in android for now. | 11:58.41 |
| kens | And this is just the framework, I haven't actulaly written the linearised file back yet.... | 11:58.59 |
| Robin_Watts | The only way to "win" with linearisation would be to travel back in time and nuke the hometown of the guy that invented it from orbit. | 11:59.50 |
| | It's the only way to be sure. | 11:59.55 |
| paulgardiner | I bet that guy got ideas for linearised pdf from technology also sent back in time - probably from the severed arm of an android or similar. | 12:02.02 |
| | Robin_Watts: both master and forms have introduced AR_CMD in the MuPDF Makefile, but slightly differently. One uses cr the other cru. | 12:03.10 |
| sebras | paulgardiner: yeah, that's my change. | 12:04.50 |
| kens | Its not possible to travel back in time and nuke idiots form orbit, the Doctor won't let you :-( | 12:05.04 |
| sebras | paulgardiner: if you get merge issues your're supposed to use the one with only cr. | 12:05.05 |
| paulgardiner | kens: Surely in this particular case he'd make an exception. | 12:06.14 |
| kens | Mayeb he could be persuaded... | 12:06.37 |
| | The guy was clearly influenced by Daleks | 12:06.58 |
| | Or possibly Cybermen | 12:07.06 |
| paulgardiner | sebras: Ok. The u looks slightly odd to have in a build command. | 12:09.13 |
| | Robin_Watts: Done the merge and downloaded the new thirdparty. Getting Cannot open include file: 'ft2build.h'. Any idea what I might have forgotten? | 12:46.09 |
| | Oh. Probably I need to take over windows build changes from mupdf target to mupdf-v8 | 12:47.57 |
| Robin_Watts | Yes, the include paths have changed. | 12:51.36 |
| paulgardiner | ah right. Makes sense. | 12:55.13 |
| Robin_Watts | mvrhel_laptop: Morning | 13:03.13 |
| mvrhel_laptop | Robin_Watts: thanks for taking a look at the gximono to cmyk issue | 13:03.15 |
| Robin_Watts | the current code is broken. | 13:03.26 |
| | I've got a cutdown file that shows it. | 13:03.34 |
| mvrhel_laptop | ok great | 13:03.37 |
| Robin_Watts | and I've isolated part of what the problem is. | 13:03.49 |
| | When you get started properly, let me know, cos I'd like to talk it through with you. | 13:04.45 |
| mvrhel_laptop | ok lets do it now | 13:04.55 |
| Robin_Watts | ok. In gxht_thresh_planes | 13:05.06 |
| | (in gxht_thresh.c) | 13:05.15 |
| mvrhel_laptop | ok | 13:05.34 |
| Robin_Watts | We call: (*dev_proc(dev, copy_planes)) (dev, penum->ht_buffer, xoffs, dithered_stride, | 13:05.40 |
| | gx_no_bitmap_id, x_pos, y_pos, | 13:05.42 |
| | curr_width, vdi, vdi); | 13:05.44 |
| | line 972ish. | 13:05.47 |
| | In the case I have here, vdi is 1. | 13:06.08 |
| mvrhel_laptop | I am there | 13:06.13 |
| Robin_Watts | This means that we expect to get the first planes data from penum->ht_buffer, the second planes data from penum->ht_buffer + dithered_stride, etc. | 13:06.49 |
| mvrhel_laptop | right h is the plane_height | 13:07.14 |
| Robin_Watts | but at line 888, we put the first planes data into halftone, where: | 13:07.30 |
| | halftone = penum->ht_buffer + j * penum->ht_plane_height | 13:07.43 |
| | and penum->ht_plane_height != dithered_stride | 13:07.58 |
| mvrhel_laptop | ok that is an issue.. | 13:09.34 |
| Robin_Watts | I'm thinking that we should calculate: | 13:10.43 |
| | halftone = enum->ht_buffer + j* vdi *dithered_stride | 13:10.59 |
| mvrhel_laptop | yes that would make more sense | 13:12.18 |
| Robin_Watts | That does seem to solve the issue for this particular cutdown file. | 13:13.15 |
| mvrhel_laptop | I wonder why this works though in the case when we are going from cmyk to the plank devoce | 13:13.15 |
| Robin_Watts | but it wouldn't surprise me to find there are other cases where it doesn't. | 13:13.57 |
| mvrhel_laptop | oh | 13:14.37 |
| Robin_Watts | I've just scheduled a cluster job to test this. | 13:16.09 |
| | gonna grab some lunch while I wait for it to run unless you have any other thoughts? | 13:16.50 |
| mvrhel_laptop | Robin_Watts: ok. I don't want to eat up your time on this. I can work on getting it fixed since it is my issue | 13:17.01 |
| | I don't have any thoughts now. but can you send me the file that you have cut down? | 13:17.32 |
| Robin_Watts | http://ghostscript.com/~robin/ht.pdf | 13:18.22 |
| mvrhel_laptop | thanks | 13:18.29 |
| Robin_Watts | np. | 13:18.38 |
| mvrhel_laptop | Robin_Watts: your cluster job is psdcmyk? | 13:20.58 |
| | or is there another queue someplace | 13:21.22 |
| | bbiab | 13:27.34 |
| paulgardiner | Robin_Watts, tor8: there are some new commits on paul/forms, including the merge in of master at the end. | 13:38.56 |
| Robin_Watts | mvrhel_laptop: bugger. | 13:59.20 |
| | paulgardiner: Urm... | 14:06.29 |
| paulgardiner | Oops! What have I done. :-) | 14:06.55 |
| Robin_Watts | oh, right, sorry. | 14:06.56 |
| paulgardiner | Phew! | 14:07.02 |
| Robin_Watts | I was confused by the git web view thing showing the master commits that were in your merge too. | 14:07.36 |
| | paulgardiner: So... pdf_widget_choice_get_value returns the number of choices, and optionally fills in the supplied array. | 14:11.34 |
| paulgardiner | Yes. | 14:11.57 |
| mvrhel_laptop | Robin_Watts: ok I was thinking you had 2 queues. | 14:12.06 |
| Robin_Watts | pdf_widget_choice_set_value takes an array of choices and sets them. | 14:12.22 |
| paulgardiner | yep. | 14:12.33 |
| Robin_Watts | mvrhel_laptop: No, I'm just a fool. | 14:12.41 |
| | paulgardiner: Maybe it's just me, but that's not what I expected. | 14:13.00 |
| | Oh, is it because we can have more than one value selected? | 14:13.53 |
| | so it's really pdf_widget_choice_get_value(s) | 14:14.28 |
| | OK. I follow now. | 14:14.55 |
| | sorry. | 14:14.57 |
| | So, minor point; pdf_widget_choice_set_value sets the dirty flag, even if the value hasn't changed. | 14:15.37 |
| | Also, it always sets an array, even if there is just a single one. | 14:15.49 |
| | and the next commit fixes that latter bit :) | 14:16.20 |
| paulgardiner | :-) | 14:16.29 |
| | Confused then. I forgot you were looking at separate commits. | 14:16.51 |
| Robin_Watts | ok, looks good to me. | 14:17.59 |
| paulgardiner | great. thanks. | 14:19.24 |
| kens | congrats on release chrisl | 14:20.29 |
| Robin_Watts | ah, we've gone live? great. | 14:21.11 |
| | chrisl: nice one. | 14:21.24 |
| chrisl | Thanks - pretty smooth this time (so far!) | 14:24.18 |
| Robin_Watts | I just have this one extra fix that must go into the commercial version... :) | 14:25.07 |
| chrisl | Too late, the commercial release is done, too! | 14:25.37 |
| Robin_Watts | How well scripted is the "make a commercial release from a git snapshot" code ? | 14:26.32 |
| chrisl | It's pretty good - the only manual involvement now is changing some instances of "GPL" to "Artifex" | 14:27.24 |
| Robin_Watts | chrisl: If it was *entirely* automated, then we could have a link on the gitweb thing next to the "snapshot" link. | 14:28.38 |
| kens | how to limit it to customers ? | 14:29.20 |
| chrisl | We discussed that before - the problem is, snapshots are not what most customers want | 14:29.27 |
| Robin_Watts | kens: I'd redirect through a password protected area of the website. | 14:29.47 |
| chrisl | They always think it's safer to have 8.70 and a sh*t load of random patches, for some reason | 14:30.10 |
| Robin_Watts | chrisl: Yeah, I remember. I still think that if we do builds for customers we should commit them under a tag. | 14:30.26 |
| chrisl | I stil think we should do builds do customers! | 14:30.45 |
| Robin_Watts | So you'd checkout to the base revision, make a branch, cherry pick the patches, push that to the casper repo, then grab the commercial release from the link from that. | 14:31.17 |
| | Then we'd have a record of what we sent them. | 14:31.38 |
| | mvrhel_laptop: OK. See my bmpcmp now. | 14:32.08 |
| chrisl | But most customers want a patch to build themselves - it would be a lot of faffing around keeping a complete record of every random patch sent to a customer | 14:32.15 |
| Robin_Watts | Sure. This would be for customers that wanted either a release from us, or a build done by us. | 14:32.47 |
| kens | Only Gemma then ? | 14:33.03 |
| Robin_Watts | mvrhel_laptop: The corruption is gone, but there looks to be phase differences. | 14:33.03 |
| chrisl | Robin_Watts: I see a simpler solution being that we make it clear that we fully support our releases, anything "interim" they use at their own risk. | 14:33.17 |
| Robin_Watts | I'm not proposing anything other than that :) | 14:33.49 |
| | mvrhel_laptop: And number 15 is interesting. | 14:34.33 |
| mvrhel_laptop | Robin_Watts: ok. why don't I take it from here | 14:34.42 |
| Robin_Watts | oh, that's phase differences too. | 14:34.50 |
| | mvrhel_laptop: It's all yours :) | 14:35.05 |
| mvrhel_laptop | ok. thanks for all you work Robin_Watts | 14:35.14 |
| Robin_Watts | no worries. | 14:35.30 |
| | I am currently between 'urgent' bits of work, and what with going away on holiday in 2 days am avoiding diving into anything too big. | 14:36.11 |
| | mvrhel_laptop: If you've got anything that needs triaging/cutting down, please say. | 14:36.32 |
| mvrhel_laptop | ok thanks | 14:36.41 |
| Robin_Watts | Number 34 in my bmpcmp is odd. | 14:37.25 |
| mvrhel_laptop | oh that is odd | 14:38.05 |
| Robin_Watts | (For the blink test to work, you need to hold ctrl now) | 14:38.27 |
| mvrhel_laptop | oh its not just the dots but a scaling change | 14:39.24 |
| | great.... | 14:39.38 |
| Robin_Watts | I suspect there are 2 issues; the scaling + the phase change. | 14:40.00 |
| mvrhel_laptop | these must be indexed color spaces of the turkey | 14:40.44 |
| | for it to be going through gximono | 14:40.53 |
| Robin_Watts | I could look for the scaling issue while you look for the phase change maybe ? | 14:41.25 |
| | or does that seem like a potential overlap? | 14:42.00 |
| | 104 shows a level change rather than just a phase change (but for the better, maybe?) | 14:44.56 |
| mvrhel_laptop | Robin_Watts: I have to head out for a bit now. I will beat on this more later today | 14:56.31 |
| Robin_Watts | mvrhel_laptop: Did you see my comment above about me maybe looking for the scaling issue? | 14:56.49 |
| | (and leaving you to find the phase one) ? Or does that seem a bad idea? | 14:57.05 |
| paulgardiner | Robin_Watts: Did you push forms to the main repo? | 14:58.29 |
| Robin_Watts | paulgardiner: Not yet. Was waiting a bit to give tor8 a chance to comment if he wanted to. | 14:58.49 |
| paulgardiner | Ah right. Okay | 14:59.15 |
| tor8 | *frustration* Xcode 4.4 is buggier than ever... | 15:15.53 |
| | having to force quit the IDE between each debugging session because the thing is not smart enough to realize the iphone simulator has quit... so it hangs trying to close a non-existent process. | 15:16.44 |
| paulgardiner | tor8: So you'd recommend not upgrading for those that still have the choice? | 15:37.23 |
| tor8 | I would most definitely recommend to stay with 10.6 and Xcode 3 if you have the choice | 15:37.46 |
| Robin_Watts | 10.6 = snow leopard ? | 15:38.04 |
| tor8 | sadly, I don't, since apple requires xcode 4 to build new ios apps :( | 15:38.28 |
| | Robin_Watts: yes. | 15:38.31 |
| Robin_Watts | I suspect paul is on lion already. | 15:38.48 |
| | Xcode 4.5 is in beta now, and will be required to work with iOS 6. | 15:40.18 |
| | (also in beta now) | 15:40.31 |
| paulgardiner | Yeah, I'm on lion already. I think I have Xcode 4.1 or 4.2 | 15:45.12 |
| tkamppeter | gs 9.06 final is now uploaded to Ubuntu Quantal (12.10). Thank you all for the great work. | 15:49.08 |
| chrisl | tkamppeter: that was quick! Nice one! | 15:49.31 |
| kens | thanks tkamppeter | 15:49.51 |
| chrisl | tkamppeter: actually, I have a question about the opvp device (and the OpenPrinting API), do you know where I could get an up-to-date OpenPrinting API reference and/or a good person to ask about it? | 15:51.22 |
| kens | OK off for pizzza, goodnight folks | 16:02.07 |
| Robin_Watts | nigh tkens | 16:02.16 |
| | FWIW: They released the parallels upgrade that fixed the VMware import, and so my Windows XP virtual box is now running on the macbook again. | 16:03.30 |
| | tor8: That reflected objects bug is down to mupdf not supporting transfer functions. | 16:10.34 |
| | We have a luminosity SMask with a transfer function that inverts it. | 16:12.26 |
| tor8 | Robin_Watts: ow. | 16:17.22 |
| Robin_Watts | indeed. | 16:17.29 |
| | tor8: Are you happy for me to push pauls forms changes, btw? or would you like to look them over first? | 16:18.20 |
| | (includes merging master into forms - no changes on master) | 16:18.37 |
| tor8 | go ahead | 16:18.44 |
| tkamppeter | chrisl, contact Koji Otani <sho at bbr dot jp>. | 16:20.08 |
| chrisl | tkamppeter: thanks, I'll do that | 16:20.28 |
| Robin_Watts | paulgardiner: I just spotted a compile fail on the cluster as it's testing those commits. | 16:21.46 |
| | Is that to be expected? | 16:22.01 |
| | They'll be running with the new thirdparty, but that shouldn't affect the unix makefiles, right ? | 16:22.26 |
| chrisl | Didn't you say the include path(s) had changed? | 16:23.46 |
| Robin_Watts | The unix makefiles find the includes by thirdparty/jpeg* etc. | 16:28.47 |
| | so me changing jpeg-8d to jpeg-9 is no problem. | 16:28.57 |
| | The windows solutions has them listed explicitly. | 16:29.19 |
| tkamppeter | chrisl, OPVP specs are here: ftp://ftp.pwg.org/pub/pwg/fsg/vector/ | 16:29.26 |
| chrisl | tkamppeter: cool, thank you! | 16:31.04 |
| Robin_Watts | Damn. mujstest cluster failures are down to it not finding v8, which is probably down to the thirdparty changes. Let me have a look. | 16:43.03 |
| chrisl | I have to head off - any release questions will have to wait until tomorrow...... | 16:45.28 |
| Robin_Watts | tor8: How much do we care about transfer functions? | 17:25.55 |
| tor8 | I'd prefer to keep them out of the device interface | 17:26.38 |
| Robin_Watts | I could probably make this case work by passing the transfer function (or a sampled version of it) into the begin_mask call. | 17:27.04 |
| tor8 | but if we can bake them into the colorspaces somehow, that's a solution I can live with. I haven't seen much need or use for them yet. | 17:27.06 |
| Robin_Watts | (but that's exposing it into the device interface) | 17:27.29 |
| | Hmm. So roll the transfer function into the colorspace? | 17:27.49 |
| | Is this a customer file? | 17:28.34 |
| | No. I'm tempted to open a new enhancement bug saying that we don't support transfer functions, and to point this bug at that and close it. | 17:29.48 |
| tor8 | I don't believe so, it was entered directly into the bugzilla with no customer id | 17:29.50 |
| Robin_Watts | If it ever becomes an issue we'll then have at least 1 file for it. | 17:30.06 |
| tor8 | that sounds fine to me | 17:30.20 |
| Robin_Watts | I have some changes here that emit a warning that we're ignoring a transfer function. | 17:30.22 |
| tor8 | Robin_Watts: four commits on tor/master for review | 17:30.42 |
| Robin_Watts | ok. 5 mins. | 17:31.51 |
| | Why "destructiveButtonTitle" rather than "deleteButtonTitle" ? | 17:39.07 |
| | Otherwise all look fine to me. (bearing in mind that my objective C is sketchy at best) | 17:42.30 |
| | (and the destructive vs delete thing is just a question - presumably there is a reason for that?) | 17:43.07 |
| | tor8: One commit on my repo for you to look at after you've pushed yours. | 17:47.17 |
| Robin_Watts | walks dogs. bbs. | 17:54.25 |
| tor8 | Robin_Watts: ask apple why they named it destructiveButtonTitle :) | 17:55.07 |
| | Robin_Watts: your commit for transfer function warnings LGTM | 17:57.21 |
| | paulgardiner: I assigned you a bug about pdf_new_rect | 18:01.32 |
| ray_laptop | marcosw: can you contact Gemma and tell her the commercial 9.06 is released -- and that she can now start reporting bugs against it ;-) | 18:03.56 |
| | chrisl_away: fast work on getting the commercial release out. Thanks. | 18:08.13 |
| | I emailed scott-san to ask him to send out an announcement to our customer contacts | 18:14.06 |
| marcosw | ray_laptop: I'll let Gemma know. I'm sure she is looking forward to reporting more bugs. | 18:18.08 |
| Robin_Watts | tor8: Oh, OK. | 18:18.29 |
| henrys | tor8, Robin_Watts:do we have an exact date for the mupdf release yet, Miles is asking. | 18:39.04 |
| Robin_Watts | The thirdparty stuff is all done and tested. | 18:39.26 |
| tor8 | henrys: rc going out tonight | 18:39.35 |
| Robin_Watts | So it's just down to any last minute fixes tor is doing. | 18:39.42 |
| tor8 | Robin_Watts: I don't remember if we added any major features, or whether we should just call 1.1 a stability and bug fix release? | 18:42.39 |
| Robin_Watts | http://ghostscript.com/~robin/changes.txt | 18:43.11 |
| | It's a stability and bug fix release. | 18:43.20 |
| tor8 | Robin_Watts: fantastic :) | 18:43.38 |
| | well, -l to pdfclean is pretty major | 18:43.54 |
| henrys | yeah what about linearization? | 18:44.24 |
| Robin_Watts | henrys: Well, it appears (famous last words) stable now. | 18:47.14 |
| | But there is at least 1 file that when linearised, doesn't appear to be recognised as such by Acrobat. | 18:47.44 |
| henrys | but that is a new feature right? | 18:47.45 |
| Robin_Watts | I have no idea why. | 18:47.47 |
| | Yes, it's a new feature. | 18:47.50 |
| henrys | not a bug fix. | 18:47.54 |
| Robin_Watts | indeed. | 18:47.58 |
| | The fact that saving is now part of the lib rather than part of one of the tools may also be considered a feature. | 18:48.41 |
| tor8 | Robin_Watts: henrys: rc1 on google code download page. please sanity check the archive if you got a moment. | 19:05.43 |
| Robin_Watts | You have .gitattributes and .gitignore files in there ? | 19:07.49 |
| | Is this the first time we've shipped the apps as mubusy ? | 19:09.01 |
| tor8 | yes, and yes | 19:09.09 |
| Robin_Watts | Possibly we should mention that in the windows README file? | 19:09.18 |
| tor8 | for 1.0 we shipped the command line tools in a separate zip | 19:09.37 |
| Robin_Watts | Starting with this release, to save space, we are shipping the mupdf tools as a single binary, mubusy.exe. | 19:10.00 |
| | Where previously you would have called "mupdfclean blah blah blah" now call: "mubusy clean blah blah blah" | 19:10.27 |
| | Otherwise it looks great. I am being called for food. bbs. | 19:10.41 |
| | henrys: How does the forms release fit into your release news plans ? | 19:11.25 |
| tor8 | Robin_Watts: mupdf.com/news2 | 19:11.43 |
| henrys | we agreed on 2 releases? | 19:11.47 |
| | right? | 19:11.49 |
| | so I'm going to anounce there will be a second release in this news letter. | 19:12.22 |
| | and describe the form stuff. | 19:12.36 |
| tor8 | henrys: yes, there will be a forms alpha release (in source form only, no binaries) later | 19:12.52 |
| | (or at least I think that's the way it should be) | 19:13.08 |
| Robin_Watts | henrys: Right, so the plan is to preannounce it in the newsletter. | 19:45.41 |
| | tor8: Looks good to me. | 19:46.19 |
| sebras | Robin_Watts: didn't we use to warn on ignoring transfer functions? | 20:31.37 |
| | Robin_Watts: oh... but not if it was inside an SMask. | 20:33.43 |
| Ch3rryC0ke | Hey there-- is there a way to do text selection with the mupdf viewer? | 21:20.23 |
| tor8 | Ch3rryC0ke: right drag | 21:43.48 |
| Ch3rryC0ke | Sorry-- I wasn't clear at all. I want to take the text selection UI in mupdf and draw prettier highlight boxes, similar to sumatra pdf. | 21:45.02 |
| | I'm trying to build a simple PDF annotator-- I just figured out how to synthesize the appearance streams for text markup annotations, now I just need to figure out how to do pretty text selection. | 21:45.57 |
| ray_laptop | Ch3rryC0ke: so, look at the sumatra code ? | 22:04.48 |
| Ch3rryC0ke | ray_laptop: Yeah that's an option, but sumatra has a whole bunch of extra stuff, it has it's own engine. I'm wondering if the info I can do it with the text extraction that mupdf already has. So right now I'm trying to understand the text blocks / lines / spans etc. | 22:06.49 |
| tor8 | Ch3rryC0ke: if you want to highlight text, look at what happens when we highlight search results for an example | 22:15.57 |
| Ch3rryC0ke | tor8: Will do.. I'm also looking at the copy code, but what I find interesting is that in the copy code, let's say you draw a square on the middle of what looks like a paragraph. It copies the characters visible in your bounding box, not the "lines" that are within that bounding box, which is the behavior I'm trying to create.. | 22:18.03 |
| | Also-- trying to figure out how to deal with a page with two columns of text, for example. | 22:19.57 |
| tor8 | yes, good luck with that :) | 22:27.34 |
| Ch3rryC0ke | So the structure of blocks-->lines-->spans etc.. is it always "sequential" ? I mean that when I iterate through the lines of a block on a page--> is that close to iterating through the visible lines of a visible paragraph? | 22:51.04 |
| sebras | Robin_Watts: tor8: a stupid typo on my part is fixed by the patch over at sebras/master | 22:55.48 |
| | Robin_Watts: tor8: mupdf rc1 screws up page 270 of plrm3.pdf | 23:05.07 |
| | the reason is commit 4091b7a which renders large glyphs as pixmaps instead of just rendering them normally. | 23:05.53 |
| | so the any patterns would be missing. | 23:06.12 |
| | maybe we could tweak the threshold so plrm looks good at least? | 23:06.33 |
| | oh and it should be noted that we used to draw this page correctly in the commit before. | 23:08.25 |
| tor8 | Ch3rryC0ke: that's the intent, but results may vary | 23:16.26 |
| | sebras: really? damn. | 23:16.32 |
| | sebras: and don't you mean "renders large glyphs as paths instead of ..."? | 23:17.04 |
| sebras | tor8: this is the commit message: Handle glyphs that are too large to render as pixmaps. | 23:20.00 |
| tor8 | yes, we handle them by *not* rendering them as pixmaps | 23:20.24 |
| sebras | tor8: oh... now I see what you mean. darn English. | 23:21.16 |
| | anyway, there's a problem. | 23:22.12 |
| | tor8: I put together another batshit inzane suite. | 23:32.30 |
| | tor8: I see a whole heap of issues there between 1.0 and our current master. | 23:32.51 |
| | stuff that I don't see in the normal suite. | 23:33.01 |
| | e.g. there's one pdf where we now can draw an image of a cat where we used to abort early due to function arity. | 23:33.57 |
| | in another instance we muck up the drawn page a bit because we try to draw a shading using a function of the wrong arity. | 23:34.29 |
| | that is -- it used to look better when we skipped the shading altogether, but not we do our best to draw it (and fail a bit) but we do warn about the bogus function arity though. | 23:35.00 |
| | so I think we're doing better in this case. | 23:35.25 |
| | for another pdf however we no longer render the text. apparently this is due to commit 636652d but I'm not going to debug this tonight. | 23:36.25 |
| tor8 | sebras: right. but do enter a bug report about missing text when you get a chance. | 23:36.37 |
| | I'm off to bed now | 23:36.43 |
| sebras | tor8: yeah, need to research from where I got the pdf though. | 23:48.29 |
| | Forward 1 day (to 2012/08/09)>>> | |
IRC Logs