| | <<<Back 1 day (to 2014/03/11) | 2014/03/12 |
| Robin_Watts | I'm turning my PC off because of the power cuts scheduled tomorrow. | 00:24.08 |
| jroo | I was able to cross compile working binary for PowerPC (at least the pcl6 works). Now I just need to copy all the required files to test further | 10:11.49 |
| | So to cross compile GhostPDL you need to 1) generate arch.h manually; 2) set the CCAUX variable to your cross compiler; 3) patch the configure script so that libtiff configure has --host switch and set LCMS_BIGENDIAN to 0 or 1 in configure script where choss_compile is tested and remove the error message | 10:13.50 |
| | also I configured with --without-x | 10:14.06 |
| | apparently GhostPDL's make does not respect DESTDIR (i.e. make DESTDIR=path/to/root/dir install) because regardles of that it tries to install under /usr/local (so even the --prefix was not working) | 10:15.50 |
| chrisl | GhostPDL's makefiles are considerably less complete on things like that than Ghostscript's - and Ghostscript's aren't exactly complete either..... | 10:16.34 |
| jroo | yeah, I've noticed | 10:16.43 |
| chrisl | I'm surprised --without-x made any difference, too | 10:16.59 |
| jroo | but now it's just manually listing required files. I think I'll use PKGBUILD from aur.archlinux.org as a starting point | 10:17.04 |
| | chrisl, I had issue with missing libraries | 10:17.24 |
| | libSme (or similar) is not available on my target | 10:17.32 |
| | the target's Linux distro is very old | 10:17.44 |
| | ...and very stripped down | 10:18.02 |
| | but thanks for the help. Saved a lot of time | 10:18.15 |
| chrisl | No problem. | 10:18.34 |
| jroo | would it be helpfull if I uploaded a patch file for the changes I made to configure to get the cross compilation to work and the other steps required? | 10:18.51 |
| | I mean would you use that info to make GhostPDL more easy to cross compile | 10:19.17 |
| chrisl | jroo: I actually have a project to integrate the GhostPDL builds into the Ghostscript build system, when that's done, cross compiler will be easier | 10:19.19 |
| | jroo: for example, instead of messing around with libtiff, for your use, you could just leave it out..... | 10:19.52 |
| jroo | ok, I thought of that too but then when the cross compilation for libtiff was easy I thought I just leave it there so that I won't end up having some dependency issues | 10:20.40 |
| chrisl | libtiff is only used by the tiff* output devices, so not really required for conversion to PDF | 10:21.37 |
| robin_watts_mac | My UPS is really unhappy. | 10:26.01 |
| | My house is running on a generator at the moment (leccy board have disconnected mains power and reconnected it to a generator for the day) | 10:26.43 |
| | The UPS can clearly see something odd about the power, cos it's flashing lights and basically having a fit. | 10:27.11 |
| chrisl | robin_watts_mac: what are they doing that they cut the power? | 10:27.22 |
| robin_watts_mac | I suspect they are either working on a substation, or connecting power into a new housing devlopment over the road. | 10:27.58 |
| chrisl | jroo: note that the configure script has --enable-big-endian and --enable-little-endian so you shouldn't need to change it for setting LCMS_BIGENDIAN | 10:34.17 |
| henrys | paulgardiner: I wonder if the android print api in 4.4 will make these printing modules moot, I understand windows mobile already has good printing. | 14:09.52 |
| paulgardiner | henrys: Oh. I should keep up with these things. :-) I hadn't heard about that. | 14:11.05 |
| | Would we need to support old phones that cannot upgrade? | 14:11.47 |
| henrys | paulgardiner: sure that is an issue, arguably less of an issue with fast moving mobile than traditional environments though | 14:13.48 |
| ray_laptop | chrisl: I got distracted yesterday working on fast 4-bit per channel CMYK halftoning and forgot to send you the information on the crash I tripped over (with 1-bit per component case). I just opened a bug and assigned it to you. | 14:18.18 |
| chrisl | ray_laptop: I see it - I'll take a quick look now | 14:18.40 |
| ray_laptop | chrisl: Note that I found it with a debug build on Windows. I didn't try linux | 14:20.13 |
| chrisl | I see a seg fault here, but I need to double check it's not related to the changes I have in my tree | 14:20.58 |
| | ray_laptop: the crash I get on Linux is in do_validate_chunk() during gs_main_finit() :-( | 14:27.59 |
| ray_laptop | chrisl: I just ran it on HEAD and I also see a segfault in the GC do_validate_chunk. I had something different, but that was with my code under development (but, presumably not on a path that I changed) | 14:41.26 |
| | chrisl: so someone is probably stepping on memory. valgrind *might* help | 14:42.11 |
| chrisl | ray_laptop: I don't know if it's related, but mememto suggests we're writing off the end of the raster buffer in ppm_print_page_loop() | 14:42.40 |
| ray_laptop | chrisl: if you get busy with the release and don't want to dive into it, I'll take it back | 14:43.00 |
| | chrisl: Oh. That's a good thing to not do | 14:43.16 |
| chrisl | ray_laptop: I'm wondering if this should be Robin's.... | 14:43.56 |
| ray_laptop | VS sometimes detects that (there are 0xfd guard bytes on the end of buffers) | 14:44.04 |
| | but it didn't seem to detect it this time | 14:44.19 |
| chrisl | ray_laptop: I don't fully follow gx_device_raster() at the moment | 14:45.36 |
| ray_laptop | The gxht_thresh.c code is somewhat prone to writing past normal bounds, but the allocations are /supposed/ to take the over-writing into account | 14:45.48 |
| chrisl | Ah, so possibly gx_device_raster() isn't accounting for that? | 14:46.59 |
| ray_laptop | chrisl: does sound like having Robin take a look would be useful. He did the obj_align_mod and pad additions as well as dabbling (or more) in the gxht_thresh code | 14:48.58 |
| | kens: your update to Projects.htm made me remember this old file (pre-datiing enhancement bugs). Looking at it, I see some things that we have done, some that are no longer relevant, and some that we probably don't want to do. | 14:58.33 |
| kens | ray_laptop : I thought that might be the case | 14:58.59 |
| | I'd behappy if other people would update it too. Also issues.htm, I found a load of stuff in there that was no longer correct | 14:59.32 |
| ray_laptop | I'll take a crack at pruning this and send email if there are things that I think should be dropped (WONTFIX), and add a reference to the enhancement bug list | 14:59.38 |
| | things that are done, I will just remove. | 14:59.56 |
| kens | Yes, that's what I did with the RAM file system ;-) | 15:00.13 |
| | mvrhel_laptop : you got a minute ? | 15:00.27 |
| chrisl | ray_laptop: we talked about removing Projects.htm, but I don't remember coming to a conclusion about it. It seems pointless now..... | 15:00.31 |
| kens | I think it would be good if you could look at issues.htm chrisl, I was amazed at the amount I removed from that. THere may be more that can come out too. | 15:01.44 |
| chrisl | kens: again, I think that's a bit irrelevant nowadays.... | 15:02.12 |
| kens | In projects.htm 1.1 should be dropped, and presumablky 1.2 as well (the 'Netscape' browser ;-) | 15:02.34 |
| | chrisl possible, but we should either drop it or update it | 15:02.49 |
| mvrhel_laptop | kens: I have to run my daughter to school this morning | 15:03.13 |
| kens | mvrhel_laptop : OK I'll be here for a couple more hours | 15:03.25 |
| | at least | 15:03.27 |
| mvrhel_laptop | ok | 15:03.30 |
| kens | Give me a ping when you have a few minutes | 15:03.35 |
| mvrhel_laptop | I did get your email about the v2 profiles | 15:03.46 |
| kens | And I have your reply ;-) | 15:03.53 |
| mvrhel_laptop | ok bbiaw | 15:04.39 |
| chrisl | ray_laptop: we're writing off the end of the buffer in planar_to_chunky(). So I'm guessing we're allocating memory for a planar row, and for some reason writing chunky data into that buffer, and off the end of it | 15:13.13 |
| | ray_laptop: so it looks like pbm_print_page_loop(), although it producing planar data, must allocate space for chunky data in case the fallback case it required | 15:15.00 |
| | Okay, I suppose it would be a silly question to ask why gx_default_get_bits() sets the GB_PACKING_CHUNKY option for a planar device......? | 15:30.22 |
| dev-zero | hi everyone | 15:47.19 |
| | I have the problem that when I disable "Type 1" fonts in fontconfig, ghostscript won't render some of the PDFs I have | 15:47.46 |
| chrisl | robin_watts_mac: I've assigned http://bugs.ghostscript.com/show_bug.cgi?id=695090 to you as it seems like your input would be useful. You might want to punt it to ray_laptop once you've said anything you want to day.... | 15:47.57 |
| kens | So.... Don't do that then, dev-zero | 15:48.09 |
| chrisl | dev-zero: ghostscript fonts are type 1, so...... | 15:48.16 |
| dev-zero | so, it can really only use type 1 fonts, correct? | 15:49.23 |
| kens | No,Ghostscript can use type 1 and TrueType as well as CIDFonts, CFF fonts andt OpenType | 15:49.50 |
| chrisl | dev-zero: no, but the default fonts required to be present by the pdf spec are all type 1 fonts | 15:50.05 |
| kens | But the base 35 fonts supplied with Ghostscript are PostScript type 1 fonts | 15:50.10 |
| dev-zero | ookay, I think I begin to understand :) | 15:51.00 |
| chrisl | dev-zero: is there a reason you disabled type 1 in fontconfig? | 15:51.28 |
| dev-zero | the problem that I have is that when I don't disable Type 1 fonts, then fonts like Helvetica or Courier are rendered using "Nimbus Sans" | 15:51.36 |
| | fc-match Helvetica | 15:51.45 |
| | n019003l.pfb: "Nimbus Sans L" "Regular" | 15:51.46 |
| kens | Tht's the name of the equivalents supplied with GS | 15:51.58 |
| | SOme of the names are trademarked,so we cna't supply fonts with those names | 15:52.11 |
| | Why doe sit matter ? They are equivalent | 15:52.20 |
| dev-zero | ... disabling Type 1 fonts is the default config for the infinality patchset | 15:52.20 |
| | well, Type 1 fonts render poorly here | 15:52.50 |
| chrisl | In ghostscript? | 15:53.04 |
| dev-zero | no, on the display | 15:53.11 |
| kens | They generally render well, at least as well as TrueType and better than the crappy ones people usually use | 15:53.14 |
| | SO don't use type 1 fonts in the display | 15:53.26 |
| chrisl | dev-zero: okay, so you generally don't want type 1's to be found by other applications, but Ghostscript needs to find them | 15:54.02 |
| dev-zero | as far as I tested it, I had the impression that when a page suggests "Helvetica" as its font, Firefox does a 'fc-match' and then uses Nimbus instead | 15:54.13 |
| | chrisl: exactly | 15:54.21 |
| | the only way I found was to provide /usr/share/ghostscript/9.10/Resource/Font | 15:54.41 |
| chrisl | That is probably the default font search path for your Ghostscript build | 15:55.18 |
| dev-zero | and what is the order of lookup? | 16:01.59 |
| chrisl | I can't remember, it's in the documentation | 16:02.21 |
| | IIRC, it *should* check the default path first.... | 16:02.47 |
| dev-zero | ah, so for Helvetica for example it consults the fontmap and then looks for Nimbus, if that isn't found it asks fontconfig instead? | 16:04.38 |
| chrisl | Yes | 16:04.50 |
| dev-zero | hmm, so we can't provide /usr/share/ghostscript/9.10/Resource/Font as a generic fallback then (on Gentoo I mean) | 16:07.15 |
| chrisl | I don't follow - the Ghostscript fonts are the *primary* fonts, not fallbacks for Ghostscript | 16:08.02 |
| dev-zero | well, on Gentoo we don't install /usr/share/ghostscript/9.10/Resource/Font but install the SIL fonts separately and let ghostscript find them via fontconfig (as it seems) | 16:09.07 |
| | disabling Type 1 fonts (by enabling infinality) then breaks ghostscript | 16:09.31 |
| chrisl | Yes, we'd expect that to break ghostscript | 16:09.50 |
| | dev-zero: are all the type 1 fonts (as found by fontconfig) in the same directory? | 16:11.02 |
| dev-zero | no | 16:11.19 |
| | well, have to check | 16:11.26 |
| | but they're not named correctly | 16:11.33 |
| | since fontconfig has a cache and can do arbitrary lookups | 16:12.03 |
| chrisl | Well, frankly, /usr/share/ghostscript/9.10/Resource/Font should be installed - those are the fonts we ship, and that we test with. | 16:12.32 |
| dev-zero | seems that the Type 1 fonts are all in /usr/share/fonts/Type1 | 16:13.03 |
| chrisl | You *might* get Ghostscript working then using FONTPATH command line argument (IIRC) | 16:13.38 |
| | So, -sFONTPATH=/usr/share/fonts/Type1 | 16:14.13 |
| | If that works, you should be able to set the environment variable GS_FONTPATH to that path, and gs should pick that up | 16:15.24 |
| dev-zero | unfortunately the font files are not named NimbusSanL-ReguItal, etc. but c0582bt_.pfb, etc. | 16:15.32 |
| chrisl | dev-zero: did you try it? | 16:15.42 |
| dev-zero | yes | 16:15.56 |
| kens | Sounds to me like the simple answer is just to install our fonts in the expected location | 16:16.09 |
| dev-zero | yes, it probably is | 16:16.22 |
| | thanks a lot guys, I'll report this back to my fellow Gentoo devs | 16:16.39 |
| chrisl | I think that's best. As I said, we test with, and support those fonts. | 16:16.50 |
| dev-zero | ah, found the correct path for the urw-fonts, sorry | 16:23.19 |
| | export GS_FONTPATH=/usr/share/fonts/urw-fonts works perfectly | 16:23.35 |
| | and there we have the upstream copy of the urw fonts | 16:23.46 |
| chrisl | Those should be what we supply | 16:24.06 |
| mvrhel_laptop | missed kens | 17:05.28 |
| chrisl | He might return given it was a read error, and not an exit..... | 17:05.51 |
| mvrhel_laptop | ok | 17:06.40 |
| | brb. need to restart | 17:09.33 |
| | chrisl: are you available for what is likely a very simple question | 17:50.55 |
| chrisl | mvrhel_laptop: sure | 17:51.09 |
| mvrhel_laptop | so in PDFX_def.ps | 17:51.34 |
| chrisl | Okay, go it | 17:52.17 |
| | got it | 17:52.20 |
| mvrhel_laptop | I am supposed to put replace ISO Coated sb.icc with a path to my ICC profile that I want embedded as the output intent | 17:52.32 |
| | I have been putting in C:/vrhel/Artifex_laptop/Docs/icc/default_gray.icc | 17:53.14 |
| | and I keep getting an error from gs | 17:53.22 |
| | about invalidfileaccess | 17:53.36 |
| chrisl | invalidfileaccess suggests we can't open the file, for some reason | 17:54.00 |
| mvrhel_laptop | The Operand stack has the file name on it | 17:54.20 |
| | I guess I need to step through and see | 17:54.34 |
| chrisl | Only the file name? | 17:54.36 |
| mvrhel_laptop | well it has --nostringval-- --nostringval-- (C:/vrhel/Artifex_laptop/Docs/icc/default_gray.icc) (r) | 17:55.00 |
| chrisl | Well, that looks okay | 17:55.45 |
| | mvrhel_laptop: what happens if you just use "(default_gray.icc)"? | 17:56.53 |
| mvrhel_laptop | let me try that | 17:57.06 |
| | same thing :( | 17:58.36 |
| | that file is in the romfs | 17:58.48 |
| | but I dont' know how this part of the code is looking | 17:58.59 |
| chrisl | Yeh, that's what I was thinking.... | 17:59.06 |
| | Okay, how about trying "(%rom%iccprofiles/default_gray.icc)" - I think that's the right path for where they are in the romfs | 18:00.28 |
| | mvrhel_laptop: ^^ | 18:00.41 |
| mvrhel_laptop | good diea | 18:01.20 |
| | idea | 18:01.22 |
| | ok. it seems to be making it through that one | 18:04.22 |
| chrisl | You're not setting -dSAFE or -dSAFER? | 18:04.42 |
| mvrhel_laptop | although it is complaining about my second file (the one that I am converting to X) | 18:04.44 |
| | yues | 18:04.47 |
| | yes I am | 18:04.49 |
| chrisl | Ah, that might cause problems accessing random files | 18:05.11 |
| mvrhel_laptop | ok | 18:05.17 |
| chrisl | IIRC, -dSAFER won't allow you to open any non-"libfile" other than the one specified as the input file on the command line | 18:07.05 |
| mvrhel_laptop | ok | 18:07.15 |
| | let me try now | 18:07.19 |
| | chrisl: ok that seems to have fixed that issue | 18:08.27 |
| | thank you | 18:08.29 |
| chrisl | NP | 18:08.39 |
| | I suppose it might be an idea to add code to PDFX_def.ps to throw an error if it's called with -dSAFER.... | 18:09.18 |
| mvrhel_laptop | yes. alright. now it all seems to be working. thanks again chrisl | 18:10.38 |
| chrisl | Cool! | 18:10.51 |
| | mvrhel_laptop: note that the same issue will arise with PDFA_def.ps, too | 18:13.57 |
| mvrhel_laptop | chrisl: right | 18:15.51 |
| | a question is, when do we want to use -dSAFER | 18:16.07 |
| chrisl | Well, SAFER is mainly intended to prevent Postscript files from accidentally executing malicious code from elsewhere on your file system without your knowledge | 18:17.42 |
| | Personally, I think it's over very limited use in preventing compromise of your computer because, to get the bad file onto your computer, a cracker would already need access to your file system | 18:18.51 |
| | For my part, I never use it, and usually recommend others drop it when I see them using it....... | 18:20.05 |
| | mvrhel_laptop: it might be a good idea to get Ray's opinion on -dSAFER, though, he knows more of the background than I do | 18:26.24 |
| mvrhel_laptop | chrisl: ok thanks | 18:27.16 |
| | so all the conversions seem to be working X3 Gray and CMYK and A1 and A2 RGB and cmYK | 18:27.44 |
| | now I will do the trick ken gave me to extract PDF pages and reassemble | 18:28.04 |
| | and then the trick of the media size to select a region on a page | 18:28.30 |
| chrisl | mvrhel_laptop: Ken mentioned possibly adding something to the pdf interpreter to make extracting/reordering pages easier, maybe talk to him before you implement that? | 18:29.19 |
| Robin_Watts | mvrhel_laptop: Extracting PDF pages can be neatly done using mutool clean. | 18:30.35 |
| chrisl | Robin_Watts: but not if you want PDF-X, PDF-A or Postscript out..... | 18:33.30 |
| Robin_Watts | chrisl: True indeed. | 18:33.52 |
| chrisl | It would probably good to do a simple "extract pages" with mutool, though | 18:34.09 |
| mvrhel_laptop | Robin_Watts: and I can merge pages 3 7 9 and 13 into a new pdf? | 18:35.51 |
| | with mupdf? | 18:35.59 |
| | that is what kens showed me with ghostscript this weekend | 18:36.25 |
| | and is what I want to be able to do | 18:36.47 |
| chrisl | mvrhel_laptop: mutool takes a list of pages to process, I assume it will dump them to a new PDF | 18:37.56 |
| mvrhel_laptop | so this is not to do with PDF-X or PDF-A | 18:37.56 |
| | I will have a look at it | 18:38.18 |
| chrisl | mvrhel_laptop: no, but what if I want to select pages for a conversion route? | 18:38.37 |
| mvrhel_laptop | chrisl: then I would tell you that you are being difficult | 18:39.10 |
| Robin_Watts | mvrhel_laptop: You can't merge pages from 2 pdfs. | 18:39.12 |
| mvrhel_laptop | ;) | 18:39.13 |
| | Robin_Watts: no just pages 3 7 9 and 13 from a single PDF. | 18:39.36 |
| | and save them as a new PDF | 18:39.43 |
| Robin_Watts | mutool clean in.pdf out.pdf 3,7,9,13 | 18:39.59 |
| mvrhel_laptop | very good. I need to look over the source code for that then | 18:40.16 |
| chrisl | mvrhel_laptop: :-) I figured you'd want both a simple extract/merge (mutool) and the extract/convert (Ghostscript), without the latter being a two step process | 18:40.25 |
| Robin_Watts | and if you do: mutool clean -ggg in.pdf out.pdf 3,7,9,13 you'll drop any unused fonts/images etc too. | 18:40.30 |
| | The advantage of mutool over gs is that things like structural content aren't lost. | 18:41.16 |
| mvrhel_laptop | chrisl: I can see that. for now though I am going to keep them separate. my thoughts being that someone has what they want then they convert to X or A type. | 18:47.37 |
| | Robin_Watts: so the question for me now is, do I have mutool included with the whole solution and call the process or bake it in. I am leaning towards baking it into my winRT interface to mupdf since I could add this option int the windows 8 app too. | 18:49.21 |
| Robin_Watts | mvrhel_laptop: either should be possible. | 18:50.34 |
| | mutool is actually a front end for lots of tools. | 18:51.02 |
| | mutool.c has a main function that looks at argv[0] and [1] to figure out how it's been called, and then calls a main_<toolname> function to actually do the work. | 18:51.57 |
| | so pdfclean_main is the function you want to call. | 18:52.34 |
| | and that's implemented in pdfclean.c | 18:52.38 |
| | Oh, and if you add -l then it'll linearise things too. | 18:53.15 |
| mvrhel_laptop | Robin_Watts: ok. I will look this over. I would prefer to be able to call it as a library rather than a process. I will see what I can do | 18:54.16 |
| Robin_Watts | mvrhel_laptop: It's just a tiny tweak to the way it builds. It shouldn't be a problem. | 18:55.15 |
| mvrhel_laptop | ok cool | 18:55.35 |
| Robin_Watts | Do you have libmupdf in your solution in the same way that the normal solution does? | 18:55.42 |
| mvrhel_laptop | Robin_Watts: pretty much. | 18:55.57 |
| Robin_Watts | Then just add pdf-clean.c to that. | 18:56.10 |
| mvrhel_laptop | ok. that is easy enougy | 18:56.18 |
| | enough | 18:56.21 |
| | thanks Robin_Watts . I am going to grab some lunch now then I will give it a try | 18:56.45 |
| Robin_Watts | ok. | 18:56.56 |
| mvrhel_laptop | need to commit this stuff though too... | 18:57.04 |
| chrisl | Robin_Watts: did you see what I said about the gs bug I assigned to you? | 18:57.53 |
| Robin_Watts | chrisl: sorry, almost certainly not. | 18:58.08 |
| chrisl | Okay, give me a sec.... | 18:58.35 |
| | Robin_Watts: I've assigned http://bugs.ghostscript.com/show_bug.cgi?id=695090 to you as it seems like your input would be useful. You might want to punt it to ray_laptop once you've said anything you want to say.... | 18:59.13 |
| Robin_Watts | ok, ta. I will take a look at that tomorrow. | 18:59.48 |
| | I *really* want to fix the stuff I'm working on now. I'm nested about 3 rabbit holes deep :( | 19:00.08 |
| chrisl | Robin_Watts: I know how you feel... it's just that bug seems to be around the planar stuff, and you probably know what as well as anyone | 19:01.09 |
| | g'nite all | 19:18.17 |
| Robin_Watts | Gah. Twice today I've gone hunting for why my revised fz_stream stuff is giving errors on files, only to discover that these particular errors were in the old version too. | 19:41.22 |
| Jogu_ | hello | 19:41.27 |
| Robin_Watts | Morning Jogu_ | 19:41.33 |
| | henrys: Jogu_ = Joseph | 19:41.41 |
| Jogu_ | apparently still vaguely remembers how to use irc :) | 19:42.32 |
| henrys | oh hello Jogu_ | 19:43.29 |
| | Robin_Watts: paulgardiner should be forwarded that mail - have you done it or shall I? | 19:43.59 |
| Jogu_ | apparently I may be working with some of you folks soonish on something :-) | 19:44.06 |
| Robin_Watts | henrys: I have not. | 19:44.31 |
| henrys | Robin_Watts: I've done it. | 19:46.07 |
| Robin_Watts | Jogu_: So, the biggest short term thing facing us is sorting out the printing from SmartOffice. Currently it's using the embedded-general libs (Anprint on android, ticprint on ios). | 19:46.27 |
| | Our current license for those ends at the end of the month. | 19:46.39 |
| | Miles is trying to negotiate an extension, but it's possible we will need to remove them and/or replace them. | 19:47.05 |
| Jogu_ | nods. what's the plan? (is there a plan? :) ) | 19:47.12 |
| Robin_Watts | We should find out which later today. | 19:47.16 |
| | paulgardiner has been looking into the options. | 19:47.28 |
| Jogu_ | afaik airprint on iOS doesn't rely on that btw, if you're lucky enough to have exactly the right model of HP. | 19:48.26 |
| Robin_Watts | Longer term, the desire is for us to address some of the grosser differences in layout/rendering between us and msoffice/libreoffice etc. | 19:48.27 |
| | The exact division of tasks has not been figured out yet. | 19:49.14 |
| Robin_Watts | is being called for dinner though. | 19:49.35 |
| henrys | Jogu_: yes paulgardiner said he had no luck getting it work with his epson. | 19:51.11 |
| Jogu__ | uh. cool. trying to access my airprint printer's webinterface crashed firefox. | 19:56.26 |
| Jogu___ | okay... accessing my airprint printers web interface /reproducibly/ kills firefox. I'll maybe stop trying to do that. | 19:57.41 |
| Jogu_ | airprint seems to work fine for me, in the current appstore build, talking to my cups server. | 20:05.11 |
| | in fact that same release doesn't seem to see my non-airprint printer. odd. | 20:07.12 |
| henrys | Jogu_: I don't think paulgardiner was using a server but trying to connect directly to a printer. | 20:11.19 |
| | but I don't know the details | 20:11.34 |
| Jogu_ | it's the same protocol (my cups server is setup to accept airprint jobs) | 20:12.41 |
| | I'm deeply suspicious about why the current build doesn't see either of my non-airprint printers. Previous builds did. | 20:16.19 |
| henrys | Jogu_: you mean what is current at the app store or some other build? | 20:17.14 |
| Jogu_ | current app store | 20:17.18 |
| | of smartoffice 2. | 20:17.25 |
| henrys | Jogu_: what protocol was used to see them? | 20:18.04 |
| Jogu_ | the embedded general stuff use to see them | 20:18.23 |
| | they're both HPs. | 20:18.41 |
| henrys | Jogu_: oh like eprint | 20:18.48 |
| | ? | 20:18.49 |
| Jogu_ | I think the embedded general stuff was speaking pcl directly to them | 20:19.25 |
| henrys | my app says airprint along the way in the print dialog and I assumed that was all that was supported? Where in the epage tree do I find this stuff? | 20:19.33 |
| Jogu_ | you /should/ see other printers in the print dialog. that's the whole point of the embedded general stuff - it should show most printers on your network there. | 20:20.30 |
| | in the tree... I think it's in the iphone alien | 20:20.44 |
| henrys | no it doesn't and I have 2 printers on the network here - neither airprint | 20:21.06 |
| Jogu_ | you should see a list like http://www.picsel.com/docs/images_pso/print-room.png | 20:21.47 |
| henrys | I wonder if it was disabled to avoid paying the third party and just a native printing solution (airprint) was cobbled together. | 20:22.25 |
| Jogu_ | iirc, it use to have airprint /and/ the embedded general stuff | 20:23.19 |
| | but it does seem very possible they've disabled it. I wouldn't necessarily say they deliberately disabled it though. | 20:24.00 |
| henrys | Jogu_: so there is no source for the embedded-general stuff AFAICT | 20:26.48 |
| Jogu_ | yeah; binary only license as far as I know | 20:29.00 |
| | should be in epage/third-party or thereabouts. | 20:30.00 |
| mvrhel_laptop | Robin_Watts: so it is not quite as simple as adding in pdfclean.c to the library. pdfclean.c uses globals for the doc and ctx. I certainly could use this code just with a different interface | 20:32.24 |
| Robin_Watts | mvrhel_laptop: Oh, right. | 20:32.45 |
| | I can fix that. | 20:33.18 |
| mvrhel_laptop | oh | 20:33.23 |
| | one other request then | 20:33.29 |
| | Robin_Watts: pdfinfo looks like it would be useful to use to. but it is dumping out to stdout . any chance we could make it go out to something that I can set up like is done with gs | 20:34.59 |
| Robin_Watts | mvrhel_laptop: I'm sure we can do something with it, yes. | 20:35.20 |
| | I can probably make it use an fz_output * rather than stdout. | 20:35.43 |
| | Then you can redirect it to file or memory buffer. | 20:35.57 |
| mvrhel_laptop | ok. I should be able to hook into that. | 20:36.03 |
| | I know you have your plate full. just ping me when you think you have something . I will move on to doing the extraction of a small region from within a page using gs | 20:37.36 |
| pete_mcl | hi | 21:15.29 |
| Robin_Watts | Aha. Hi pete_mcl | 21:20.07 |
| | henrys (et al), pete_mcl is the other director of emobix. | 21:20.25 |
| pete_mcl | hi Robin_Watts, henrys | 21:21.05 |
| Jogu_ | Hi Pete | 21:21.52 |
| | I suspect that's enough for me for today; have a good night everyone | 21:21.55 |
| Robin_Watts | night Jogu_ | 21:22.53 |
| henrys | hello pete_mcl | 21:27.40 |
| Robin_Watts | marcosw_: We need to make shell accounts on casper for Joseph and Pete. | 21:32.43 |
| | I'll take a run at it tomorrow unless you fancy doing it. | 21:33.21 |
| marcosw_ | either way. have they sent you public ssh keys? | 21:33.42 |
| Robin_Watts | marcosw_: Not yet. | 21:33.54 |
| pete_mcl | not yet - but can sort that out | 21:34.21 |
| marcosw_ | Robin_Watts: I'm traveling tomorrow so if I get the ssh keys tonight I can make the accounts, otherwise I'll leave it to you. | 21:35.25 |
| henrys | marcosw:they probably need a bugzilla account also to see ghostdocs bugs. | 21:37.51 |
| Robin_Watts | marcosw_: Could you make the accounts, and I could insert the keys tomorrow ? | 21:38.19 |
| henrys | marcosw:I see they're locked I guess that is the right thing to do for now | 21:38.23 |
| | I can make the accounts no big deal for me. | 21:38.45 |
| Robin_Watts | marcosw: I just about trust myself to insert the keys without screwing up :) | 21:39.13 |
| marcosw_ | henrys: yes, the bugzilla accounts need to be set up first and then set to be allowed to access the ghostdocs bugs. | 21:39.31 |
| | Robin_Watts: sure, do we have preferred account names? joseph and pete? | 21:40.00 |
| | and also their complete names | 21:40.50 |
| Robin_Watts | Joseph Heenan | 21:41.14 |
| pete_mcl | marcosw - that sounds cool | 21:41.19 |
| Robin_Watts | Peter McLaughlin | 21:41.32 |
| marcosw_ | Robin_Watts: will do it now. | 21:44.07 |
| | Robin_Watts: okay, accounts created with --disabled-password so login disabled without ssh key. Insert the public key into ~/.ssh/authorized_keys and that should be it. | 21:47.52 |
| Robin_Watts | marcosw: Thanks. | 21:48.04 |
| marcosw_ | henrys: Peter already has a bugzilla account, should I give him ghostdocs bugs access? | 21:49.47 |
| | ^Peter^Joseph | 21:50.20 |
| pete_mcl | thanks marcosw_ | 21:52.05 |
| henrys | marcosw_: yes | 21:52.19 |
| | if you guys want to have a brief look at the bugs: http://bugs.ghostscript.com/buglist.cgi?quicksearch=ghostdocs&list_id=13430 | 21:52.56 |
| marcosw_ | pete_mcl: I couldn't find your bugzilla account; just Joseph's. Do you have one? | 21:53.52 |
| pete_mcl | thanks henrys - will have a look. | 21:54.01 |
| | marcosw_> probably not yet - don't have any details for one yet | 21:54.38 |
| marcosw_ | go ahead and create one so I can add ghostdocs access. | 21:57.17 |
| pete_mcl | ok, I've set up an account (pete@emobix.co.uk) | 22:00.22 |
| marcosw_ | and you should be able to view the bugs. | 22:01.13 |
| pete_mcl | yup, sorted - thanks marcosw | 22:02.31 |
| Robin_Watts | marcosw_: Much more better :) | 23:48.40 |
| marcosw_ | you mean the private attach tag or something else? | 23:49.07 |
| Robin_Watts | the private attach tag. | 23:50.11 |
| | Forward 1 day (to 2014/03/13)>>> | |
IRC Logs
