| | <<<Back 1 day (to 2012/03/06) | 2012/03/07 |
| mvrhel_laptop | henrys: that is not going to give you fast color. You want to do -dUseFastColor | 00:03.36 |
| | setting the profile to the profile that you have above will actually cause more mappings when you go out to an RGB device compared to the default case | 00:06.11 |
| | since the target device is sRGB based and you are specifying that the source colors are all defined in the 255-X postscript color space | 00:07.05 |
| | with -dUseFastColor littleCMS will not be used at all for PCL | 00:08.04 |
| | since there are no ICC color spaces | 00:08.17 |
| henrys | okay I see. | 00:08.26 |
| Robin_Watts | henrys: re 692906... really? You think it's a valid bug? | 00:17.04 |
| | I mean, if he's a customer and he wants to send us questions to support@artifex.com that's fine, but it's not really something for the bug tracker, right ? | 00:18.34 |
| henrys | I don't know it sounds to me like he is trying set up pdfwrite as a server himself. He's put in a request for that and is waiting | 00:19.42 |
| | so maybe just say sorry didn't realize you were a customer but we still are not sure about what you want send something to support@artifex.com, and leave the bug closed. | 00:21.44 |
| | sound reasonable. | 00:21.54 |
| Robin_Watts | sure. | 00:22.01 |
| henrys | I notice they have moved into top 10 customer status... sigh | 00:23.30 |
| sebras | Robin_Watts: robin/images, robin/pg_android robin/context have all been merged into the origin repo somewhere. robin/ios seems like a dead-end. branch cleanup? :) | 00:28.54 |
| | and what is robin/remote/origin/master? | 00:29.19 |
| Robin_Watts | Oh, bugger. | 00:29.22 |
| sebras | while you're at it you may want to make your repo a bare git repo like the others...? | 00:30.35 |
| Robin_Watts | sebras: I occasionally build on casper. | 00:31.01 |
| sebras | oh. in that repo? | 00:31.09 |
| Robin_Watts | mmm. | 00:31.13 |
| | Was pg_android not published before ? | 00:31.21 |
| sebras | I think you got pg_android from paul first, but I know tor8 created origin/pg_android recently. | 00:31.55 |
| | I cleaned up my own branches just now so as not to confuse you guys. I believe that my four patches on sebras/master are still valid. | 00:32.31 |
| Robin_Watts | Where are you seeing these branches of mine? | 00:33.15 |
| sebras | git branch -r | 00:33.32 |
| | I pull from ghostscript.com/home/robin/repos/mupdf.git/ | 00:33.48 |
| Robin_Watts | Right, *my* repo has various branches in. | 00:34.11 |
| | but the master one shouldn't. | 00:34.21 |
| sebras | no, but still I see all your old branches. so I'm pleading for a branch cleanup. :) | 00:34.47 |
| Robin_Watts | I see. | 00:34.57 |
| sebras | feel free to ignore me, but I'll keep pleading sometime later. ;) | 00:35.04 |
| Robin_Watts | I use my repo on casper to move code between my windows box and my mac. | 00:35.17 |
| | Commit, push, pull. | 00:35.23 |
| | faster than fighting the finder/converting line endings etc. | 00:35.49 |
| sebras | ok. can't you just push/pull directly from one to the other? | 00:36.14 |
| | I know tor8 does that a lot. | 00:36.19 |
| Robin_Watts | No, cos neither of them are set up as accessible from outside. | 00:36.48 |
| sebras | ah. all my laptops have an ssh-server running. | 00:37.33 |
| Robin_Watts | sebras: OK. Some simple tidying done. | 00:38.44 |
| sebras | oh and the reason I was complaining about the bare repo thing is that from here: http://git.ghostscript.com/?p=user/robin/mupdf.git/.git;a=summary I can not take the git-url and clone it (which is what I attempted to do a long time ago before realizing that I should be fetching directly from casper). | 00:38.47 |
| | Robin_Watts: thanks. :) | 00:39.58 |
| Robin_Watts | At some point, when everything is up to date, I'll change it to be a bare repo. | 00:40.37 |
| | np. Thanks for pointing it out. | 00:44.14 |
| kens | chrisl so I see the Ubuntu 'shared libraries' bit us again :-( | 08:08.55 |
| chrisl | kens: yes. Although, we can hardly complain too much - we should really have done a jbig2dec release. | 08:09.31 |
| kens | True. But I wonder why they are putting it as a system shared library | 08:09.56 |
| | We really should retract it as a 'product' | 08:10.16 |
| chrisl | I've been asked not to - but haven't been given a good reason. I kind of feel we should rename it to obfuscate the fact we include it. | 08:11.36 |
| kens | That would do :-) | 08:11.50 |
| | But if we aren't going to release new versions we should pull it anyway. Or at least say its replaced by the code supplied as part of GS. | 08:12.19 |
| chrisl | The problem is, mupdf uses it. | 08:12.42 |
| kens | Hmmm. | 08:12.50 |
| | Make Tor include it as standard instead of 3rd party :-) | 08:13.19 |
| chrisl | Good luck with that.... | 08:13.34 |
| kens | OK let Tor maintain jbig2dec and be resposible for releases then :-) | 08:14.44 |
| chrisl | And good luck with that...... ;-) | 08:15.27 |
| kens | OK so ddd is off again with a watchpoint, I wonder how long it will be before it triggers..... | 08:21.30 |
| | If it hasn't hit it by 10:30 I'll leave it while I ride. | 08:21.53 |
| | Well, that's an hour and still running | 09:26.02 |
| Robin_Watts | Surely the solution with jbig2dec is just to do new releases with every gs/mupdf release (if it's changed) | 10:10.13 |
| kens | And hope that the distributions pick those up at the same time :-) | 10:10.47 |
| chrisl | Except it wasn't/isn't quite ready for a release right now | 10:10.52 |
| kens | My point was more that the shared library dogma is costing us because we can't reproduce the problems. | 10:11.09 |
| chrisl | Well, we really ought to be clearer in pointing such people at the distribution package maintainer - I was wary about doing it this time since jbig2dec really needs a new release | 10:12.25 |
| kens | Coming up on 2 hours now, still no wathcpoint trigger, ddd still running :-( | 10:13.15 |
| | Well time for me to go for a while, I'll leave ddd running and see if it triggers while I'm out. | 10:20.58 |
| vtorri | hey | 11:18.47 |
| | i saw some "multi threading" support in the commits | 11:19.10 |
| | is it only for thread safety, or is there in addition speed improvements for parralal computations ? | 11:19.40 |
| Robin_Watts | vtorri: Hi. | 11:20.07 |
| vtorri | for ----> with | 11:20.27 |
| Robin_Watts | You can render to display list in the main thread, then render from display list -> images in multiple bands in other threads. | 11:20.41 |
| vtorri | ho | 11:20.53 |
| Robin_Watts | So, yes, it can be used to give performance improvements on multicore systems. | 11:21.04 |
| vtorri | so it's the user who is doing parrala execution of mupdf calls | 11:21.10 |
| Robin_Watts | The responsibility for using multiple cores lies with the caller of the lib, yes. | 11:21.39 |
| vtorri | ok | 11:21.45 |
| | anyway, is there some numbers ? | 11:22.04 |
| Robin_Watts | I can't give you any hard and fast numbers, no. | 11:22.19 |
| vtorri | ok | 11:22.25 |
| | and an example of use ? | 11:22.37 |
| Robin_Watts | but I can tell you that we have a customer trialing it now, and they are finding a measurable improvement. | 11:22.46 |
| | There are the starts of some docs in git. | 11:23.03 |
| vtorri | as I have a wrapper around mupdf and poppler, i would like to measure the speed with poppler, mupdf with and without threading supprt | 11:23.40 |
| Robin_Watts | great. Let us know how it goes. If you have any questions, please feel free to ask. | 11:24.09 |
| vtorri | in addition, we plan to hae a completely async reader | 11:24.21 |
| | so i think that this feature will help a lot | 11:24.37 |
| Robin_Watts | 'completely async reader' ? | 11:24.47 |
| vtorri | i mean, the rendering is done in several threads | 11:25.05 |
| | to display thumbnails of the pages | 11:25.19 |
| Robin_Watts | Right, that's what this is intended to allow. | 11:25.19 |
| vtorri | and also render several pages when scrolling | 11:25.54 |
| Robin_Watts | The interpretation (from pdf -> display list) has to happen in the main thread, but the rendering (repeated rendering at different scales, or banded rendering etc) can all happen in multiple threads. | 11:26.08 |
| | It has stopped raining. I should run. bbs. | 11:27.31 |
| vtorri | where is the doc lying ? | 11:27.39 |
| | oh | 11:28.13 |
| | in doc/ .... | 11:28.17 |
| sebras | vtorri: if anything is unclear in doc/ let me know. | 12:00.30 |
| vtorri | sebras, well, usually, an example is always useful | 12:00.53 |
| sebras | vtorri: of course. that is on the todo-list. :) | 12:01.49 |
| vtorri | hehe | 12:01.55 |
| | anyway, iwon't use it until the next release | 12:02.05 |
| | is there some date ? | 12:02.09 |
| sebras | mupdf 1.0 is supposed to be release at the end of this month. | 12:02.32 |
| vtorri | great ! | 12:02.39 |
| | .10 | 12:02.41 |
| | 1.0 | 12:02.44 |
| | does it mean that the API will be fixed ? | 12:02.57 |
| sebras | not fixed, but certainly less changes. | 12:04.16 |
| | tor8 have the details of what is planned for what release, but I know that there are some changes that are planned for after 1.0. | 12:05.14 |
| vtorri | ok | 12:05.41 |
| | i also would like to know if there will finally some shared lib with the 1.0 or not | 12:06.15 |
| | +be | 12:06.58 |
| sebras | vtorri: I doubt that we'll add a shared lib. it hasn't been mentioned as far as I know. | 12:09.12 |
| vtorri | ok | 12:09.21 |
| | so still static linking :/ | 12:09.30 |
| | thanks | 12:09.38 |
| sebras | vtorri: so you'll have precise control over what mupdf code is being executed, and need not worry about subtle changes in the API differing in runtime. ;) | 12:10.43 |
| vtorri | sure, as i have to provide the code with my library... | 12:11.12 |
| | this also prevent mupdf from being more widely used, unfortunately | 12:11.42 |
| tor8 | robin: is fz_save_pixmap really necessary now that you added fz_pixmap_components? | 13:58.29 |
| | robin: also, fz_pixmap_pixels, or fz_pixmap_samples? | 14:01.03 |
| kens | 6 hours and counting.... | 14:24.36 |
| tor8 | Robin_Watts: I updated my branch to your latest split commit. | 14:32.41 |
| marcosw | kens: what happens in ~6 hours? | 14:36.21 |
| kens | That's how long dd has been running Gs with a watchpoint in my VM | 14:37.14 |
| | Takes acouple of seconds without the watchpoint. | 14:37.14 |
| Robin_Watts | tor8: back. | 14:37.14 |
| | tor8: Ah, cool. | 14:37.21 |
| | Is that published on casper? | 14:37.43 |
| tor8 | in user/tor/mupdf.git on branch header-split | 14:37.55 |
| Robin_Watts | I've just got an updated version here that uses openjpeg 1.5.0 | 14:37.56 |
| | ok, cos I have some tiny tweaks to it. | 14:38.10 |
| tor8 | I moved some things I think should be public into the public headers | 14:38.13 |
| Robin_Watts | ok. | 14:38.17 |
| tor8 | and the xref_entry back into the internal ones | 14:38.20 |
| Robin_Watts | AH, that's the one | 14:38.26 |
| tor8 | and removed mupdf-internal from most of the tools | 14:38.29 |
| | I also brought the x11_main.c viewer up to speed | 14:38.59 |
| Robin_Watts | OK. | 14:39.13 |
| tor8 | I've got a list here with some things we should consider renaming and/or changing in the api | 14:39.21 |
| | the halftone stuff, we could hide most of that if we allowed NULL to mean the default halftone | 14:39.33 |
| Robin_Watts | That sounds reasonable. | 14:39.48 |
| vtorri | x11_main.c use the thread stuff ? | 14:40.17 |
| tor8 | I'm fine with the accessors for pixmap, apart from the above name change | 14:40.21 |
| | vtorri: no. | 14:40.24 |
| vtorri | arg | 14:40.32 |
| tor8 | we're splitting headers into public and internal ones | 14:40.40 |
| vtorri | ok | 14:40.45 |
| tor8 | the public api:s should remain stable, but internal ones we're free to change willy nilly | 14:41.01 |
| | robin: the pixmap/image split could do with a bit more polish, but nothing that affects the public interface | 14:41.29 |
| Robin_Watts | tor8: Quite possibly. What is there now was just what fell out when it started working. | 14:42.02 |
| tor8 | the fz_load_jpeg/png/tiff/whatever should IMO return fz_images | 14:42.19 |
| | and the xres/yres should move into image as well IMO | 14:42.39 |
| Robin_Watts | That would be nice. | 14:42.53 |
| tor8 | but that can wait until after 1.0 if we don't find the time to slip it in | 14:43.14 |
| Robin_Watts | I suspect that pdfextract could usefully use images rather than pixmaps. | 14:43.27 |
| tor8 | did you see my question about fz_save_pixmap? | 14:43.32 |
| Robin_Watts | About making it private ? | 14:43.45 |
| tor8 | about not needing it :) | 14:43.52 |
| Robin_Watts | It may well not be needed. | 14:44.05 |
| tor8 | with the accessors I think you don't need it any more | 14:44.18 |
| | if we also make fz_convert_pixmap available | 14:44.28 |
| | or we could just make pdfextract use the private interface | 14:44.42 |
| | and move convert_pixmap back, if we later decide to smarten pdfextract up for load_image uses | 14:44.59 |
| | so it can save jpegs as they came from the file | 14:45.11 |
| Robin_Watts | I suspect we could usefully rewrite pdfextract to save images in their original format where possible. | 14:45.24 |
| | I find fz_save_pixmap relatively inoffensive because it's self contained. | 14:46.01 |
| tor8 | we ought to rename a few other accessors like you did with the new pixmap accessors | 14:46.08 |
| Robin_Watts | Not sure how I feel about exposing fz_convert_pixmap. | 14:46.10 |
| tor8 | I'm not thrilled about exposing it | 14:46.18 |
| Robin_Watts | I don't suppose you'd consider a wholesale move to: fz_type_action ? | 14:46.44 |
| tor8 | I'm happy with fz_noun_attribute() for accessors | 14:46.58 |
| Robin_Watts | (rather than the mix we have between that and fz_action_type) | 14:46.59 |
| | fz_pixmap_save appeals to me more than fz_save_pixmap | 14:47.20 |
| | but that's a big change. | 14:47.32 |
| | fz_pixmap_{keep,drop,convert,...} | 14:47.57 |
| tor8 | it's a major change, and I'm not sold on that naming scheme :) | 14:47.57 |
| Robin_Watts | I figured that might be the answer ;) | 14:48.08 |
| tor8 | it smells of OOP | 14:48.14 |
| Robin_Watts | OOP smells nicer than most alternatives. | 14:48.32 |
| | Do you want to do this stuff, or do you want me to? | 14:49.08 |
| tor8 | I'm happy to do the function renaming, but if you want to tackle the halftone defaultness I'd appreciate it | 14:49.33 |
| Robin_Watts | Sure. | 14:49.38 |
| tor8 | how about changing fz_debug_noun to fz_print_noun ? | 14:49.54 |
| Robin_Watts | fz_debug implies that it will compile away in release builds. | 14:50.18 |
| | so I prefer print if its not going to. | 14:50.25 |
| tor8 | then print it'll be | 14:50.40 |
| Robin_Watts | Are we working on the split branch here? | 14:50.50 |
| | or on master? | 14:50.57 |
| tor8 | we might as well continue from my header-split branch | 14:51.15 |
| Robin_Watts | So... you're going to fold that down to master? | 14:51.26 |
| | or I should pull in the branch and work on it there ? | 14:51.49 |
| tor8 | yeah, but let's keep it on a branch for now so we can squash it all into one nice patch so we don't have bits of header jumping back and forth as we make up our minds? | 14:52.14 |
| Robin_Watts | OK. | 14:52.26 |
| tor8 | and I think we should do a final pass over the headers and reorder things once we've settled | 14:53.13 |
| kens | Wow, watchpoint triggered! only 7 hours to get there | 15:00.15 |
| | and ddd didn't stop.... | 15:00.45 |
| Robin_Watts | tor8: ping | 15:36.25 |
| tor8 | Robin_Watts: yes? | 15:36.56 |
| Robin_Watts | I've just pushed an update to use openjpeg-1.5.0 | 15:37.03 |
| | so we need a new thirdparty.zip | 15:37.10 |
| | There is one in my casper homedir. | 15:37.16 |
| | Sanes out fine - it gives more logging of errors on some files, but no image diffs. | 15:37.50 |
| tor8 | ~robin/thirdparty.zip ? | 15:39.06 |
| Robin_Watts | That's it. | 15:39.12 |
| tor8 | I've copied it to the mupdf.com/download directory | 15:39.45 |
| | do you want me to repoint the symlink yet? | 15:39.51 |
| Robin_Watts | The symlink follows the git one, right? | 15:40.05 |
| tor8 | that's the intention | 15:40.22 |
| Robin_Watts | Git needs the new one now, so I think repointing it is the right thing to do. | 15:40.26 |
| | I've checked both windows and unix building. | 15:40.38 |
| tor8 | you'll need to push to the origin repo as well; I'll repoint the symlink | 15:41.54 |
| Robin_Watts | I have, I think? | 15:42.18 |
| tor8 | only to robin/master | 15:42.31 |
| | origin/master is still on "Fix memory corruption" | 15:43.04 |
| Robin_Watts | Not for me... | 15:44.28 |
| vtorri | robin master was the neversawn guy in the serie "Magnum" | 15:44.29 |
| | funny :) | 15:44.40 |
| Robin_Watts | Robin Masters, I believe :) | 15:45.37 |
| tor8 | Robin_Watts: hrmf. "git fetch" isn't the same as "git fetch origin" if you're on a branch tracking another remote :) | 15:45.54 |
| Robin_Watts | tor8: According to the web view it's on origin/master too. | 15:45.55 |
| tor8 | so nvm | 15:45.56 |
| Robin_Watts | Ah :) | 15:46.00 |
| | So I'm now going to blow away my casper mudf repo and make a new bare one. | 15:46.20 |
| | just to keep sebras happy :) | 15:46.31 |
| vtorri | Robin_Watts, arg ! not so funny finally :) | 15:47.33 |
| Robin_Watts | tor8: aargh. How do I work on a bare git repo? | 16:09.35 |
| | git pull won't work without a working set. | 16:09.49 |
| | git fetch does though... | 16:10.17 |
| tor8 | Robin_Watts: I have a non-bare repo in ~/src/mupdf on casper (that I very rarely use) | 16:11.32 |
| | bare repos are only for storing stuff, not for working so I don't see how you'd want to pull to it? | 16:12.04 |
| Robin_Watts | I've figured out enough to get going. I may get stuck in future, but I'll worry about it later. | 16:12.11 |
| tor8 | you can push to it | 16:12.15 |
| | if you want to update the refs | 16:12.26 |
| Robin_Watts | tor8: Presumably the intent with the halftone stuff is that people should be able to provide their own halftones. | 16:24.44 |
| | As such, should the definition of fz_halftone_s not be public ? | 16:25.15 |
| | Or do we consider that to be 'post 1.0' functionality ? | 16:26.16 |
| | and hence we don't want to public too much because what we publish may change ? | 16:26.30 |
| | s/public/publish/ | 16:26.37 |
| tor8 | something like that. and the definition is dependent on the fz_pixmaps | 16:36.57 |
| paulgardiner | tor8: I think I have the android-app link highlighting working now, and pushed to my repo on Casper. Just for your information. In no particular hurry to have it checked over. | 16:38.16 |
| tor8 | paulgardiner: thanks | 16:39.28 |
| Robin_Watts | mvrhel_laptop: Aha. | 16:51.48 |
| | Stupid halftoning question if I may... | 16:51.59 |
| | I stole a default halftone for mupdf from gs a while ago. | 16:52.19 |
| | Its currently only used for halftoning greyscale pixmaps to bitmaps. | 16:52.59 |
| | When we use halftones for cmyk, say, presumably we wouldn't use the same halftone for each separation? | 16:54.14 |
| mvrhel_laptop | no | 16:55.50 |
| | they would be different angles | 16:56.02 |
| | typically yellow is 0 degrees | 16:56.13 |
| | black is 45 degrees | 16:56.18 |
| Robin_Watts | Thanks. | 16:57.10 |
| mvrhel_laptop | cyan/magenta sit around 15 or 75 | 16:57.12 |
| | Robin_Watts: you can use the screen generation tool in the toolbin to create some screens | 16:58.16 |
| Robin_Watts | mvrhel_laptop: OK. I was just wondering if I should just reuse the same threshold array for all the planes in the absence of anything better, but that sounds like a bad idea. | 16:59.07 |
| | I'll leave it as greyscale only for now. | 16:59.17 |
| mvrhel_laptop | Robin_Watts: ok. it is easy to generate some simple screens if you would decide to do so | 16:59.49 |
| Robin_Watts | Thanks. | 17:00.17 |
| | We could do a crap rgb -> halftoned cmyk thing, but not now :) | 17:01.07 |
| kens | time to go, goodnight all | 17:02.59 |
| Robin_Watts | tor8: halftone changes pushed to my repo on casper, I think. | 17:15.57 |
| mvrhel_laptop | Robin_Watts: do clean and rebuild work properly for you with gs visual studio? | 17:24.52 |
| | was there a change recently in any of this? | 17:25.00 |
| Robin_Watts | Last time I checked. | 17:25.02 |
| | Not as far as i know. What are you seeing ? | 17:25.12 |
| | Early versions of VS2010 have a bug with Rebuild, I believe. | 17:25.36 |
| mvrhel_laptop | ok. for some reason when I do clean on ghostscript I am getting | 17:26.02 |
| | 1>NMAKE : fatal error U1077: 'call' : return code '0x1' | 17:26.04 |
| | 1>Stop. | 17:26.06 |
| | 1>NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\nmake.EXE"' : return code '0x2' | 17:26.07 |
| | 1>Stop. | 17:26.09 |
| | 1>Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions" | 17:26.11 |
| | which I don't understand why it would be doing that | 17:26.33 |
| Robin_Watts | git diff ? | 17:26.54 |
| | In case an update has only partially applied or something? | 17:27.07 |
| mvrhel_laptop | perhaps. let me look | 17:27.14 |
| Robin_Watts | Let me update my gs source. What hash are you on? | 17:27.23 |
| mvrhel_laptop | actually let me get to a fresh project | 17:27.36 |
| | to see if it does it | 17:27.42 |
| | ok that does it too | 17:29.26 |
| | I am fully updated. | 17:29.39 |
| Robin_Watts | Clean works fine for me here. | 17:29.53 |
| | Oh, wait, no. | 17:30.11 |
| | I see the same problem. | 17:30.32 |
| mvrhel_laptop | ok good | 17:30.34 |
| Robin_Watts | Hold on a mo. | 17:30.36 |
| | cleaning pcl gives the same error. | 17:32.38 |
| | chrisl: are you around? | 17:32.50 |
| mvrhel_laptop | yes. all the projects do it for me | 17:32.51 |
| chrisl | Robin_Watts: yes | 17:33.00 |
| Robin_Watts | I think someone has added a -r to one of the RM calls. | 17:33.09 |
| chrisl | May have been me | 17:33.31 |
| | Ah, no looks like Marcos has been fiddling in there | 17:34.44 |
| mvrhel_laptop | yes | 17:34.46 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=7180b9328f00fb5df41e6d019e16f70ae4f66ec7 | 17:34.57 |
| Robin_Watts | So... chrisl - this looks like your ballpark - should I leave it with you? | 17:36.05 |
| | or would you like me to look because it's windows ? | 17:36.21 |
| chrisl | What's the problem? | 17:36.31 |
| | Oh, we can't use -r in the cross platform makefiles? | 17:37.05 |
| Robin_Watts | It causes cleans on windows to fail with an error. | 17:37.05 |
| | It's not the -r that's the problem. | 17:37.44 |
| | It's the fact it tries to: | 17:37.51 |
| | 1> call .\base\rm.bat .\debugbin .\debugobj .\debugobj .\debugobj .\debugobj | 17:38.03 |
| | 1>d:\CVS\artifex\ghostpdl.git\gs\debugbin\*, Are you sure (Y/N)? | 17:38.05 |
| | 1>d:\CVS\artifex\ghostpdl.git\gs\debugobj\*, Are you sure (Y/N)? | 17:38.07 |
| | Recursive deletes are problematic. | 17:38.28 |
| chrisl | Well, that is a pile of crap :-( | 17:38.46 |
| mvrhel_laptop | well put | 17:39.01 |
| Robin_Watts | I'm not arguing. | 17:39.53 |
| chrisl | I'm tempted to punt it to Marcos - he who broke it, fix it! ;-) | 17:40.39 |
| Robin_Watts | I can probably fix rm.bat to work. | 17:41.07 |
| chrisl | If you could, it would save us having to delete everything explicitly for a "clean" | 17:42.07 |
| henrys | interesting fix chrisl, I'm surprised you got that one so quickly. | 17:42.16 |
| chrisl | henrys: as I said in the commit, I had something similar (from a different angle) with the FAPI code. | 17:43.06 |
| | henrys: one rather worrying thing is that in the cases it where it "worked" it was relying on potentially unitialised variables...... | 17:45.05 |
| henrys | anything on the mincho gothic free font investigation I owe urw a response. | 17:45.07 |
| chrisl | I'm not convinced we're going to get much take-up on an AFPL mincho/gothic release. There are at least two (allegedly) print quality substitutes for each that are available under more liberal licenses (although not GPL compatible). | 17:47.16 |
| Robin_Watts | mvrhel_laptop, chrisl: Fixed pushed. | 17:48.29 |
| chrisl | Robin_Watts: excellent - nice one! | 17:48.45 |
| henrys | chrisl:can a customer use them in a printer? license wise? | 17:49.17 |
| mvrhel_laptop | Robin_Watts: Great thanks | 17:49.59 |
| chrisl | henrys: Yes, the main one I've been looking at has a free to use as long as you don't claim credit, and don't change it. The problem, from our customer's POV is that they are only the fixed, not proportional variants - other wise I'd have recommended using them. | 17:51.05 |
| henrys | chrisl:well users want proportional (basically all non programmers and tor ;-) use proportional) how are the free ones substitutes? | 17:58.32 |
| chrisl | henrys: kanji glyphs tend not to vary as much in their width - which is why the customer in question only noticed the problem on the Latin glyphs in DroidSansFallback. | 18:00.17 |
| | henrys: I did actually find a set of candidates that we might be able to use, but I don't want to misinterpret the license - it's not an area I have much experience with. | 18:02.39 |
| henrys | chrisl:do you have a link or something? | 18:06.22 |
| chrisl | http://ossipedia.ipa.go.jp/ipafont/index.html#LicenseEng | 18:06.31 |
| henrys | I think ralph was trying to talk urw into using the ipa | 18:08.41 |
| | that is instead of AFPL | 18:10.56 |
| | the whole business embedding font embedding business in pdf (pdfwrite) gets hazy with this kind of license. | 18:14.17 |
| | too many words there. | 18:14.31 |
| chrisl | I think it explicitly allows embedding | 18:14.41 |
| henrys | yes but if the output is a "derived program" it must have the license right? | 18:16.12 |
| chrisl | It just says that if font information is extracted from a file in which it is embedded, it is still covered by the license. | 18:18.13 |
| | henrys: don't forget, truetype has an "embeddable" flag, so if that's not set in the distributed file, I think we can assume it's allowed - I'll check that tomorrow. | 18:20.58 |
| henrys | okay | 18:22.32 |
| | I would think fixed would be unacceptable but I'm not an expert. Many pages I see are exactly like the link you sent a mix of kanji and latin - presumably you want to use the same font right? | 18:26.20 |
| chrisl | henrys: and another thing - I'm not considering these as additions to our standard distribution. One of the reasons for using DroidSansFallback was to avoid shipping individual Japanese, Chinese, Korean, Vietnamese, etc, etc, fonts. | 18:26.20 |
| henrys | understood | 18:27.05 |
| chrisl | henrys: Depends - in a PDF we have Widths and W arrays, so the glyph spacing isn't dictated by the font *we* use | 18:27.38 |
| | henrys: IPA has both fixed and proportional versions available under the IPA font license so, at least in principle, they have all the substitutes we need (for Japanese) | 18:30.18 |
| | henrys: According to fontforge, the IPA mincho font I have handy has the embeddable flag set to the most liberal value - you can embed the entire font, in such a way that it can be extracted and installed on another system. I'd like the decode the font manually to double check that, though. | 18:35.36 |
| | Have to go - I'll try to look at all four of the relevant IPA fonts in more detail tomorrow (unless cust 532 pipes up again.....) | 18:37.19 |
| henrys | chrisl_away:great | 18:38.16 |
| pickcoder | what is the best way to enforce landscape orientation when combining PDFs? | 19:37.13 |
| | the individual PDFs are already set landscape | 19:37.28 |
| | the output is rotated and the pages are chopped off | 19:37.40 |
| mvrhel_laptop | bbiaw | 19:40.54 |
| Robin_Watts | tor8: ping? | 20:15.21 |
| | In between being bothered by customers, I've been scribbling some more function comments in fitz.h | 20:16.17 |
| | and I've come to the chartorune, runetochar stuff. | 20:16.28 |
| | Do we want to give them better names? An fz_ prefix at least? | 20:16.48 |
| | Or do we want to offer a higher level interface (string encode/decode instead of char level operation?)? | 20:17.33 |
| | Why does runtochar take a pointer to the rune ? | 20:17.57 |
| pickcoder | can I use -c commands in -dBATCH mode? | 20:19.58 |
| Robin_Watts | yes. | 20:20.09 |
| pickcoder | "<</Orientation 3>> setpagedevice" is not working | 20:20.14 |
| | it is throwing a window open error | 20:20.37 |
| tor8 | Robin_Watts: they're the same as the plan9 libc functions | 20:20.44 |
| | the place where utf-8 was invented | 20:21.08 |
| Robin_Watts | Right. | 20:21.24 |
| tor8 | I guess we could prefix them with fz_ if you like | 20:22.02 |
| Robin_Watts | Craply named if you ask me. | 20:22.13 |
| tor8 | the runelen function we can drop | 20:22.16 |
| Robin_Watts | Why does runetochar take a pointer to the rune? | 20:22.33 |
| | In *ALL* our cases, it would be more convenient for it to take the rune itself. | 20:22.50 |
| tor8 | for symmetry would be my guess | 20:22.56 |
| | it's bothered me too, but since they are the "standard" conversion functions from a (obscure...) libc I didn't feel like changing them | 20:23.32 |
| | now if we rename them, there's not much point in keeping the rune as a pointer | 20:23.54 |
| Robin_Watts | win_main.c uses chartorune, x11_main.c uses runetochar | 20:24.00 |
| | win_main.c uses fitz-internal.h | 20:24.24 |
| | mupdf-internal.h sorry, which means fitz-internal.h too. | 20:24.40 |
| tor8 | I wonder why it uses mupdf-internal | 20:24.49 |
| | it shouldn't need to if we've done the split correctly | 20:25.03 |
| Robin_Watts | Does need to, it seems. | 20:25.32 |
| | Doesn't, sorry. | 20:25.41 |
| | Hi RaducuL | 20:36.55 |
| RaducuL | Hi Robin | 20:37.10 |
| Robin_Watts | tor8: RaducuL was wondering if our ios sample builds for the simulator ? | 20:37.13 |
| RaducuL | it builds in the older xcodes | 20:37.37 |
| | but in 4.3 | 20:37.40 |
| | not any more | 20:37.43 |
| Robin_Watts | RaducuL is the lead developer for the customer using mupdf in multicore mode. | 20:37.50 |
| RaducuL | a lot of paths are changes | 20:37.54 |
| | changed | 20:37.58 |
| Robin_Watts | tor8 is in sweden, so may be having dinner right now. but he checks in periodically. | 20:38.34 |
| tor8 | hi. it builds for both simulator and device on xcode 4.2 under osx 10.6 | 20:39.00 |
| Robin_Watts | tor8: but you don't have 4.3 ? | 20:40.44 |
| tor8 | no, I don't have 4.3 | 20:41.02 |
| Robin_Watts | (or does 4.3 not work on snow leopard?) | 20:41.14 |
| RaducuL | i have lion and 4.3 | 20:41.19 |
| Robin_Watts | I have lion, and just wish I still had snow leopard :) | 20:41.34 |
| RaducuL | it build even on lion | 20:41.35 |
| | until i switched to 4.3 | 20:41.43 |
| tor8 | 4.3 is only available on the mac app store | 20:42.04 |
| RaducuL | yes | 20:42.15 |
| | when it installs it removes the Developer folder | 20:42.33 |
| | all the stuff is now in the xcode app bundle | 20:42.42 |
| tor8 | *sigh* why do they have to keep making things worse... | 20:43.03 |
| | I can't install it anyway, it requires osx 10.7.3 | 20:43.25 |
| RaducuL | they moving towards sandboxing | 20:43.31 |
| tor8 | they are really bad about maintaining backwards compatibility. | 20:44.34 |
| RaducuL | they never cared | 20:44.49 |
| Robin_Watts | tor8: No, they are really good at extracting peoples money for upgrades :( | 20:44.55 |
| tor8 | Robin, you have Lion, can you try to install Xcode 4.3? | 20:45.07 |
| Robin_Watts | I could, but I've never got to grips with Xcode. | 20:45.35 |
| | It's hateful. | 20:45.39 |
| tor8 | RaducuL: the main project is trivial to recreate, but we do call an external makefile to cross compile the library | 20:45.44 |
| | it wouldn't surprise me if they broke the environment variables that are set to the various paths used for building with external targets | 20:46.24 |
| RaducuL | yes | 20:46.31 |
| | that's the cause | 20:46.36 |
| | but i dont know how to fix it | 20:46.44 |
| tor8 | $PLATFORM_DEVELOPER_BIN_DIR should be set | 20:46.47 |
| | that's used in the Makerules file | 20:47.18 |
| | ARCHS, SDKROOT and TARGET_BUILD_DIR are used in ios/build_libs.sh | 20:47.34 |
| RaducuL | i saw that | 20:48.23 |
| tor8 | which one of them is not set correctly? or is it all of them? | 20:48.39 |
| RaducuL | so the first error is /bin/sh: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang: No such file or directory | 20:48.47 |
| | i can fix it by creating a link to clang | 20:48.56 |
| Robin_Watts | Installing now. | 20:49.02 |
| tor8 | where is the real clang? | 20:49.11 |
| RaducuL | but then it starts trowing compiler errors | 20:49.11 |
| | in usr/bin | 20:49.25 |
| Robin_Watts | Is the iphonesimulator clang the same as the normal macosx clang? | 20:52.34 |
| RaducuL | i think | 20:52.47 |
| | after i fix the clang path | 20:52.55 |
| | it starts with In file included from fitz/base_context.c:1: fitz/fitz.h:11:10: fatal error: 'stdarg.h' file not found #include <stdarg.h> ^ | 20:52.59 |
| | so some other paths are brobek | 20:53.23 |
| Robin_Watts | macosx clang might be 64bit, whereas ios will be 32bit. So the simulator may also use a 32bit one ? | 20:53.38 |
| RaducuL | yes | 20:53.45 |
| tor8 | I'm not sure, the iphone device clang is not the same as the macosx one | 20:56.58 |
| Robin_Watts | Well, that's definite - one targets x86_64, the other ARM :) | 20:57.27 |
| tor8 | it sets a lot of other environment variables for where to find includes etc, so I doubt the regular clang will be happy when running in the cross platform build environment | 20:57.55 |
| | we send -isysroot and a bunch of other command line flags to the compiler | 20:58.29 |
| Robin_Watts | I'm going to shut up shop for the night soon. Hopefully by tomorrow 4.3 will have finished installing and my mac will be completely broken. | 20:58.56 |
| pickcoder | do I need to specify -f if I use -c when listing several files to process? | 21:07.20 |
| Robin_Watts | tor8: I need to add the same accessor functions for bitmaps as for pixmaps. Will do that tomorrow. | 21:20.57 |
| | I've pushed stuff to my repo on the header-split branch. | 21:21.55 |
| scottsan | Hi Tor are you on? | 21:48.02 |
| | Robin, Marcos??? | 21:48.33 |
| tor8 | Hi Scott | 21:48.59 |
| scottsan | Hi Tor. Question: Is text search now available on MuPDF or still in development? | 21:49.29 |
| tor8 | scottsan: search is available. you have on your ipad demo if you push the magnifying glass button. | 21:50.08 |
| scottsan | OK, thanks! This is the information that I needed. See you in London! | 21:50.34 |
| | Forward 1 day (to 2012/03/08)>>> | |
IRC Logs