| | <<<Back 1 day (to 2015/02/18) | 20150219 |
| rayjj | gahhh!! (or however you say that). The pattern-clist playback with transparency is SO HONKED UP. When reading, it's calling the pdf14_clist write routines for the compositor actions :-/ | 00:04.13 |
| | _and_ it's not picking up the ICC profile (at least on the fts 23_2303.pdf) when reading back because the BEGIN_TRANS_MASK just gets the hashcode and never loads the profile before calling pdf14_update_device_color_procs_push_c | 00:06.04 |
| | so it returns an error that aborts the playback | 00:06.38 |
| | and this is on top of what I've already fixed :-( | 00:07.14 |
| | we never tripped over any of this because we don't test with a small (e.g.10k) MaxPatternBitmap | 00:08.51 |
| henrys | Â fredross-perry : I see qt-gsview updated 3 hours ago but that can't be the ios stuff? | 01:22.48 |
| fredross-perry | no. Thereâs a separate repo called mupdf that has the iOS stuff. | 01:23.17 |
| henrys | link? | 01:24.35 |
| | fredross-perry: nevermind I see it. | 01:25.24 |
| | fredross-perry: but that's the main repository I thought you were to do stuff in the personal repo, get review then put it into main. | 01:26.47 |
| fredross-perry | right. I made a branch. Maybe I did this wrong. | 01:27.11 |
| henrys | fredross-perry: I thnk you want to just put your changes on user/fred/mupdf.git - no branch get revew then push to golden (mupdf.git) | 01:28.53 |
| fredross-perry | OK Iâll ry that again. | 01:29.33 |
| henrys | fredross-perry: you can have a branch if you want but this system sort of takes away the usefulness of a branch | 01:30.14 |
| fredross-perry | ok | 01:31.10 |
| henrys | fredross-perry: it was quite a bit of time before everyone got used to git | 01:31.11 |
| | fredross-perry: so don't worry if it seems difficult - it should ;-) | 01:31.30 |
| fredross-perry | stay tuned... | 01:34.58 |
| henrys | fredross-perry: your git config should have an alias like [remote "personal_mupdf"] then a url for the user/fred/mupdf.git. then do git push personal to put stuff up there. We rarely use branches (less than i'd like) | 01:37.37 |
| fredross-perry | OK Ill sort this out tonight. Thanks for the info | 01:39.45 |
| henrys | tkamppeter: are you about? | 01:40.31 |
| tkamppeter | henrys, hi | 01:41.33 |
| henrys | tkamppeter: is there a way to set up mock printers in cups for the purpose of just capturing driver output? We don't have the printers. I remember doing something like this years ago but it doesn't seem obvious in the current cups web gui. | 01:43.38 |
| tkamppeter | henrys, you can print into a file, see "Getting the data which would go to the printer" on https://wiki.ubuntu.com/DebuggingPrintingProblems. | 01:47.24 |
| henrys | tkamppeter: okay I was trying to change the driver used for an ipp printer and capture the tcp stream. But cups doesn't like that. It seems to just switch back to the old (correct) driver. | 01:51.13 |
| | tkamppeter: the problem with print to file is I won't see what the printer actually does. | 01:52.47 |
| tkamppeter | henrys, you can also emulate an IPP (Everywhere) printer. On one machine in the local network stop CUPS and run ippserver (in the test directory of the CUPS source code). This coputer emulates an IPP network printer then. On another achine run CUPS, set up queues pointing to your emulated IPP printer and print. | 02:06.59 |
| henrys | tkamppeter: I might try that. It is curious to me that I can't just change the driver of my dnssd printer I have setup. There is a prompt to change the "model", I thought that would install a new driver but apparently it does not. | 02:14.23 |
| fredross-perry | OK, try again. I merged recent stuff into my repo and added the iOS changes. See if that looks ok. | 02:48.49 |
| henrys | fredross-perry: it's in the right place now the mupdf folks will have a a look when they get in. | 02:57.48 |
| | fredross-perry: I'll tell them to look at it in the morning if you aren't here. | 02:58.23 |
| fredross-perry | all right thanks | 03:09.03 |
| chrisl | kens: I have to go out at about 9:30 for a couple of hours or so - it's up to you if you want to talk over the problem before then, or after..... | 08:22.10 |
| kens | After would be better, I thought of a couple of thinkgs I want to try first. | 08:22.29 |
| | Also I need to refresh my memory and clear up confusion..... | 08:22.47 |
| chrisl | Okay, that's fine - I might actually be awake by then! | 08:23.04 |
| kens | More coffee now :-) | 08:23.14 |
| chrisl | I think so - although, even coffee might struggle to get me started this morning | 08:23.58 |
| | kens: my new work PC from quietpc was delivered yesterday. The case is very slightly taller than an old skool ATX mini-tower case, not as tall as a midi-tower...... but it was packed into the *largest* cardboard box I've seen in ages - so big, it wouldn't fit through my loft hatch! | 08:37.44 |
| kens | I guess its their standard box...... | 08:38.10 |
| chrisl | Possibly, but when it was delivered, I wondered what the hell I'd ordered - I kept looking round it for a "Cray" logo..... | 08:38.52 |
| kens | :-) One of the old ones with teh bech seating would be cool | 08:39.15 |
| | bench* | 08:39.21 |
| | I don't think they were very quiet though | 08:39.40 |
| chrisl | Yeh, a lecturer I (briefly) had at uni wanted to get hold of one those - to go with the PDP-11 (I think) and IBM mainframe he ran in his garage!! | 08:40.21 |
| kens | :-O | 08:40.40 |
| chrisl | He'd had to get 3-phase power run in to power them! | 08:41.09 |
| kens | Yeah I'm pretty sure the IBM would need that, PDP-11 might not, I don't remember that well. | 08:41.29 |
| | Still mad though.... | 08:41.44 |
| chrisl | He made quite a lot of money doing consultancy - mainframe software doesn't exactly change quickly, so it paid to keep an old one to work on locally | 08:42.42 |
| | The PDP was just for "fun" | 08:43.04 |
| jmux | Hi. Does mupdf have XFA support? | 10:32.54 |
| tor8 | no. | 10:33.23 |
| kens | If you mean 'canit process the XML from an XFA file' then teh answer is no at present | 10:33.26 |
| | It cna however happily handle the PDF portion of an XFA form | 10:33.42 |
| jmux | kens: Ok - should have checked the bug tracker: 693446 | 10:34.04 |
| kens | :-) | 10:34.28 |
| jmux | Well - I have a 20k Linux desktop base and since Adobe Reader on Linux is going EOL I'm facing the problem, that people won't be able to to file SAP forms, which a lot of people have to do... | 10:38.36 |
| | I've seen that XFA specs, v3.3 has 1584 pages - hmm. | 10:39.04 |
| kens | The problem is that XFA isn't really PDF, its XML. You need a full layout engine which PDF consumers don't need. SO you need a whole load of stuff added to any normal PDF consumer. Its hard to do well and its a lot of work to do at all. | 10:39.52 |
| jmux | Anyone here who can roughly estimate (in mandays or something) how much effort it would take to get - probably basic - support implemented? | 10:40.11 |
| kens | Hmm. Tor8 probably has an idea. | 10:40.30 |
| tor8 | kens: very non-trivial | 10:40.45 |
| | even basic forms support in mupdf is very limited in capability | 10:40.56 |
| kens | My initial guess wold be 3-6 man months, but I know nothing really | 10:41.05 |
| tor8 | at least | 10:41.12 |
| | possibly more, depending on how robust you need it | 10:41.22 |
| | longer if you need the http forms submitting and solid javascript bindings. the framework is there from what paul wrote but the linux viewer doesn't hook into it at all. | 10:42.12 |
| jmux | So it's really a huge afford based on the current codebase | 10:42.18 |
| kens | THat's why nobody in the PDF world really does it. | 10:42.33 |
| tor8 | jmux: I'm afraid so. form support is something we're working on, but unfortunately it's rather low priority | 10:42.46 |
| jmux | Would uit be possible to implement it as a seperate library, so it could be used by other projects, like poppler, too? | 10:43.04 |
| tor8 | and XFA is just someone who drank the XML kool-aid ten years too late... | 10:43.16 |
| | parsing the XML is trivial (we already have XML processing in mupdf for dealing with XPS) | 10:43.40 |
| | it's hooking it up to the viewer and back-end PDF objects that's a lot of work | 10:44.10 |
| | and none of that work is going to be applicable to poppler | 10:44.35 |
| kens | And the layout | 10:44.42 |
| | Which, of course, will have to match Adobe, or it'll be 'wrong' | 10:45.01 |
| jmux | Hmm - ok. Thanks for the info and guesstimates. | 10:48.34 |
| | Guess it'll get really expensive, if people decide to sponsor it full time - well, that's not me to decide | 10:50.21 |
| chrisl | kens: do you still need to talk over the memory problem? | 13:30.44 |
| kens | Yes please. | 13:30.52 |
| | Not getting very far at the moment | 13:31.00 |
| chrisl | Okay, whenever you like | 13:31.13 |
| kens | private tab | 13:31.22 |
| henrys | tor8: fred had changes in his personal repo I imagine paulgardiner would be best for doing the review but you should look too, Fred's new I think a couple of folks reviewing is a good idea. | 14:00.33 |
| | Robin_Watts: fyi ^^^ | 14:01.00 |
| paulgardiner | Oh right. I'll take a look | 14:01.28 |
| tor8 | henrys: right. patch looks reasonable at a first glance, but I'll let paul take a look as well | 14:03.26 |
| paulgardiner | Is this supplying ctx everywhere to aid multithreaded code? | 14:04.40 |
| | I missed the discussion. | 14:04.50 |
| | Yeah, all looks reasonable to me. | 14:06.19 |
| tor8 | paulgardiner: yeah, and because a regular api is better than having to look it up every time you use a function | 14:07.05 |
| | and the fragility of 'rebind' when you forget it, will mess up multi-threading | 14:07.21 |
| paulgardiner | Very true | 14:07.22 |
| | Yeah dropping rebind is good, although it was a good short-term fix | 14:08.01 |
| tor8 | yeah. | 14:08.12 |
| | dropping the embedded contexts is nice | 14:08.18 |
| | passing ctx everywhere is a lot of extra typing, but regularity beats obscurity | 14:08.31 |
| | and I don't think it'll matter performance wise | 14:08.39 |
| henrys | tor8: speaking of the mupdf api - jogux pointed me at a pretty good competitor pspdfkit perhaps somebody should look at their api for useful ideas | 14:08.43 |
| tor8 | henrys: iOS specific objective C framework right? | 14:09.15 |
| jogux | yeah | 14:09.36 |
| | but they're releasing Android too soon | 14:09.41 |
| | (presumably as a nice java API) | 14:09.49 |
| henrys | tor8: I figure as soon as the foxit rip makes it to android they'll have a product. | 14:10.03 |
| | tor8: their docs say you can use mupdf ;-) | 14:10.39 |
| jogux | foxit will be in the OS though probably? | 14:10.42 |
| | I guess they could probably port it back to an in-app library if they wanted though | 14:11.08 |
| henrys | jogux: yes | 14:11.10 |
| tor8 | henrys: so they do! | 14:11.52 |
| | pluggable architecture | 14:11.56 |
| | so I guess they have separate pdf object parsing code for all the annotations and outlines and stuff? | 14:12.24 |
| henrys | jogux: that was google's original goal, find a pdf rip for android we lost to foxit | 14:12.46 |
| jogux | tor8: I'm guessing so. I can't say I know that much about it. | 14:14.22 |
| rayjj | I briefly looked at pspdfkit (why "ps" I have no idea). muPDF gets mentioned in one of their FAQ's "PSPDFKit uses Apple's PDF renderer to render PDFs. This is a pluggable architecture and it's also possible to use different render driver classes (e.g. use PDFTron, muPDF or another 3rd-party renderer.)" | 16:13.03 |
| Robin_Watts | paul smith. | 16:13.17 |
| | or peter samson. | 16:13.22 |
| | or something like that. | 16:13.25 |
| rayjj | so I wonder what pspdfkit uses for rendering on Android (by default, do they use mupdf)? | 16:14.20 |
| marcosw | Robin_Watts: "initials of the founder" | 16:14.34 |
| rayjj | marcosw: Oh, Peter Steinberger ? | 16:15.32 |
| | (he's the one that wrote the FAQ that I excerpted from above) | 16:16.08 |
| Robin_Watts | rayjj: yeah. | 16:16.14 |
| | the android version isn't out yet. | 16:16.29 |
| | but who knows... | 16:16.34 |
| henrys | rayjj: lots of stuff in the logs about that. | 16:20.03 |
| | marcosw: do you have any multi-tray printers jogux has a test he needs to do. I've tested it on all my printers here but I don't have the needed extra trays we want to test? | 16:23.31 |
| jogux | rayjj: what they use on android is the big question :-) | 16:24.33 |
| | idle thought: wonder if it's worth paying the company that did this study to tell us if they found mupdf when scanning appstore apps :-) http://techcrunch.com/2011/03/08/potential-open-source-license-violations-in-android-and-ios-apps/ | 16:28.23 |
| henrys | rather irrelevant I want to compete with these guys on the interactive stuff, we've done a lot of it .. signatures, forms, annots, that's one market niche we've been trying to reach. | 16:29.46 |
| | I do like their company list ;-) | 16:31.51 |
| marcosw | henrys: both my HP LaserJet P3005 and Color LaserJet 4500 have multiple trays (the multifeed tray, the standard tray, and the high-capacity tray). | 16:34.45 |
| henrys | perfect. I'll forward jogux instructions and you can give it a test, if you can marcosw | 16:37.27 |
| cinap_lenrek | i have a hard time debugging some postscript code | 16:37.45 |
| | is there a way to get usefull execution stack traces? | 16:37.55 |
| kens | pstack | 16:38.02 |
| henrys | I have a hard time debugging all postscript code ;-) | 16:38.04 |
| cinap_lenrek | like, not having everything like --nostrval-- | 16:38.06 |
| kens | That's because its not a string so it can't be printed as a string | 16:38.23 |
| cinap_lenrek | kens: ok | 16:38.24 |
| kens | pstack prints the operand stack, not the exec stack | 16:38.34 |
| cinap_lenrek | i want the exec stack | 16:38.47 |
| kens | You will rarely find anything of any use whatever on the exec stack | 16:38.47 |
| cinap_lenrek | i have inflate() return with some error | 16:39.06 |
| | in some pdf document | 16:39.11 |
| | from readstring | 16:39.19 |
| | but i cannot find the invocation in the postscript code that handles the pdf | 16:39.32 |
| kens | You will have to debug our PDF interpreter, you won't find that at all easy | 16:39.45 |
| marcosw | henrys: of course | 16:40.11 |
| cinap_lenrek | i already managed to work arround one problem :) | 16:40.14 |
| | its just that theres probably better ways todo it | 16:40.23 |
| kens | Maybe. | 16:40.28 |
| cinap_lenrek | this is some horribly old version of aladdin ghostscript | 16:40.39 |
| kens | Use -dPDFSTOPONERROR and -dPDFDEBUG to locate the problem | 16:40.43 |
| cinap_lenrek | yes | 16:40.48 |
| kens | and use a recent version of Ghostscript | 16:40.51 |
| cinap_lenrek | i can't | 16:40.57 |
| kens | I don't think there's much I can add then | 16:41.12 |
| cinap_lenrek | i did this once | 16:41.23 |
| | i remember theres some ps function that does the stack tracing | 16:41.32 |
| | or wait | 16:41.43 |
| | this is also plan9 | 16:42.26 |
| | theres no c++ compiler | 16:42.30 |
| | we cannot use newer ghostscript because of that | 16:42.39 |
| rayjj | cinap_lenrek: if you are a glutton for punishment, and have lots of disk space to collect logs, then a debug build with -ZI will trace the interpreter including stack depth info | 16:42.44 |
| kens | Ghostscript doesn't use C++ | 16:42.45 |
| | It compiles in C89 IIRC | 16:42.53 |
| Robin_Watts | gs compiles on ANYTHING, pretty much. | 16:43.04 |
| rayjj | cinap_lenrek: you can also insert "(I) true .setdebug" in PS (such as the PDF interpreter) at selected places. "(I) false .setdebug" will turn it off | 16:44.09 |
| cinap_lenrek | rayjj: thank you, i'll try that | 16:44.36 |
| henrys | always thought we could something more sane that -I debugging for PS. | 16:45.28 |
| | s/that/than | 16:45.36 |
| kens | PostScript is hard to debug, but not *that* hard | 16:46.01 |
| henrys | it's just such a hassle to read | 16:46.10 |
| kens | Eh ? Its way easier than PCL | 16:46.17 |
| | Or even PDF until you decompress it | 16:46.33 |
| henrys | kens: I just find it too terse, we could make it more verbose and readable and it might actually get more use. | 16:47.37 |
| | maybe not | 16:47.46 |
| kens | PostScript isn't terse. PostScript *programs* are terse | 16:47.59 |
| rayjj | henrys: it's not compiled in by default (even on a debug build), but the -Z! is somewhat more sane | 16:48.03 |
| henrys | rayjj: right just the operators | 16:48.17 |
| | kens: I'm talking about the format of the -I output | 16:48.41 |
| kens | I never use -I | 16:48.48 |
| henrys | see there you go, if it were good kens might use it ;-) | 16:49.12 |
| kens | Nope, not likely | 16:49.17 |
| | I prefer to debug the real code | 16:49.24 |
| rayjj | I sometimes do, but usually by inserting "on" "off" in the PS code | 16:49.31 |
| chrisl | Even just initialisation, you get information overload using it on the command line | 16:50.01 |
| rayjj | kens: but, yeah, sprinkling pstack and occassional === on dicts is usually enough. | 16:50.22 |
| kens | That and explcit (I'm here) == flush is what I suually use | 16:50.48 |
| rayjj | cinap_lenrek: BTW, also turning on -dPDFDEBUG will help find what part of the PDF is being interpreted when things go wrong | 16:51.02 |
| kens | and for the PDF interpreter PDFSTOPONERROR nad PDFDEBUG to locate the problem | 16:51.07 |
| | WhenI know what functionj to look at in the PDF itnerpreter its usually fairly straight forward (as much as it ever is with our interpreter) to figure out what's going on. | 16:52.00 |
| rayjj | cinap_lenrek: as kens said, -dPDFSTOPONERROR is also handy (for newer gs) old gs did that by default | 16:52.00 |
| kens | still thinks it would be better to invest time in getting Ghostscript to build on the OS than trying to fix an ancient version | 16:52.34 |
| rayjj | agreed | 16:52.59 |
| henrys | cinap_lenrek: ^^^ what kens said is really spot on. | 16:53.16 |
| chrisl | Ghostscript previously had an erroneous dependency on having a C++ compiler on Unix-like systems because Jasper's configure script was wrong - we fixed it a few versions ago | 16:53.56 |
| kens | And we don't use JasPer any more anyway..... | 16:54.14 |
| | OK I have to go and grovel for forgetting to bring the washing in. Goodnight all. | 17:00.00 |
| henrys | rayjj: -ZI is too much and Z! too little. | 17:02.30 |
| cinap_lenrek | ah | 17:33.54 |
| | this appears to be a encrypted object stream | 17:34.00 |
| Robin_Watts | cinap_lenrek: Just to add my voice to the others here... you are mad to go down this route. | 17:36.55 |
| | Getting the latest version of gs built on your OS will be a much easier job than trying to hack the old code about. | 17:37.25 |
| | And if you *do* hit problems, we can help you. | 17:37.36 |
| rayjj | old gs didn't handle decrypting the same way as newer gs. It may be that you'll never get it to work | 17:37.55 |
| Robin_Watts | Whereas, we aren't going to help you when you inevitably hit problems trawling through the old pdf interpreter. | 17:38.08 |
| | There were real breakages and limitations in the old version that you'll never solve. | 17:38.48 |
| cinap_lenrek | i am crazy. | 17:39.02 |
| | and playing with the ghostscript seems more interesting than wading thru billions of lines of configure shellscripts | 17:40.02 |
| | yes | 17:40.11 |
| | maybe at some point going to port newer version over | 17:40.23 |
| | i did fix other this in this version as well that i'd need to backport | 17:41.00 |
| chrisl | cinap_lenrek: have you even tried to build a recent version? Surely it's worth 10 minutes to try it | 17:41.12 |
| cinap_lenrek | our compiler doesnt support packet structs very well | 17:41.28 |
| | packed* | 17:41.32 |
| | there where aliasing and alignment issues on arm | 17:41.42 |
| | and amd64 | 17:41.46 |
| Robin_Watts | cinap_lenrek: gs will compile on anything. | 17:41.53 |
| rayjj | cinap_lenrek: plan9 has gcc, so that _should_ compile gs | 17:42.44 |
| cinap_lenrek | gcc is bigger than the whole plan9 userspace | 17:43.00 |
| rayjj | cinap_lenrek: what compiler were you trying to use | 17:43.07 |
| cinap_lenrek | the plan9 compilers :) | 17:43.17 |
| henrys | cinap_lenrek: if it doesn't we'd help you fix it. We want it to be portable. | 17:43.30 |
| rayjj | cinap_lenrek: (1) install GCC, (2) build modern gs | 17:43.42 |
| cinap_lenrek | i'm not making my system into linux | 17:43.54 |
| | really, relax guys | 17:44.03 |
| | i agree that porting newer version would be longterm solution | 17:44.40 |
| rayjj | cinap_lenrek: OK. Well, good luck | 17:44.57 |
| cinap_lenrek | this is version 8.53 | 17:45.30 |
| | with some ducttape | 17:45.39 |
| rayjj | cinap_lenrek: well, at least it isn't totally ancient (7xx or before) | 17:46.09 |
| cinap_lenrek | yeah | 17:46.16 |
| | it works ok | 17:46.24 |
| Robin_Watts | 8.71 was 6 years ago. | 17:46.28 |
| cinap_lenrek | until it doesnt | 17:46.32 |
| Robin_Watts | And we've had a full time development team working on improving it/fixing bugs ever since. | 17:46.47 |
| rayjj | 8.53 was Aug 2008 | 17:47.00 |
| cinap_lenrek | no doubt | 17:47.00 |
| rayjj | oops. That was a typo in the logs. 8.63 was 2008. 8.53 was Nov 2005 AFAICT | 17:48.36 |
| | of course, cinap_lenrek knows that since starting prints out the date on the GPL ... line | 17:49.32 |
| cinap_lenrek | horay | 22:23.23 |
| | got that stream decrypted | 22:23.28 |
| | aaand it works :) | 22:28.05 |
| FreezingCold | I have three PNG files that I need to combine into a PDF; what's the best way of combining them into a grayscale PDF? | 22:49.11 |
| | imagemagick's convert doesn't seem to have an option for that | 22:49.34 |
| | -colorspace gray | 22:51.08 |
| | Never mind, it does. | 22:51.11 |
| cinap_lenrek | yey, all these pdf-1.6 files work now | 23:27.53 |
| | exch oget /CFM oget /AESV2 eq { | 23:42.06 |
| | (sAlT) concatstrings | 23:42.07 |
| | } if | 23:42.07 |
| | thats in the computation for the stream encryption key | 23:42.18 |
| | that did the trick | 23:42.22 |
| | i couldnt find this in the documentation | 23:42.32 |
| | theres no mention of this sAlT string in PDFReference16-v6.pdf | 23:43.19 |
| | Forward 1 day (to 2015/02/20)>>> | |
IRC Logs