| | <<<Back 1 day (to 2013/05/15) | 2013/05/16 |
| sebras | sorry about the bug, but it's too late tonight for me to fix it. | 00:20.48 |
| Global_Odey | quick question (and obviously because I'm lazy) - how do you make a shared lib on OS X and/or is it even possible? | 03:50.51 |
| vtorri_ | use libtool :p | 03:52.22 |
| Global_Odey | as in libtoolize and be done with it? or spend the next several days trying to piece the entire source tree together? | 03:54.22 |
| vtorri_ | well, libtool is part of a build system, oftenly named as "autotools" | 03:55.29 |
| | so you have to write some files to set up the autotools | 03:56.19 |
| | they create Makefile's | 03:56.32 |
| | libtool will set up these Makefile's so that shared lib are created | 03:57.15 |
| Global_Odey | I guess that's what I was asking | 03:57.15 |
| | so autotools config files aren't already (at least, completely) there? | 03:57.43 |
| vtorri_ | basically, you have to write a file named configure.ac, and one or several Makefile.am files | 03:57.56 |
| | the autotools will create, from these files, the files configure (which will configure your project) and the Makefile files | 03:59.32 |
| | then run 'make' | 03:59.38 |
| Global_Odey | I see that configure.ac is there but there's no automake files... | 04:00.06 |
| | so this is going to take a while? | 04:00.26 |
| vtorri_ | what is the projet you want to bild ? | 04:00.31 |
| | build* | 04:00.35 |
| Global_Odey | I've got a program that depends on libspectre and I need libgs to build libspectre | 04:02.20 |
| vtorri_ | ho | 04:05.42 |
| | use the prebuilt libgs | 04:05.58 |
| | that's what i do, as i'm als using libspectre | 04:06.10 |
| Global_Odey | ? | 04:06.12 |
| vtorri_ | also* | 04:06.16 |
| Global_Odey | on OS X? | 04:06.28 |
| vtorri_ | well, on linux, there are packages | 04:07.21 |
| | on windows, there is a prebuilt bin | 04:07.30 |
| | i don't know for mac | 04:07.35 |
| Global_Odey | that's just it | 04:07.53 |
| | the doc lists a way to get a shared lib for seemingly every platform but OS X | 04:08.41 |
| vtorri_ | http://downloads.ghostscript.com/public/ <--- that's where you get the source files ? | 04:09.45 |
| Global_Odey | yeah, I just got 9.07 | 04:10.08 |
| vtorri_ | i'll look at it | 04:10.46 |
| | it will take some time | 04:10.52 |
| Global_Odey | ok | 04:11.00 |
| | well thank you for your time | 04:11.16 |
| vtorri_ | so there are no Makefile.am ? | 04:11.21 |
| Global_Odey | no | 04:11.52 |
| | and autogen.sh really just boils down to an autoconf and ./configure | 04:12.24 |
| vtorri_ | you already have the dependencies ? (libjpeg, zlib, libpng) | 04:13.15 |
| Global_Odey | yeah | 04:13.23 |
| | the gs bin builds just fine | 04:13.40 |
| vtorri_ | but no libgs | 04:13.57 |
| Global_Odey | nope | 04:14.04 |
| | I'll dig through the Makefile to see if there's a special target or something | 04:14.38 |
| | the lib for linux is made with 'make so' | 04:15.49 |
| vtorri_ | indeed | 04:18.14 |
| | i'm reading the doc | 04:18.22 |
| | Global_Odey, open the file gs/doc/Make.htm with your browser | 04:21.13 |
| | in the Mac OS X section, there are some doc | 04:22.01 |
| Global_Odey | ok | 04:22.11 |
| | oh | 04:23.05 |
| vtorri_ | copy the top level Makefile and name the copy Makefile.orig | 04:23.13 |
| | the | 04:23.15 |
| Global_Odey | yeah that was about the only doc I could find | 04:23.25 |
| vtorri_ | cp gs/base/macosx.mak Makefile | 04:23.32 |
| | try to run configure again and make | 04:24.04 |
| Global_Odey | unfortunately, the Metrowerks Codewarrior it references is probably more than 10 years old | 04:24.24 |
| | but I'll try it | 04:24.28 |
| vtorri_ | note that i said 'macosx.mak' | 04:25.25 |
| | not 'macos-mcp.mak' | 04:25.37 |
| Global_Odey | oh wait, configure recreates the Makefile | 04:27.18 |
| vtorri_ | honestly, that would be much simpler with all the autotools and not only autoconf | 04:27.27 |
| | ho | 04:27.30 |
| | sorry | 04:27.33 |
| | copy again and make :) | 04:27.40 |
| Global_Odey | yeah I just tried that and oddly enough it throws up a few errors about genconf | 04:29.20 |
| | which I think I read somewhere is a source file that only after you fix it will it tell you the configuration you need | 04:30.23 |
| vtorri_ | can you paste the errors in pastebin ? | 04:31.06 |
| Global_Odey | there isn't much | 04:31.35 |
| | it's mainly just 'make: I./base: Command not found' | 04:32.09 |
| | and then a few errors stemming from that | 04:32.33 |
| vtorri_ | ok | 04:33.54 |
| | does the file 'configure' exist in gs/ ? | 04:37.08 |
| | or is there only configure.ac ? | 04:37.15 |
| Global_Odey | yeah configure is there | 04:38.24 |
| vtorri_ | so go into gs/ | 04:38.36 |
| | and run | 04:38.40 |
| | ./configure --enable-dynamic | 04:38.52 |
| | then make | 04:38.55 |
| Global_Odey | ok | 04:39.06 |
| | ... | 04:41.38 |
| vtorri_ | not good ? | 04:41.48 |
| Global_Odey | oh | 04:41.56 |
| | no I just meant it's still running | 04:42.05 |
| vtorri_ | ok | 04:42.09 |
| | do you have a multi processor ? | 04:42.31 |
| | dual cores or quadri cores ? | 04:42.49 |
| Global_Odey | yeah I'm running -j2 | 04:42.51 |
| vtorri_ | ok :) | 04:42.55 |
| | if it does not work, there will be another thing to test :) | 04:43.26 |
| Global_Odey | yeah this mac wouldn't be nearly as old if it didn't cost so much to get a new one :) | 04:43.57 |
| vtorri_ | :) | 04:45.20 |
| | btw, do you know the brew package manager ? | 04:45.36 |
| Global_Odey | yeah | 04:46.27 |
| vtorri_ | there is a ghostscript mackage in it | 04:46.44 |
| | looking at the source, it seems that it installs libgs | 04:47.03 |
| | but i'm not sure | 04:47.07 |
| Global_Odey | ah man | 04:47.25 |
| | I've looked at recipes in the past for other things I have trouble building | 04:48.10 |
| | and that crossed my mind but I don't know why I didn't try that first | 04:49.03 |
| | holy cow | 04:52.17 |
| | it just uses the 'so' make target (well, indirectly by using 'install-so') to get libgs | 04:53.19 |
| | I'm trying it right now... | 04:54.06 |
| | ha! | 05:03.40 |
| | sure enough | 05:03.44 |
| | well thanks again | 05:04.05 |
| | looks like I'll be off to file a bug against the documentation | 05:04.24 |
| Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=d7a79bb7a88abfca9b1e0bc79703951f5a1e4bc5 | 10:26.11 |
| tor8 | nods. | 10:26.36 |
| Robin_Watts | ta. | 10:36.56 |
| | I fixed the mutex stuff in the windows 7 project last night. | 10:37.35 |
| | Tiny patch on my winRT branch, which contains all mvrhel's stuff rebased down to a single commit with formatting changes etc. | 10:38.07 |
| | I reckon it's easily good enough to commit as is. | 10:38.31 |
| | Can anyone else reach: http://www.easysw.com/~mike/rasterview/index.html | 11:02.42 |
| chrisl_r61 | Robin_Watts: nope, it looks like the site is down, according to http://www.downforeveryoneorjustme.com | 11:09.42 |
| Robin_Watts | thanks. | 11:10.32 |
| chrisl_r61 | Robin_Watts: I have rasterview 1.2.1 if that's any help | 11:10.49 |
| paulgardiner | robin_watts, tor8: I've documented the Android app class structure. Here's the commit: http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=commitdiff;h=08dc4a137134408397b6f8b17d35267164e750f1 | 11:32.24 |
| | The three commits after it should be held off until we get openssl included. | 11:32.57 |
| kens | thinks the Ghostscript devices are insane | 11:45.45 |
| tor8 | paulgardiner: still working on that... hopefully later today. | 11:46.01 |
| sebras_ | paulgardiner: in android or in doc/ that's the question... ;) | 11:48.11 |
| paulgardiner | sebras: I'm happy to go with the consensus | 11:55.03 |
| sebras | paulgardiner: I'm not sure which one is more appropriate, but maybe we want to keep most of the docs in one place? tor8? Robin_Watts? opinions? | 11:58.42 |
| sebras | is probably wrong. :) | 11:58.50 |
| paulgardiner | tor8: You should avoid finishing it off today: you'll just be back on Gtk+ | 12:14.59 |
| Robin_Watts | IMHO, doc is the place for mupdf docs. But android specific docs should be in android. | 12:19.54 |
| | (or maybe android/doc) | 12:19.59 |
| | paulgardiner: "menues" and "annotaton" | 12:56.14 |
| paulgardiner | oops | 12:56.49 |
| Robin_Watts | Would an ascii-art chart of the hierarchy be possible? | 12:56.50 |
| | Maybe just indenting (and reordering?) the existing text would be enough. | 12:57.47 |
| paulgardiner | robin_watts: thought about a chart, but it isn't really a hierarchy | 12:57.48 |
| Robin_Watts | Well, when X subclasses Y, there is a 'directionality' there. | 12:58.34 |
| | And there is kind of an implied tree with the Adapter/AdapterView stuff, right? | 12:59.21 |
| paulgardiner | It would be all bits and bobs all over the place: most of the subclassing is of ssystem classes | 12:59.32 |
| | I don't know. I don't really see the Adapter/AdapterView thing as a tree | 13:00.21 |
| Robin_Watts | yeah, but for people like me, (non (or beginner) android programmers) that specific knowledge is some of the most crucial. | 13:00.39 |
| | Don't panic about it. I may try and draw myself a diagram if I get bored at some point. The text is massively helpful as is. | 13:01.27 |
| paulgardiner | Which may imply that more explanation is needed, but I can't see how to do it well with trees. | 13:01.27 |
| Robin_Watts | kens, chrisl: Whose is the Debug-cups thing in the vs makefile? | 13:04.44 |
| chrisl_r61 | Robin_Watts: say what now? | 13:05.07 |
| Robin_Watts | In the vs project, there is a "Debug-cups" config option. | 13:05.20 |
| chrisl_r61 | You added that, didn't you? | 13:05.37 |
| Robin_Watts | essentially, it adds 'WITH_CUPS=1' | 13:05.42 |
| | I don't remember adding that. | 13:05.47 |
| | but that doesn't prove anything :) | 13:06.07 |
| chrisl_r61 | The makefile content is mine, I added that, but I didn't touch the project file | 13:06.34 |
| Robin_Watts | Right. | 13:06.50 |
| | The build log goes into Debug-cups, but the binary goes into debugbin/debugobj as usual. | 13:07.28 |
| | and when I just did a build, it didn't rebuild gswin32c.exe, but did rebuild gswin32.exe | 13:07.52 |
| chrisl_r61 | Yeh, that's how I did it | 13:07.54 |
| Robin_Watts | I'm trying a rebuild now. | 13:07.56 |
| chrisl_r61 | It's not something I really want encourage people to use, hence I didn't want it in the project | 13:08.53 |
| Robin_Watts | ok. | 13:09.00 |
| paulgardiner | robin_watts: I've corrected those typos you spotted. | 13:10.57 |
| tor8 | I agree with robin watts on doc location (android specifics belong with the android code) | 13:19.31 |
| Robin_Watts | tor8; happy for me to push paulgardiner's stuff ? | 13:19.50 |
| tor8 | Robin_Watts: go ahead push the docs. the openssl based stuff should probably wait a bit. | 13:21.16 |
| Robin_Watts | tor8: I've not braved that :) | 13:21.29 |
| tor8 | paulgardiner: fontdump, cquote, and bin2hex do similar things. maybe combine them into one tool? | 13:22.26 |
| paulgardiner | tor8: or should have common code pulled out into a separate file. | 13:23.36 |
| Robin_Watts | Morning mvrhel_laptop | 14:01.28 |
| mvrhel_laptop | morning robin_watts | 14:01.45 |
| | robin_watts: so did you commit your fixes to my repos or where can I get them? I have other changes related to text search progress, password and keyboard based zooming | 14:20.15 |
| Robin_Watts | mvrhel_laptop: My changes are on the winRT branch on my repo. | 14:20.43 |
| | It's not clear to me how you want to proceed here. | 14:21.07 |
| | If you were to take on my branch, you'd lose the development history. | 14:21.25 |
| mvrhel_laptop | well, I would like your fixes related to the lock and the tab/spacing | 14:21.50 |
| Robin_Watts | I can work some git magic whereby I can arrange to put my revised commit at the end of your branch, I think. | 14:22.15 |
| mvrhel_laptop | I don't want to have problems putting my changes here into play though | 14:22.50 |
| Robin_Watts | mvrhel_laptop: Why don't you push your changes onto your branch. | 14:23.08 |
| mvrhel_laptop | ok | 14:23.18 |
| Robin_Watts | Then I'll pull those into mine, and put a revised version of my patch onto the end of your branch? | 14:23.35 |
| | mvrhel_laptop: I've just realised it's 3:30, and I haven't had lunch yet. My internal clock goes to pot on days when Helen is out. | 14:27.33 |
| | Yell when you've pushed the commits and I'll do that straight after lunch. | 14:27.53 |
| tor8 | paulgardiner: what's the status with openssl on android? | 14:29.15 |
| | do we need to build or is it available as a system lib? | 14:29.26 |
| mvrhel_laptop | robin_watts: ok. done. off for breakfast and taking kids to school | 14:29.34 |
| paulgardiner | tor8: oh. I hadn't thought of that. I'd imagine it isn't available, but I don't know for sure. | 14:30.13 |
| tor8 | paulgardiner: how are you building it on android then? | 14:30.30 |
| paulgardiner | tor8: I've yet to get it working for android. | 14:30.50 |
| | It's Windows only at the moment | 14:31.06 |
| tor8 | making our build system call config && make was trivial enough, but the more I look at building it manually the more I get scared | 14:31.11 |
| | building libcrypto.a compiles roughly 600 files... | 14:31.21 |
| sebras | tor8: but they compile quite quickly, no..? | 14:31.44 |
| | at least they do at work. | 14:31.50 |
| tor8 | sebras: takes a minute or two | 14:31.54 |
| sebras | tor8: I would be surprised if we need more than 6 of those (without the digital signatures). | 14:32.28 |
| tor8 | sebras: yeah. just getting the ones we need for encryption would be trivial. | 14:33.04 |
| | it's the q of getting signatures to work and how much is needed there | 14:33.16 |
| | they also have (stupid, stupid, STUPID!) -DL_ENDIAN requirements in their build | 14:33.40 |
| sebras | tor8: do those apply even to the files we need? | 14:34.06 |
| tor8 | sebras: thing is, I don't know which files we actually need yet... | 14:34.23 |
| | sorting through 600 odd files is a bit much | 14:34.34 |
| | ideally we'd build it as a complete static lib and let the linker sort out what we need | 14:35.11 |
| | like we do with libjpeg and freetype | 14:35.20 |
| | less so with freetype, where everything is pulled in unless you have magic configuration headers, which we do have set up in scripts/ | 14:35.51 |
| sebras | tor8: weren't your idea to use libcrypto for PDF encryption as well...? | 14:36.24 |
| | tor8: that sounds like a good start. | 14:36.34 |
| tor8 | sebras: yes, if we're pulling it in for signatures we may as well use it for pdf encryption | 14:36.57 |
| sebras | tor8: but for the other thirdparties we don't compile all .c-files from those project? | 14:37.12 |
| henrys | tor8:there's all kinds of stuff in lib crypto we shouldn't need. seems like a lot to pull in. | 14:40.06 |
| kens | Robin_Watts : canyou look at this please ? : | 14:40.59 |
| | http://stackoverflow.com/questions/16586754/issue-to-build-mupdf-library-for-android | 14:40.59 |
| tor8 | henrys: yeah. I wonder if there are any alternative libraries that do less but still fulfill our needs. | 14:41.08 |
| kens | I'm guessing the user has not got X11 installed, but I don;t know | 14:41.15 |
| kens | coffees | 14:41.53 |
| tor8 | kens: rats. yeah, easiest is for him to compile with "make generate NOX11=yes" | 14:44.15 |
| | X11 libs shouldn't be tacked on for command line tools though... should fix that in the makefiles | 14:45.05 |
| tkamppeter | Robin_Watts, did you get my mail? | 14:52.11 |
| kens | tor8 will you reply to him ? | 14:52.47 |
| | Or I can if you prefer | 14:53.08 |
| tor8 | kens: I can reply. | 14:56.02 |
| kens | OK thanks | 14:56.07 |
| Robin_Watts | tkamppeter: Yes, it arrived a while ago. | 14:58.20 |
| | I've not had a chance to look at it in detail yet. Give me an hour or two. | 14:58.34 |
| tkamppeter | Robin_Watts, OK. | 14:59.26 |
| henrys | Robin_Watts:can this be forwarded to tech? | 15:01.31 |
| Robin_Watts | sure. | 15:01.52 |
| | tkamppeter: I spent this morning making mudraw capable of outputting pwg format. | 15:02.36 |
| tkamppeter | tkamppeter, great! | 15:23.22 |
| | tkamppeter, Robin_Watts great | 15:23.35 |
| Robin_Watts | I haven't tested it/committed it yet. | 15:24.10 |
| | Unfortunately the site for rasterview appears to be down. | 15:24.24 |
| | Maybe mvrhel_laptop could mention that to mike sweet ? :) | 15:24.35 |
| tkamppeter | Robin_Watts, I can send Rasterview to you. The CUPS infrastructure is broken down and in emergency service. Mike is waiting for getting infrastructure at Apple. | 15:33.19 |
| Robin_Watts | tkamppeter: Please, that would be much appreciated. | 15:33.43 |
| tkamppeter | Robin_Watts, see Tuesday's CUPS talk of the OpenPrinting Summit. | 15:33.50 |
| Robin_Watts | tkamppeter: Right, I skimmed the slides this morning and saw that. I didn't realise that easysw.com was part of that issue. | 15:37.05 |
| tkamppeter | Robin_Watts, it is in your mail now. | 15:38.22 |
| Robin_Watts | mvrhel_laptop: Yell when you're back in range. | 15:38.30 |
| tkamppeter | Robin_Watts, should Mike drop the hosting of Rasterview, I will re-host it on OpenPrinting. | 15:44.31 |
| Robin_Watts | tkamppeter: I was pondering adding pwg input to mupdf. | 15:44.59 |
| | Would that be useful in any way? | 15:45.06 |
| tkamppeter | Robin_Watts, we would need a rastertopdf filter, butt basing this on MuPDF could be overkill. | 15:48.01 |
| | Robin_Watts, but it could be useful anyway as one could perhaps thing about a mobile device scenario with less CUPS filters, by modifying the filter chains. | 15:49.15 |
| | if MuPDF does it all in one one could perhaps save a lot of resources, but it then would also need to do the job of pdftopdf. | 15:49.55 |
| Robin_Watts | tkamppeter: We don't yet have a full pdfwrite solution for mupdf. | 15:50.47 |
| | so we can't do pdf out reliably. | 15:50.59 |
| tkamppeter | So MuPDF would only do the rastertopcl, rasterto... filters, which would be overkill in the print workflow | 15:52.18 |
| | Robin_Watts, but I have an idea now for what it is good: A CUPS/PWG Raster screen viewer for debugging the print workflow, like Rasterview, but better maintained, and perhaps a beter UI. | 15:53.17 |
| Robin_Watts | tkamppeter: Current MuPDF can read PNGs,TIFs and JPGs. | 15:54.03 |
| | (as well as PDF/CBZ/XPS) | 15:54.13 |
| | If we had code to read cups/pwg files to pixmaps, it would be trivial to add CUPS and PWGs to that list. | 15:55.02 |
| tkamppeter | Robin_Watts, that is great, it makes MuPDF a universal doc/photo viewer to reduce the footprint on mobile. | 15:56.25 |
| henrys | tkamppeter: we'd like to get http://bugs.ghostscript.com/show_bug.cgi?id=693715 tested, any ideas? | 15:59.48 |
| | I was thinking of having a webpage to solicit volunteers to help us test printer on ghostscript.com | 16:01.28 |
| | or even more than one printer ;-) | 16:02.34 |
| tkamppeter | henrys, this would be great for bugs which are dependent on hardware. | 16:02.44 |
| henrys | too bad chrisl isn't here - I wanted to see what he'd do when I said "Drupal" could solve that. | 16:04.22 |
| | tkamppeter:I'll bring it up next agenda. | 16:06.02 |
| Robin_Watts | plays the VMware game with Ubuntu. | 16:06.10 |
| henrys | I mean next meeting - Tuesday | 16:06.31 |
| | Robin_Watts: I like having a headless linux box. | 16:07.40 |
| Robin_Watts | henrys: I have casper or peeves for that :) | 16:08.33 |
| henrys | I wouldn't like a headless linux box without 1G ethernet. | 16:08.58 |
| | to it. | 16:09.07 |
| | so why do you need vmware? | 16:09.36 |
| Robin_Watts | henrys: For when I want to run X stuff really. | 16:10.01 |
| | for instance, I've got to try and build rasterview now. | 16:10.09 |
| | VMWare works well, except the constant need to update everything before I start work. | 16:10.42 |
| henrys | ssh -X works to a mac but I suppose not to windows. | 16:10.43 |
| kens | Only if you are running a ssh server | 16:11.34 |
| Robin_Watts | ssh -X forwards the X ports. | 16:12.02 |
| henrys | kens:casper is running the ssh server | 16:12.04 |
| | you need cygwin X11 | 16:12.11 |
| Robin_Watts | The problem is that windows doesn't have an X server. | 16:12.14 |
| | Xmingw by preference. | 16:12.28 |
| henrys | I have done X on casper and find the performance annoying. But I didn't look at improving it, possibly with ssh compression or something. | 16:14.27 |
| Robin_Watts | henrys: Right. I use casper and peeves when I can live with terminal access. | 16:14.47 |
| | Having a VM here that runs unix is just much easier. | 16:14.58 |
| | and I don't need the hassle of another physical box in my office. | 16:15.08 |
| henrys | Robin_Watts:yes I guess if I weren't saddled with the regression boxes I'd feel the same. | 16:15.43 |
| | kens:there was something I was supposed to look at which fell out your last pcl->pdf change and I can't remember what it was, were you to report a bug? | 16:16.46 |
| Robin_Watts | tkamppeter: Well, rasterview can see tiger.pdf :) | 16:19.02 |
| kens | henrys I didn't open a bug, I will if you like | 16:19.32 |
| Robin_Watts | and in greyscale too. | 16:19.47 |
| henrys | kens:up to you tell me, mail me or bug me. | 16:20.00 |
| kens | It was the PCL bitmap character building when a character has no data | 16:20.03 |
| henrys | kens:good enough, got it. | 16:20.21 |
| tkamppeter | Robin_Watts, do you have rasterview running now? Then you are ready for testing your work. | 16:20.47 |
| Robin_Watts | tkamppeter: Yes, I have it working, and it's successfully shown both an rgb and a greyscale output PWG from mupdf. | 16:21.15 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=b999611774f903d82df05b1129bf4f320d79371a | 16:22.08 |
| kens | OK henrys, thanks | 16:22.39 |
| tkamppeter | Robin_Watts, so what is needed for a pdftoraster filter is that one can control by command line resolution, color space, ..., all embedded parameters, so that one can add MuPDF support to the pdftoraster filter of cups-filters. | 16:23.50 |
| Robin_Watts | tkampeter: mudraw -o out-%d.pwg -r 200 in.pdf will get you rgb. | 16:24.52 |
| tkamppeter | Robin_Watts, it must be possible to make it doing everything what the Poppler and GS pdftoraster filters are capable of. | 16:24.56 |
| Robin_Watts | tkampeter: mudraw -o out-%d.pwg -r 200 -g in.pdf will get you greyscale. | 16:25.02 |
| | tkamppeter: Can you point me at docs for pdftoraster ? | 16:25.31 |
| kens | OK goodnight all | 16:26.54 |
| Robin_Watts | tkamppeter: Looking at http://www.openprinting.org/download/printing/pdf-printing/pdftoraster.c it looks like there are a lot of command line options for passing in cups parameters to be dumped into the header. | 16:28.53 |
| tkamppeter | Robin_Watts, this is the case, but said file is out of date. Please check the pdftoraster source code in the cups-filters package (the Poppler-based filter) or cups/gstoraster.c in Ghostscript. | 16:32.58 |
| | Robin_Watts, the best for consistency would perhaps be merging gstoraster into the pdftoraster of cups-filters and adding MuPDF support. | 16:34.05 |
| Robin_Watts | tkamppeter: I am loathe to add hundreds of new command line switches to mudraw. | 16:35.57 |
| | which means we should probably have a separate mupdftoraster thing. | 16:36.27 |
| tkamppeter | Robin_Watts, perhaps this would actually be the best solution. | 16:37.58 |
| ray_laptop | robin_watts: in your list of "what's wrong with the winRT email" you said "Converted the C/CPP files from space based indents to tab based ones." | 16:38.44 |
| | robin_wattsI thought we all decided that tabs were bad and we had to convert all the GS stuff to spaces (which is a major pain for me) | 16:39.20 |
| | robin_watts: so how come the winRT code is the other way around ? | 16:40.03 |
| Robin_Watts | ray_laptop: mupdf uses tabs for indentation. And only tabs. | 16:42.41 |
| | gs uses spaces, and only spaces. | 16:42.54 |
| | My personal preference is for spaces, and I believe the consensus was that spaces were better - hence gs adopting that way of working. | 16:43.41 |
| | mixed is certainly evil. | 16:43.46 |
| | tor8 prefers tabs, so mupdf stayed with tabs. | 16:44.02 |
| ray_laptop | mixed is smaller than spaces and allows for indent 4 | 16:44.25 |
| Robin_Watts | and my email wasn't intended as "Look what mvrhel got wrong!" :( | 16:44.40 |
| ray_laptop | robin_watts: but we already had that discussion. | 16:44.43 |
| Robin_Watts | It was "here is a squashed history version for people to look at, and here are the few small things I have questions about" | 16:45.20 |
| tor8 | ray_laptop: mupdf coding style with "tabs for indent, no vertical alignment" allows for any indent of your choice. just set the tab stop size. | 16:46.17 |
| tkamppeter | Robin_Watts, mvrhel_laptop, marcosw, Feature Freeze for Ubuntu Touch is around mid-August, but printing will perhaps only get into the second phone, around half a year later (first model will be a more low-end). | 16:51.42 |
| | Robin_Watts, mvrhel_laptop, marcosw, I will have a meeting tomorrow 11am CEST about that. | 16:53.13 |
| mvrhel_laptop | robin_watts : dont worry I am thick skinned about criticism even if the code is still a work in progress ;) | 18:00.38 |
| Robin_Watts | mvrhel_laptop: Sure, but none of it was meant as criticism. | 18:01.03 |
| | so I've pushed a new branch to my repo, winRT2 | 18:01.26 |
| mvrhel_laptop | ok | 18:01.53 |
| Robin_Watts | That has your branch (rebased onto the current master), plus my polishing, plus my lock commit, plus your latest commit. | 18:02.03 |
| mvrhel_laptop | robin_watts: so I guess I should grab that branch and then go ahead and push it to my repo and start working from there? | 18:03.58 |
| Robin_Watts | mvrhel_laptop: If you're happy with what I've done, yes. | 18:04.12 |
| mvrhel_laptop | I can always change it if I am not ;) | 18:04.45 |
| Robin_Watts | mvrhel_laptop: Then, yes, grab away. | 18:05.28 |
| mvrhel_laptop | ok. brb. need to help wife with something then I will attempt | 18:05.51 |
| Robin_Watts | I'd be happy to see that merged with master so you don't have to keep rebasing it. | 18:06.04 |
| | Would be nice to get the nod from tor8 for that... | 18:06.16 |
| tor8 | Robin_Watts: I haven't looked over the winRT branch yet, but go ahead and commit anyway | 18:07.30 |
| | though I think I'd prefer the squished version so I can easily see the initial diff all in one place :) | 18:07.58 |
| Robin_Watts | tor8: It'll be a merge, so the history will be there on a branch. | 18:08.31 |
| tor8 | I'm not sure about the changes in base_time.c though | 18:09.01 |
| Robin_Watts | and diffing across the branch will give you a single change. | 18:09.10 |
| tor8 | #if define(_WIN32) && !defined(_WINRT) ? | 18:09.26 |
| Robin_Watts | I mean: git diff merge~1..merge | 18:09.35 |
| tor8 | fopen_utf8 should probably move to a file of its own | 18:10.17 |
| Robin_Watts | tor8: possibly we should rename base_time.c to be plat_win32.c or something. | 18:13.18 |
| | or plat_win.c ? | 18:14.02 |
| | That way fopen_utf8 would make sense to stay there. | 18:14.16 |
| tor8 | yeah, that works for me | 18:15.17 |
| | though we do have a handful of ifdef _WIN32 spread throughout the files | 18:16.22 |
| mvrhel_laptop | robin_watts: so are you moving this all into master then? | 18:22.50 |
| | if you want to do that first that is fine | 18:23.01 |
| Robin_Watts | mvrhel_laptop: If you're happy with that. | 18:23.04 |
| | I'll do that now then. | 18:23.08 |
| mvrhel_laptop | ok | 18:23.10 |
| Robin_Watts | Hmm. It really wants to use a fast forward. Let me cheat a bit. | 18:25.39 |
| | OK, so master will look like this (ignoring the last 2 work in progress commits) | 18:32.26 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=summary | 18:32.30 |
| | bugger, no it won't. | 18:32.59 |
| | mvrhel_laptop: Do you want the history kept? | 18:33.40 |
| | I can put it in as I have there, and it means the history is kept on a separate branch. | 18:36.07 |
| | git diff master~1..master will give tor8 his single diff. | 18:36.29 |
| | but I can't see how to do it so I get the diff nicely in the web view. ho hum. | 18:36.51 |
| | I don't think I'm going to get better than this, so I'll push it. | 18:37.00 |
| | mvrhel_laptop, tor8: pushed to golden. | 18:37.40 |
| tor8 | Robin_Watts: two patches on tor/master | 18:43.00 |
| Robin_Watts | I thought I'd got all the trailing whitespace - from the .cpp and .h files at least. | 18:44.05 |
| tor8 | I just piped all files through "git stripspace" | 18:44.45 |
| Robin_Watts | So... you change from X11_LIBS to SYS_X11_LIBS | 18:45.55 |
| tor8 | Robin_Watts: it was a mess. cmapdump and non-x11 tools got the SYS_X11_LIBS as well :( | 18:46.30 |
| | and X11_LIBS was never set | 18:46.41 |
| Robin_Watts | I can't see any changes for cmapdump etc. | 18:47.13 |
| tor8 | I removed the line LIBS += $(SYS_X11_LIBS) from Makethird | 18:47.34 |
| Robin_Watts | Ah! | 18:47.47 |
| | Gotcha. | 18:47.56 |
| | yeah, that's nicer. | 18:48.01 |
| | I'll push them. | 18:48.07 |
| mvrhel_laptop | Robin_Watts: ok. I pulled everything. so the remaining things for me to get working are, password finish, zooming with keyboard (almost done), state saving, and a couple issues when the device orientation changes | 19:17.03 |
| | so, now I will just push into my repos on the master and then when I get to a spot where I think it looks good, do I have you and tor8 review and then commit to golden? | 19:18.06 |
| tor8 | mvrhel_laptop: yes. when you have things you want to put on master, ping me or Robin_Watts and we'll review and push when all is good | 19:19.15 |
| mvrhel_laptop | ok sounds good | 19:19.35 |
| tor8 | or we'll complain about things to fix and refuse to push :) | 19:19.36 |
| mvrhel_laptop | fair enough | 19:19.59 |
| | I need to get cracking on the icc branch | 19:20.13 |
| | I wanted to write up a couple thoughts on how I think that should be done to have you and robin_watts look over before I get started | 19:20.38 |
| | I will try to get that to you by next week tor8 | 19:20.47 |
| tor8 | sounds good. feel free to pester me or robin if there is anything we can help with. | 19:21.43 |
| | we've both messed about with the color space code | 19:21.54 |
| mvrhel_laptop | ok thanks | 19:21.59 |
| | the main thing I was wondering about is how do you want the API to be set up. I was thinking that you have some fz_ procedures that you can call to initialize the default profiles and the device profile and enable using ICC. That way things stay pretty much the way they are and if someone wants to do ICC stuff they need to make these extra set up calls | 19:24.02 |
| tor8 | it would be good to have the default "fast" color spaces as they are | 19:24.37 |
| mvrhel_laptop | yes. I agree | 19:24.53 |
| tor8 | currently when rendering we create a pixmap with a specific colorspace object | 19:25.11 |
| | I'm not sure if it's feasible to just create an ICC based colorspace, pass that to the pixmap constructor and then everything would work off of that | 19:25.58 |
| | I guess you'll need some input profile for the devicergb etc colorspaces? | 19:26.17 |
| mvrhel_laptop | yes. that needs to be part of the setup I mentioned above | 19:26.33 |
| | really 3 defaults for the sources and a device profile | 19:27.17 |
| tor8 | so fz_new_input_profile for the device* colorspaces, and fz_new_output_profile for the destination pixmap's colorspace? | 19:28.08 |
| mvrhel_laptop | right. plus we would want a cielab profile | 19:28.27 |
| | not sure how best to handle that | 19:28.42 |
| | I don't want to bloat the rom footprint | 19:28.51 |
| tor8 | currently we have a fz_colorspace struct which is used for both input and output profiles | 19:28.53 |
| | would you want to split that into two separate structs? | 19:29.07 |
| mvrhel_laptop | no | 19:29.10 |
| | since the profiles are 2 way it is fine | 19:29.20 |
| tor8 | right. so just a fz_new_colorspace() from icc and cielab data which will internally use lcms profiles. | 19:29.56 |
| | how big would default icc profiles for srgb and swop cmyk be? | 19:30.29 |
| | we already have some pretty bloated data chunks in the rom (hello CJK fonts and cmaps... ugh) | 19:30.49 |
| | we could make a "hack" for the device colorspaces | 19:31.20 |
| mvrhel_laptop | I have cut them down a lot for gs (cmyk was the big one). let me check. but I would picture this as perhaps not being part of the default set up, but a special add on if needed | 19:31.23 |
| tor8 | if the output is also a device colorspace, just use the current fast path | 19:31.28 |
| | if the output is an icc colorspace, instantiate a proper sRGB profile | 19:31.50 |
| | I think if we have it we'd ideally want to use it by default unless it makes everything ten times slower | 19:32.13 |
| mvrhel_laptop | swop cmyk profile is 184K. the rest are a few K | 19:32.29 |
| tor8 | I think we can live with that rom footprint | 19:32.47 |
| | so I wouldn't worry about that | 19:33.05 |
| mvrhel_laptop | ok. good deal | 19:33.10 |
| tor8 | if it was closer to 1M I'd be more reluctant :) | 19:33.25 |
| mvrhel_laptop | well I need to poke around in the color stuff a bit and I will probably have a bunch of questions | 19:33.29 |
| | I will probably need help from someone in making the link cache thread safe too | 19:34.05 |
| | aka robin_watts | 19:34.11 |
| tor8 | yeah, robin has done lots of global cache work in mupdf so he's definitely better suited to help with that | 19:34.37 |
| | I think my biggest question is what happens with device colorspaces by default in a few situations | 19:35.12 |
| | maybe it should all be configurable | 19:35.16 |
| | 1) device output space, icc image is drawn | 19:35.31 |
| | 2) icc output space, device space image is drawn | 19:35.45 |
| | I'd imaging for device/device the current code would run | 19:35.56 |
| | and icc/icc would invoke the full wrath of lcms | 19:36.05 |
| | this is where you asked about setting up default profiles? | 19:36.25 |
| mvrhel_laptop | yes. so you are asking about the case where we have an embedded ICC profile and a "Dumb color" device? | 19:37.02 |
| tor8 | yeah. mostly. | 19:37.15 |
| mvrhel_laptop | and the case where we have DeviceRGB source but specified a profile for the device | 19:37.17 |
| tor8 | exactly. | 19:37.26 |
| mvrhel_laptop | so for the top one, I would argue we just treat the source ICC color as Device Color like you currrently do | 19:37.54 |
| | for the bottom one, we use the "default" profiles that I mentioned way above | 19:38.20 |
| | but I am open to other ideas if you have some clever thought of making it do different things based on some settings | 19:39.30 |
| tor8 | I was thinking we could have two modes of operation. | 19:39.55 |
| | a "fast" one where any use of a device colorspace would hit the current non-colorspace-managed code | 19:40.19 |
| | and a slow one where we use default profiles installed for both input and output spaces | 19:40.42 |
| mvrhel_laptop | that would make sense to me | 19:41.09 |
| tor8 | of course that means that any icc colorspace would need a fallback colorspace object to do what we have now | 19:41.20 |
| | so if you really don't care about color management, just don't install any profiles and it will behave exactly like today even when there are icc profiles in the PDF file | 19:41.59 |
| mvrhel_laptop | that was what I was thinking originally | 19:42.17 |
| tor8 | but if you install them, you get sane defaults for device colorspaces (assume sRGB or swop) | 19:42.20 |
| mvrhel_laptop | to make use of the ICC stuff you need to do a few setup commands | 19:42.48 |
| tor8 | I think I'm just rephrasing what you said before though... | 19:43.13 |
| | color management on or off based completely on the output colorspace profile being set or not | 19:43.56 |
| | but if output is set, we need a way to set the default device* input profiles | 19:44.22 |
| mvrhel_laptop | yes. we could have the sane defaults loaded but there should be an interface to also use different defaults if desired | 19:45.03 |
| tor8 | definitely. | 19:45.34 |
| mvrhel_laptop | when the output is set, we will go ahead and set the defaults (assuming they were not already set). and then then user can load different ones if desired | 19:45.50 |
| | but with the loading of the output profile, we will be doing an ICC workflow. if no output profile was set, things will work like they do now | 19:46.20 |
| tor8 | the question then is where do we associate them. currently the device colorspaces are constant globals, so they'd have to move into the fz_context. | 19:46.22 |
| | robin would probably want a fz_colorspace_context for that | 19:46.31 |
| mvrhel_laptop | yes that would need to be changed | 19:46.47 |
| tor8 | *or* we associate them with the interpreter | 19:47.16 |
| | and leave them out of the context altogether | 19:47.23 |
| | the context would still have a link cache | 19:47.49 |
| | I think it'll be easier on the API to just leave them as a semi-global in a context | 19:48.23 |
| | but we'll need to move away from globals to accessor functions | 19:48.35 |
| | fz_device_rgb would have to become fz_device_rgb(ctx) function call | 19:48.51 |
| mvrhel_laptop | right | 19:49.23 |
| | ok | 19:49.25 |
| tor8 | and fz_set_device_rgb(ctx, colorspace) to register a new one | 19:49.28 |
| | fz_set_device_rgb(ctx, fz_new_colorspace_with_icc_data(ctx, buffer, len)) or something like that | 19:49.59 |
| | does that sound reasonable? | 19:50.28 |
| mvrhel_laptop | yes. that does sound reasonable. | 19:50.36 |
| tor8 | and then to render: fz_new_pixmap(..., fz_new_colorspace_with_icc_data(ctx, buffer, len)) | 19:50.58 |
| mvrhel_laptop | I will spend a bit of time next week looking at the color code and probably have a pile of questions | 19:51.01 |
| tor8 | mvrhel_laptop: don't feel like the internals of the color code are worth preserving in the shape it's in... we are not averse to ripping out and rewiring everything in completely different shapes | 19:51.56 |
| mvrhel_laptop | ok. that is good to know | 19:52.08 |
| tor8 | the current architecture made the most sense for what we currently have, but it's in no way "holy" :) | 19:52.25 |
| | Robin_Watts: mvrhel_laptop: some patches on tor/master for review (added colorspace context) | 20:30.29 |
| mvrhel_laptop | oh cool | 20:32.37 |
| tor8 | I'd imagine the link cache would be stuffed in there too | 20:35.37 |
| mvrhel_laptop | tor8: looks good to me. so now it will be straight forward to add the icc color space type | 20:53.40 |
| | and it would make sense to put the link cache in there like you said | 20:53.51 |
| | bbiab | 21:05.04 |
| tor8 | I'm off for the night. | 21:15.05 |
| | Forward 1 day (to 2013/05/17)>>> | |
IRC Logs