| <<<Back 1 day (to 2013/05/30) | 2013/05/31 |
robin_watts_mac | henrys: in the short 5 minute demo I got, the BB10 stuff looks like it can do stuff for business deployments that no other OS can, currently. | 01:45.24 |
| But they plan to bring out the critical features for android later this year, so they may be shooting themselves in the foot. | 01:46.02 |
henrys | I assume miles and scott talked to this guy and tried to get a contact? | 01:46.56 |
robin_watts_mac | henrys: oh yes. He's gonna hook us up with the relevant people. | 01:49.34 |
henrys | robin_watts_mac: looking at the enterprise stuff on their web site. | 01:55.23 |
robin_watts_mac | henrys: The "BYOD" stuff. Bring you own device. | 01:55.43 |
| You can change between different partitions of the device. Personal or Work, for example. | 01:56.03 |
| Your work stuff automatically connects to your work network via VPN. | 01:56.24 |
| You can't copy work stuff to personal, but you can copy from personal to work. | 01:56.41 |
| The work and personal apps are all different. | 01:56.55 |
| and the work apps can be adminned remotely by your works IT team. | 01:57.17 |
henrys | robin_watts_mac: yes and they separate your apps and work stuff on the same device. | 01:57.22 |
robin_watts_mac | so if an organisation gives out devices they can leave people with the freedom to customise them for personal use, but still maintain the rigid control they want for work data. | 01:58.15 |
henrys | robin_watts_mac: but I don't see any BB devices that I'd want to work on for any amount of time ;-) | 02:00.38 |
robin_watts_mac | The bb10 looks just like any modern smartphone. | 02:01.32 |
henrys | robin_watts_mac: I don't want to work on those either - that's sort of what I'm curious about here. How important is "work" stuff on mobile platforms - I don't have a single app on my phone that has anything really work related. It seems to be more about getting through the rest of your life. | 02:03.50 |
| I work on a laptop or a workstation. | 02:05.32 |
robin_watts_mac | right, but that's our workflow. | 02:06.13 |
| I have friends who work for the NHS. | 02:06.21 |
| They get blackberries, which enables them to deal with email on the move. | 02:06.44 |
| Patient confidentiality etc means they need secure access to patient data. | 02:07.11 |
| so it's a really good fit. | 02:07.31 |
henrys | robin_watts_mac: yes that makes sense and I can see insurance folks using them. | 02:07.44 |
robin_watts_mac | I am sure there are lots of other similar 'enterprises' where it's a similar good fit. | 02:08.02 |
henrys | robin_watts_mac: I guess your sleep is messed up. How does Helen like Boston? | 02:11.14 |
robin_watts_mac | just heading to bed now. | 02:11.47 |
| Helen has liked boston a lot - she walked miles today. | 02:12.01 |
| We are going to walk the freedom trail on saturday with Scott and Austin (his grandson) | 02:12.28 |
| I ran around some of the docks - seems really nice. | 02:13.03 |
henrys | Sounds like fun, Sabrina says hi to both of you. I'll be around tomorrow, love to hear what's going on at the show. | 02:13.39 |
| robin_watts_mac: going to watch some supernatural good night. | 02:16.34 |
robin_watts_mac | night | 02:27.40 |
| say hi to sabrina | 02:27.46 |
| tkamppeter: Hey. | 12:05.55 |
| I have mono PCL output working from mupdf. | 12:06.19 |
| Same range of options (media selection/duplex/range of printers) as from gs. | 12:06.45 |
| It's not in mainline mupdf yet, but you can find it in user/robin/mupdf.git on git.ghostscript.com | 12:07.41 |
| I will try and look at color pcl on the return flight. | 12:07.54 |
| If I was to pick a color pcl driver (or drivers) from gs to use to base the mupdf ones on, any suggestions which one? | 12:22.31 |
chrisl | Er, how many are there? | 12:24.01 |
robin_watts_mac | chrisl: gdevcdj.c seems to have one (several devices, but one core routine, I think) | 13:18.36 |
| are there others ? | 13:18.40 |
| I am completely ignorant about this, hence me asking before I waste too much time. | 13:19.05 |
chrisl | That's s deskjet driver which is (based on, I think) PCL3 - I assumed you wanted PCL5 | 13:20.29 |
| robin_watts_mac: ^^ | 13:20.36 |
robin_watts_mac | so which is the pcl5 one? | 13:28.57 |
chrisl | I was just looking, and I'm really not sure :-( | 13:30.12 |
henrys | robin_watts_mac: ps2write ;-) | 13:30.26 |
chrisl | robin_watts_mac: gdevclj.c and gdevcljc.c are color laserjet, so probably worth a look | 13:32.23 |
henrys | seriously gdevclj.c but as I've said it doesn't work on my printer | 13:32.36 |
chrisl | henrys: what about cljet5c (gdevcljc.c)? It looks much dumber | 13:33.45 |
henrys | chrisl: yea that's what I meant. | 13:34.20 |
| my guess is though if you have a color laser printer and linux it better be a postscript printer - but that is just my experience. | 13:35.52 |
chrisl | henrys: Or use the HP PCL driver | 13:36.20 |
henrys | right the XL driver works for me. | 13:37.18 |
| I imagine that is what the HP driver produces, I should check. | 13:37.49 |
chrisl | Not sure - I only had it installed briefly to test something out | 13:38.20 |
henrys | but doing high level xl is as much work as producing postscript | 13:38.21 |
robin_watts_mac | yeah, I don't want to do high level stuff (yet, if at all) | 13:38.47 |
henrys | robin_watts_mac: I do think cljet5c will work on printers with memory upgrades. | 13:39.27 |
tkamppeter | robin_watts_mac, great. Probably we will use Poppler in Ubuntu Touch (see https://wiki.ubuntu.com/Touch/PDFRenderer) but we should try to make MuPDF a possible print renderer, too. | 13:39.41 |
robin_watts_mac | tkamppeter: As counters to the "Advantages poppler" section of that page... | 13:41.53 |
| MuPDF has been around for a long time too, and it's developed by the same people that did gs - hence it has a background that goes back further than poppler. Certainly I wouldn't expect us to have any problems displaying files that poppler can. | 13:42.58 |
| The upstream maintainers of mupdf are similarly friendly with ubuntu - we've been working for years with you on gs, which has (and is) still part of your printing toolchain. | 13:43.42 |
henrys | tkamppeter: where is reflow in the comparison? | 13:43.54 |
robin_watts_mac | Better accessibility: really? We do text extraction too. What else do you need for screen reading? | 13:44.17 |
tkamppeter | robin_watts_mac, by the way, the PCL-5 support in GS (ljet4/ljet4d) has a problem. One cannot switch one-sided/duplex-long-edge/duplex-short-edge via the standard -dDuplex and -dTumble options, duplex can only be switched by slecting ljet4 or ljet4d, short-edge is not available at all (see https://bugs.launchpad.net/bugs/1184665). | 13:44.38 |
henrys | tkamppeter: can you report a bug? | 13:45.31 |
robin_watts_mac | tkamppeter: In mupdf you pass a pointer to a fz_pcl_options structure to the pcl output. | 13:45.32 |
| and in there you can set tumble/duplex/media position as you want | 13:45.52 |
| it's not currently exposed as command line flags - we need to write a trivial pdftopcl exe that takes whatever command line flags you'd like and calls the pcl code. | 13:46.52 |
| Does poppler do color management? | 13:47.39 |
| or XPS ? | 13:47.50 |
henrys | robin_watts_mac: maybe best to work on the svg writer. | 13:52.17 |
robin_watts_mac | henrys: I've only got a small bit left to do on that before I run up against font issues. | 13:53.28 |
| at which point I'll have to go begging for help from other people. | 13:54.02 |
tkamppeter | robin_watts_mac, http://bugs.ghostscript.com/show_bug.cgi?id=694279 | 13:58.07 |
| robin_watts_mac, Poppler does some basic CM stuff AFAIK, but GS is much better in CM. Has MuPDF incorporated all CM of GS? | 14:00.30 |
henrys | tkamppeter:test file and command line for that bug? | 14:01.15 |
robin_watts_mac | tkamppeter: Not yet, but mvrhel is scheduled to look at that. | 14:01.52 |
| The plan is that mupdf will sprout the same support as gs has. | 14:02.07 |
tkamppeter | henrys, seems to occur with any file of more than one page and with any GS command line. To test, one would need to take a simple 2-page PS file, run it through GS with all combinations of -sDEVICE=ljet4/-sDEVICE=ljet4d, -dDuplex, -dTumble and one will see that ljet4 gives always one-sided and ljet4d always two-sided-long-edge, independent which combination of -dDuplex and -dTumble gets used. | 14:06.09 |
henrys | I believe d is for duplex isn't it? | 14:07.28 |
tkamppeter | henrys, to check, one needs to either pass the result into ghostpcl or to a printer, or one looks for PCL codes for duplex and tumble in the binary output data. | 14:07.38 |
| henrys, yes, ljet4 is for non-duplex and ljet4d is for duplex. | 14:08.10 |
robin_watts_mac | tkamppeter: Right, so using ljet4, any duplex switches should be ignored completely. | 14:08.34 |
henrys | is confused | 14:08.47 |
tkamppeter | robin_watts_mac, yes, and in ljet4d duplex should be controlled by the switches. | 14:09.14 |
robin_watts_mac | And currently ljet4d *always* duplexes, regardless of the switches ? | 14:10.02 |
chrisl | Sounds like the intended behaviour, to me | 14:10.30 |
henrys | I imagine it would, otherwise we wouldn't need 2 devices. | 14:10.31 |
| I don't remember why we need a duplex device though. | 14:11.14 |
robin_watts_mac | henrys: The way I thought it was set up (from reading the device code, but not the documentation) was that ljet4 = "laser jet 4 with no duplexer" | 14:11.18 |
| ljet4d = "laser jet 4, with a duplexing unit available" | 14:11.34 |
| hence for ljet4, as there is no duplex unit, no duplex commands are ever sent to the stream. | 14:12.03 |
| and for ljet4d, as there is a duplex unit, the duplex commands are sent to the stream *if* duplexing is enabled, but not otherwise. | 14:12.38 |
henrys | yeah I just can't think of "PCL" reason why that should be necessary. you should be able to insert duplex commands in the stream when you get the options - if the unit is there is works. | 14:13.01 |
robin_watts_mac | and tkamppeter is saying, I believe that ljet4d actually *always* enables duplexing, and the tumble commands are lost. | 14:13.13 |
henrys | and have one device. | 14:13.13 |
robin_watts_mac | right - devices that don't understand them should be able to skip the unknown commands? | 14:13.46 |
| The code is predicated on "duplex_set" and "duplex". I'm not sure how those flags get set. It's possible that at some point the past that the code to set them from the -dDuplex options has bitrotted and they are always being registered as being set or something. | 14:15.45 |
henrys | tkamppeter: oh the printer support pcl 6 - so he should be using pxlmono anyway. | 14:20.37 |
| wow 149.00 for a duplexing laser. | 14:21.44 |
| tkamppeter:we'd much rather folks use that device - higher level output and hin-tak fixes the bugs ;-) | 14:26.07 |
| but we will look at the ljet4d problem also. | 14:26.36 |
robin_watts_mac | henrys: yeah. mono lasers are stupidly cheap now - but how much is the toner? | 14:29.44 |
robin_watts_mac | heads down to stand. bbiab. | 14:29.56 |
tkamppeter | robin_watts_mac, at Ubuntu we are accepting having no CM on mobile but it would be great that it gets in in the future. The only real advantage of Poppler is that it is already used by the standard desktop and as we want to have Ubuntu Touch devices run the standard desktop when an external monitor is connected (so-called convergence) we are avoiding to add an extra PDF renderer. | 14:39.09 |
henrys | tkamppeter: he left | 14:39.53 |
tkamppeter | henrys, there are enough PCL-5-only printers (and also printers with PCL-XL problems) so the ljet4d problem ned to get taken care of. Another use case for it is if a printer reports understanding PCL (no version specified) via Bonjour or IPP, then we have to use PCL-5c/e to be sure that it works. | 14:41.46 |
henrys | tkamppeter: I said we'd look at it, glancing at the code it appears the tumble pcl codes are being emitted, so I doubt we are going to find anything but... | 14:43.20 |
tkamppeter | henrys, I have told the user that he should use PCL-XL. The bug stays open for the ljet4d fix. | 14:46.41 |
henrys | tkamppeter: thanks | 14:48.54 |
tor8 | sigh. gtk+ race event conditions suck... | 14:49.34 |
| oh fab. gtk+ ran out of memory and caused a kernel panic... | 14:54.28 |
| I think that's the cue to quit for the day. | 14:54.35 |
chrisl | tor8: sounds like a good plan! | 14:55.56 |
kens | goodnight all | 16:07.54 |
ray_laptop | it appears that we've had a new ghostscript customer for a bit. I just welcomed them and forwarded the email from Miles about them. | 16:41.58 |
| no customer number yet, however. | 16:42.08 |
| marcosw (for the logs) I gave them the commercial download instructions. | 16:42.32 |
tkamppeter | ray_laptop, what caused bug 694280? In 9.07 the CUPS output device seems to work well as I do not get any related bug reports in Ubuntu. | 16:59.18 |
ray_laptop | tkamppeter: it was only when BGPrint=true option was used to perform rasterization and output in a separate thread in parallel with the parsing of the next page. | 17:00.28 |
| tkamppeter: this is false by default, so the problem only showed up in the weekly (Friday) regression testing for " Multithreaded and backgorund rendering" | 17:01.21 |
tkamppeter | ray_laptop, OK. | 17:01.48 |
ray_laptop | tkamppeter: without BGPrint=true, everything was fine. | 17:01.49 |
| I tried to enable background printing on as many devices as seemed OK but desk checking for 'side effects' isn't perfect. We probably need to turn on BGPrint=true on the 'all devices' test run | 17:04.15 |
| Well, at least on Windoze, the cups output difference is 4 extra bytes at the start (when BGPrint=true). I delete those and everything else is identical. So what's the big deal about 4 bytes ;-) | 17:31.18 |
| tkamppeter: I've taken that bug from you. Hope you don't mind ;-) | 17:35.04 |
tkamppeter | ray_laptop, no problem, I think you know better about how to fix it. | 17:54.53 |
ray_laptop | YUCK. The cups device may never support background printing. It is definitely some of the ugliest code I've seen. It uses a static _cups_raster_error_t struct, mallocs strings for it, and then never frees them (#if HAVE_PTHREAD_H is 0) | 18:15.07 |
| so far, I've determined that the 'stream' allocation is the reason for 4 extra bytes (it writes CUPS_RASTER_SYNC at the start of the output). Note that if the file changes, as with out-%d.cups the files after the first don't have this SYNC sequence. Definitely a shortcoming | 18:19.43 |
| the writing using the stream uses the fd number, but the file attached to this fileno may no longer be the same file :-( | 18:22.31 |
| Punting for now. This will take some thought on how to refactor things. Comments above (and more) added to the bug | 18:35.45 |
| have to run an errand (pick up birthday presents for my twins). bbiaw | 18:36.11 |
mvrhel_laptop | finally back. what a trip between the border crossing and the interstate bridge being out | 21:51.31 |
| Forward 1 day (to 2013/06/01)>>> | |