| | <<<Back 1 day (to 2015/02/11) | 20150212 |
| Digit_ | Hi, i am using muPDF under android and experience a strange behaviour. | 13:47.03 |
| | maybe someone can explain? | 13:47.10 |
| kens | Not unless you are more specific. | 13:47.40 |
| Digit_ | the memory consumption of a small pdf is really low on a low end device (around 16mb) but the same pdf on a samsung tab 10.1 its 120mb | 13:47.50 |
| | so the app crashes very fast with a sig11 error | 13:48.06 |
| kens | I would guess its a higher resolution display, so the bitmap required is larger | 13:48.17 |
| | Possibly also a lrger physical screen size too | 13:48.29 |
| Digit_ | Yes it is but the heap increaes by 100mb for a pdf only has text? | 13:48.42 |
| kens | But it should not crash I would have thought (I am not a MuPDF developer) | 13:48.44 |
| | Well, the size of the bitmap is irrelevant to the content | 13:49.08 |
| Digit_ | it even grows more when i scroll. with largeheap = "true" the heap grows to 240mb then it crashes also | 13:50.07 |
| | i wonder how i can use muPDF on a samsung then | 13:50.22 |
| kens | I'm not really in a position to comment as I don;t work on MuPDF | 13:50.27 |
| Digit_ | No problem, maybe someone of the devs read it and can help :) | 13:50.52 |
| | I explain better: A 200kb pdf on a low end device lets the heap grow to 16MB which is ok, but on the samsung it grows to 120MB | 13:55.29 |
| kens | chrisl that optimisation in pdf_fonts.ps was actually OK, I've fixed the stack manipulation which was causing the problem under an error condition. Reading the CFF spec I'm still of the opinion that the font is invalid, but we may need to look at it again one day. | 13:57.22 |
| chrisl | kens: well, as our CFF interpreter is in C, it should be viable to make it more tolerant - but I agree that the font is broken, so it's not a "bug" | 13:59.40 |
| kens | :-) | 13:59.55 |
| | I hope that it wasn't really GS 9.04 that created that font.... | 14:00.17 |
| chrisl | Well, if it was, *that* would be a bug, and we should get the source file for it | 14:00.46 |
| kens | Yep, I've put something to that effect in the bug thread | 14:00.58 |
| | And now, back to where I was last Wednesday..... | 14:01.51 |
| tor8 | Digit_: the main memory use in MuPDF can be the rendered page images. these depend on the display size, and are completely independent of the pdf complexity. | 14:34.21 |
| | if you have a 4K display, you'll need about 30Mb per page | 14:35.09 |
| | and we render and cache a few pages to increase performance | 14:35.25 |
| | I believe about 5 pages, so that's 150Mb | 14:35.53 |
| henrys | tor8, Robin_Watts : do we want to go after them for gpl compliance or report it to sebras or somebody - on windows they simply took sumatra? | 14:37.06 |
| Robin_Watts | NVA ? | 14:37.35 |
| henrys | oh yes sorry | 14:37.46 |
| tor8 | there's no point reporting it to sebras (he's the one usually reporting his finds to us, not the other way around...) | 14:37.54 |
| | I'd say take them down or make them buy a license | 14:38.04 |
| | which might be impossible for Sumatra; too many authors involved on their side I think | 14:38.28 |
| | but they should at least be paying us for the mobile app | 14:38.38 |
| Robin_Watts | report them to zeniko, but I doubt he'll be able to do much. | 14:38.42 |
| henrys | I didn't mean sebras I meant zeniko | 14:38.59 |
| Robin_Watts | Digit_: 120Meg sounds like the store size. | 14:39.10 |
| tor8 | henrys: right. we should probably let him know, but I don't think he's in a position to get lawyers involved. | 14:39.35 |
| Robin_Watts | Digit_: MuPDF will use memory to cache decoded elements from the PDF. This is termed our 'store'. | 14:39.42 |
| | The store is currently set to a 128Meg max, I think. | 14:39.56 |
| | You can alter the code to reduce that if it's giving you problems. | 14:40.05 |
| | BUT it should transparently shrink rather than run out of memory. | 14:40.17 |
| Digit_ | Robin_Watts: Thanks for the info | 14:40.55 |
| | Its not shrinking it only grows | 14:41.19 |
| Robin_Watts | Digit_: It should shrink when you close the PDF. | 14:41.38 |
| Digit_ | yes that it is doing | 14:41.51 |
| Robin_Watts | Whenever we do a malloc, if the malloc fails, we evict things from the store and retry. | 14:42.09 |
| Digit_ | but it is impossible right now to go to 5-6 page on a samsung tab 10.1 i even tried the sample apps provided | 14:42.16 |
| Robin_Watts | What version of android? | 14:42.52 |
| Digit_ | i wonder if i can reduce the bitmap pixel depth, i saw something liek ARGB_8888 | 14:42.53 |
| | 4.4.2 | 14:43.03 |
| Robin_Watts | Digit_: No, you can't reduce that. | 14:43.08 |
| Digit_ | ok | 14:43.13 |
| Robin_Watts | Look for the fz_new_context line. | 14:43.13 |
| Digit_ | ok wait a moment | 14:43.20 |
| Robin_Watts | Change the value there from 1<<20 to 1<<18 say. | 14:43.30 |
| tor8 | Robin_Watts: could be android behaving like linux and never letting malloc fail, and instead just kill the process if it overcommits | 14:44.16 |
| Digit_ | the line is two times in there and both are set to 128<<20 currently | 14:44.35 |
| henrys | here's where we are at: we all talked NVA, lawyer and Artifex (me), their response was to make the app free ($) which I didn't expect, I thought licensing or take down would happen. So now either artifex or sumatra can go after them for GPL compliance, the lawyer is out because Miles isn't going to pay for it since he's gotten most of what he wants. | 14:44.41 |
| Digit_ | so i change both to to 1<<18 ? | 14:44.49 |
| Robin_Watts | digit: Sorry, no. | 14:44.55 |
| | To 64<<20. | 14:45.00 |
| | 64meg instead of 128Meg. | 14:45.07 |
| Digit_ | ok i try let me check, i will report back to you thanks | 14:45.16 |
| Robin_Watts | or 32<<20 | 14:45.18 |
| | henrys: Right, but presumably you still have a contact with them. | 14:45.51 |
| henrys | right that's what I'm asking do you want me to pursue the GPL compliance, have sumatra do it, or just forget about it? | 14:46.44 |
| Robin_Watts | I'd send them an email saying "While making it free is a step in the right direction, it does NOT get you off the hook. You need to move into compliance with the GNU GPL. The first step would be to release the full source for the app. In addition, we'd like a full list of companies to whom you have licensed the NVA reader." | 14:47.45 |
| | At worst they'll ignore it. | 14:47.52 |
| | At best we might get something useful. | 14:48.09 |
| | You could also say "We note that you have used the SumatraPDF source within NVA reader. If you do not swiftly move to GNU GPL compliance we will be forwarding your details for them so they can consider legal action." | 14:49.27 |
| | I'm not suggesting that we burn hours on this, but we should at least make a statement that they are still not compliant. | 14:50.44 |
| henrys | it could backfire - they clearly don't understand the GPL - once they read it and understand it they may post their source code and start charging again. | 14:54.00 |
| | but I'll give it a go | 14:54.07 |
| tor8 | I don't know if I'd call GPL compliance a backfire :) | 15:00.32 |
| Robin_Watts | Was this not the guys who were licensing their stuff as a magazine reader etc? | 15:03.37 |
| | GPL Compliance would mean releasing all their code, including the keys to get into webservers etc to download the magazines. | 15:04.10 |
| henrys | miles feels he has a win with the change to free, I don't know about any magazines but that would explain their willingness to release free. | 15:06.44 |
| | oh wait I think they've made a "pro version" jesus... | 15:10.17 |
| kens | And you pay for that one ? LOL | 15:10.35 |
| Robin_Watts | They have.... | 15:11.05 |
| henrys | but it's a different author | 15:12.21 |
| Robin_Watts | Look at that authors other apps... | 15:13.04 |
| henrys | yup saw that... | 15:13.19 |
| Robin_Watts | I think he's found a set of .nva files (which tend to be medical texts etc) and released an app per book. | 15:13.41 |
| henrys | and then the description: if you are looking for a good NVAReader ... what the hell does that mean. | 15:13.49 |
| | ? | 15:13.50 |
| Robin_Watts | .nva = their file format. | 15:14.04 |
| | it's a bent PDF according to prof google. | 15:14.15 |
| | http://fileinfo.com/extension/nva | 15:14.41 |
| henrys | thanks | 15:14.49 |
| | I thought it was north vietnam army ;-) | 15:15.03 |
| kens | So, we could add support for .nva files to MuPDF ? :-) | 15:15.19 |
| Robin_Watts | kens: potentially. | 15:15.48 |
| kens | Just kidding | 15:15.54 |
| henrys | okay thanks I can take it from here. Probably bad if everyone spends time on this. | 15:18.33 |
| Robin_Watts | jeez. | 15:18.57 |
| | There is a sed script to convert from NVA to PDF. | 15:19.07 |
| | http://forums.fofou.org/sumatrapdf/topic?id=3184315 | 15:19.12 |
| | That's just... bonkers. | 15:19.49 |
| henrys | yup just finished that. | 15:19.49 |
| Robin_Watts | based on that, it'd be an hour or twos work to add nva support to mupdf. | 15:26.52 |
| kens | I think it might be even quicker to add it to GS | 15:27.04 |
| | I think we could just duplicate all teh required tokens and have them call the same functions as GS does now. | 15:27.31 |
| | I may try that at the weekend if I get some time, it would be fun to add .nva support to Ghostscript | 15:27.54 |
| | I guess it might take a little while ot isolate all the mangling they've done. | 15:28.51 |
| tor8 | Robin_Watts: lol at NVAReader owner replies in that thread | 15:31.41 |
| kens | I was just reading that... | 15:31.52 |
| | He didn't get a lot of sympathy so far | 15:32.00 |
| Robin_Watts | henrys: Probably we should report all the nva reader stuff to apple. | 15:38.18 |
| henrys | sure and google | 15:38.52 |
| Robin_Watts | If apple refuse to take them down, we should report the apps to the owners of the copyright in the books (and copy those reports to google and apple, pointing out that google and apple have been informed and are complicit in the copyright theft) | 15:39.34 |
| tor8 | Robin_Watts: henrys: so, DMCA take down notice in essence? | 15:40.44 |
| Robin_Watts | DMCA take down, yes. | 15:41.10 |
| | If that fails, (and history suggests that apple and google are shite about stuff) then report them to the publishers of the books. | 15:41.41 |
| | grays anatomy goes for 115 quid on kindle. | 15:42.57 |
| | I bet the publishers would be happy to beat on apple/google with lawyers. | 15:43.32 |
| | kens: I suspect we shouldn't add nva support, given that all nva books appear to be warez. | 15:46.39 |
| kens | Yeah I was coming to that conclusion rapidly | 15:46.56 |
| | We certainly don't want to encourage that | 15:47.19 |
| henrys | on the other end of this is: how could a person of normal means in Laos or somewhere study medicine without this illegal system? | 15:48.17 |
| chrisl | Libraries? | 15:48.41 |
| kens | Or public (ie state) support | 15:48.59 |
| chrisl | I seem to remember using them when I was a student..... | 15:49.01 |
| Robin_Watts | henrys: presumably there is a grays anatomy (vietnamese student edition) that retails for less. | 15:49.42 |
| | henrys: The fact that there are warez PDF files out there of these books is one thing. | 15:50.57 |
| | The fact that someone has done bent versions of those and is selling them to make money is another. | 15:51.16 |
| | You can argue that the first is "morally less bad" than the second if you want, but the second is indefensible. | 15:51.50 |
| henrys | Robin_Watts: I agree | 15:51.58 |
| | anyway I'm going to point miles and the lawyer at all this new information and let them sort it out. I need to work on other stuff. | 15:52.36 |
| kens | Hmm, in Europe NVA is a registered charity, established in 1992 | 15:52.54 |
| Robin_Watts | Nacionale Vita Activa. | 15:53.41 |
| kens | yes, them | 15:53.45 |
| chrisl | It's also a hi-fi company: Nene Valley Audio | 15:54.02 |
| kens | :-) | 15:54.06 |
| Robin_Watts | hehe. Based in Glasgow. Why do I immediately think it must be a dodgy tax evasion scheme? :) | 15:54.14 |
| Digit_ | Robin_Watts: I tried your suggestion regarding the store setting 32/64 << 20 but nothing changed on the galaxy tab it always allocates big heap blocks of around 64mb per page | 15:57.48 |
| | So i went a different way | 15:57.54 |
| henrys | chrisl: sharing a class assigned textbook amongst all the students in a class. How many copies of the text did you have in the library? | 15:58.23 |
| Digit_ | i added the largeheap setting to the manifest and changed to 512 << 20 | 15:58.23 |
| | Robin_Watts: Now i can open the pdf around 4 times until the heap grows to 480 MB and crashes again hihi | 15:59.19 |
| rayjj | mvrhel_laptop: I implemented the "fix" to transparency with pattern-clist it gets the same numbers as non-clist patterns now (not to surprising), but I have some cleanup to do. I did have to promote the blending_mode to the tile instead of just in the ttrans struct (which is only for raster patterns) | 15:59.36 |
| Robin_Watts | Digit_: Does this happen with all PDFs or just this particular one? | 15:59.47 |
| Digit_ | i really wonder how to use muPDF on large display devices | 15:59.52 |
| | with all | 15:59.54 |
| Robin_Watts | Are you using the latest release? | 15:59.58 |
| mvrhel_laptop | rayjj: great! | 15:59.59 |
| Digit_ | yes i do | 16:00.04 |
| Robin_Watts | I have a 2K screen on my phone , and it works fine here... | 16:00.10 |
| rayjj | Digit_: did you post the PDF somewhere (bug report, for example) so we could duplicate it. | 16:00.35 |
| Digit_ | I think it is really related to the samsung tab | 16:00.37 |
| Robin_Watts | That wouldn't surprise me. | 16:00.46 |
| Digit_ | because on other devices its not happening | 16:00.52 |
| chrisl | henrys: generally for required reading/reference, there were several copies of each. It only became a problem when someone kept the copies longer than they were supposed to. For the most important texts, there were also reference copies you could only use in the library. | 16:01.01 |
| Robin_Watts | It's possible samsung broke the bitmap handling. | 16:01.11 |
| Digit_ | that could be but i cannot find anything on the net regarind the big heap block its always allocating | 16:02.06 |
| | i will do some bitmnap test tomorrow and let you know | 16:02.17 |
| | thanks for the help! cu | 16:02.36 |
| Robin_Watts | cu | 16:02.36 |
| henrys | chrisl: huh that wouldn't work in the states at any school I know of... everyone really has to buy the books at ridiculous prices because publishers can't sell them in volume. It's the source of a lot of controversy here. Textbooks cost becoming a signicant proportion of college costs. | 16:08.18 |
| tor8 | henrys: the controversy would be lessened if the text books could be handed down for a couple of years, but the whole focus on having the latest edition for the end of chapter quiz questions or exercises (that usually are the only things that change between editions) is designed to thwart the second hand market | 16:10.09 |
| chrisl | henrys: for my first degree a lot of the required reference texts were government reports and surveys which, assuming you actually could still buy them, would be thousands of pounds a copy.... even for my masters, several of the required reading texts were out of print..... | 16:10.47 |
| barq | Hi, I am using MuPfd on Android and get cannot lseek errors when opening several pdfs consecutively. Any ideas how I can fix this? | 16:14.43 |
| Robin_Watts | barq: You are using vanilla MuPDF, or you are using our code in your own project ? | 16:17.50 |
| barq | I am using the library in a separate App. | 16:18.25 |
| | The error is: | 16:19.00 |
| | E/libmupdf(5321): error: cannot lseek: Bad file number E/libmupdf(5321): warning: read error; treating as end of file E/libmupdf(5321): warning: premature end of data in flate filter | 16:19.03 |
| | Robin_Watts: ^ | 16:19.12 |
| Robin_Watts | Do the errors occur in vanilla MuPDF? | 16:19.28 |
| | And what version of MuPDF? | 16:19.48 |
| barq | I haven't tried in "vanilla" MuPDF. | 16:21.09 |
| | I'll try to find out the version. | 16:21.15 |
| Robin_Watts | barq: Either it's a broken PDF file (in which case you'll get the same problems in normal MuPDF) | 16:21.47 |
| | Or it's a bug in normal MuPDF in which case, you'll get the same problems, and we can look at fixing it. | 16:22.13 |
| | Or the problem won't occur with normal MuPDF, in which case we'd have to suspect that it's something to do with you calling MuPDF incorrectly. | 16:22.48 |
| barq | It's not a bug in the pdf. The error occurs on different pdfs, usually after opening 3 or 4, whichever it is | 16:23.11 |
| Robin_Watts | You say you are using the library in your app. | 16:23.23 |
| barq | Yes. | 16:23.28 |
| Robin_Watts | Are you using just the C library? Or are you using our java classes too? | 16:23.42 |
| barq | Robin_Watts: I am using APV 0.4.0.2. | 16:31.50 |
| Robin_Watts | barq: You what now? | 16:32.21 |
| barq | ? | 16:32.34 |
| Robin_Watts | Is that malc_'s thing? | 16:32.53 |
| barq | http://code.google.com/p/apv/ | 16:33.05 |
| Robin_Watts | We develop the MuPDF library here. We do our own android viewer. | 16:33.27 |
| | APV is an android app that uses our lib developed by someone else. | 16:33.56 |
| barq | The error is in the library, though. | 16:34.08 |
| Robin_Watts | I think the author is often here as 'malc_', but APV is nothing to do with us. | 16:34.22 |
| tor8 | barq: the error may well appear in the library, doesn't mean it's caused by the library | 16:34.32 |
| Robin_Watts | Yes, the error is in the library, but it's probably down to how APV is calling the library. | 16:34.35 |
| barq | ok | 16:34.45 |
| Robin_Watts | I'd suspect that you're screwing an fz_context up. | 16:34.47 |
| barq | Any ideas where I could look for a solution? | 16:35.01 |
| Robin_Watts | barq: Contact malc. | 16:35.11 |
| henrys | presumably NVA is serving medical students where books costs are thousands of dollars a year in the states. Googling I see $3000 US is typical for first year, so I bet NVA has a lot of customers here in the US too. | 16:36.35 |
| kens | That does seem like an awful lot for textbooks, even a t a couple of hundred per book | 16:37.11 |
| Robin_Watts | henrys: Indeed, that seems like a rip off. | 16:37.23 |
| | But capitalism says that if someone can sell a set of text books for $3000, there is a market for a set of textbooks at $2500... | 16:38.03 |
| kens | Except htat its not a completely free market | 16:38.30 |
| | However, I'd imagine lower income countries don;t require as many text books perhaps | 16:38.52 |
| | Or as tor pointed out, are happy to use older editions | 16:39.59 |
| Robin_Watts | I have a copy of "The Art of Computer Programming" that I imported from China (via Hong Kong). | 16:40.27 |
| | Cost me £30 including postage rather than £100+ over here. | 16:40.43 |
| | I'd imagine that they must have similar things in place for textbooks in such countries. | 16:41.09 |
| kens | I feel sure that must be true | 16:41.21 |
| | Must check if Melanie needs any text books and see if I can get my brother to find them in English :-) | 16:41.53 |
| Seq | Are there any decent tools for analyzing pdfs? I've got some PDFs I'm adding borders to, but occasionally it seems certain PDFs have their coordinates shifted about 50,-50 (by my ballpark estimate). | 18:20.18 |
| mvrhel_laptop | henrys: are you around? | 18:32.54 |
| henrys | mvrhel_laptop: yea what's up | 18:33.09 |
| mvrhel_laptop | did you see the most recent email from stefan? | 18:33.19 |
| henrys | reading now | 18:33.37 |
| mvrhel_laptop | I really have no idea what he is seeting | 18:33.38 |
| | seeing | 18:33.41 |
| rayjj | Seq: other than gs -- toolbin/pdf_info.ps IN.pdf you can try mutool clean -d IN.pdf OUT.pdf to get a human readable one | 18:33.43 |
| | Seq: And if you want to watch things being painted on the page: gs -dPDFSTEP IN.pdf | 18:34.34 |
| Robin_Watts | mvrhel_laptop: That does seem very odd. | 18:35.02 |
| | What platform is he on? | 18:35.08 |
| rayjj | Seq: but if the page has transparency you may need to add -dNOTRANSPARENCY before IN.pdf | 18:35.11 |
| mvrhel_laptop | Robin_Watts: I believe he is on Linux | 18:35.21 |
| rayjj | mvrhel_laptop: the one about the trio FPF | 18:35.26 |
| | ? | 18:35.30 |
| mvrhel_laptop | rayjj: yes | 18:35.36 |
| rayjj | mvrhel_laptop: that is a strange one | 18:35.53 |
| Robin_Watts | gsdll32.dll sounds windowsy to me. | 18:36.23 |
| henrys | he's not on linux it's a windows traceback | 18:36.34 |
| rayjj | Robin_Watts: good point | 18:36.38 |
| mvrhel_laptop | oh yes | 18:36.39 |
| henrys | what Robin_Watts said | 18:36.39 |
| mvrhel_laptop | sorry | 18:36.40 |
| Robin_Watts | Can he try a debug build? or a memento build maybe? | 18:36.59 |
| rayjj | I got a strange message from my previous cluster run: mickeys reports: nodeFail: log file(s) too big: and it lists a bunch of files and sizes, but the log doesn't seem to correspond to the list | 18:38.24 |
| Robin_Watts | rayjj: If the log is too big, you may be getting the log from the previous job? Just guessing. | 18:38.59 |
| mvrhel_laptop | all good questions. I feel like he possibly has some franken project to though. He does not like to use git and I had to give him my files which he used to create a patch for svn which is what they are using | 18:39.01 |
| Seq | rayjj, Thanks. That's actually a huge help. | 18:39.09 |
| rayjj | Robin_Watts: I tried again and it also aborted, so I'm going to have to see what it says this time | 18:39.35 |
| mvrhel_laptop | The files that I gave him were really not changed from 9.15 which he said is the version he is working from | 18:39.56 |
| rayjj | Seq: probably not much help, but it's how I start debugging PDF's | 18:40.00 |
| mvrhel_laptop | Not changed other than my changes | 18:40.06 |
| Robin_Watts | mvrhel_laptop: I dread when clients say "just send me the changed files" | 18:40.12 |
| mvrhel_laptop | yes | 18:40.16 |
| Robin_Watts | Can we not send a full 9.16 and say "they are all changed" ? :) | 18:40.33 |
| mvrhel_laptop | so I feel like there is lots of potentials for issues | 18:40.36 |
| Robin_Watts | My first thought would be some sort of memory corruption. | 18:41.28 |
| rayjj | mvrhel_laptop: you might resort to having him zip up his source and send it to you to apply the changes -- that's what I have to do with cust 532 (but they are a high pri customer) | 18:41.38 |
| mvrhel_laptop | yes. I agree. perhaps the memento would be good | 18:41.45 |
| rayjj | mvrhel_laptop: at least you should be able to reproduce his failure | 18:42.13 |
| Robin_Watts | rayjj: that might work. Get him to send a copy of the the working project, and have us apply the diffs. | 18:42.21 |
| mvrhel_laptop | rayjj: true. | 18:42.22 |
| henrys | rayjj's customer is a lot higher priority than this guy unfortunately. | 18:42.22 |
| mvrhel_laptop | henrys: what do you want me to do | 18:42.33 |
| | this could be a bit of a time sink | 18:42.50 |
| henrys | mvrhel_laptop: you have tried pushing back with: "reproduce it in our code and we'll fix it" | 18:43.00 |
| rayjj | henrys: agreed. But emails back and forth may end up eating a lot of time, too | 18:43.13 |
| mvrhel_laptop | henrys: I have not said that yet | 18:43.34 |
| | but it would be good for him to compare the two perhaps | 18:43.43 |
| henrys | mvrhel_laptop: you can say "Please try and reproduce it in our system and if you can we'll be happy to take it from there" | 18:45.00 |
| Seq | rayjj, Actually, -dSTEPPDF, while very verbose, looks very helpful | 18:46.33 |
| rayjj | ahh... OK, I can reproduce the massive log files. | 18:46.44 |
| | Seq: you can enter a count to "skip" that cuts down on some of the initial loading | 18:47.26 |
| | Seq: I usually do several runs, starting with moderately large skip counts until I see something getting painted, then restart to see the point of interest | 18:48.36 |
| | Seq: BTW, it is -dPDFSTEP (not -dSTEPPDF) | 18:49.11 |
| | but since you were getting it to do something, you probably had it right on the command line :-) | 18:49.52 |
| Robin_Watts | Seq: How are you adding borders to a PDF? | 18:49.54 |
| | If you mean you're just adding whitespace, then presumably it's just a matter of fiddling the mediabox/cropbox etc ? | 18:50.16 |
| | no changes to the content streams? | 18:50.37 |
| rayjj | Robin_Watts: gs would let you add visible outline borders in the BeginPage proc (if you know what you are doing) ;-) | 18:51.19 |
| mvrhel_laptop | ok I sent him an email with a list of things that he can look at | 18:51.45 |
| Robin_Watts | rayjj: MuPDF has (or almost has :) ) content stream filtering for that. | 18:51.53 |
| rayjj | mvrhel_laptop: hope that works | 18:51.55 |
| | Robin_Watts: "almost" ??? | 18:52.07 |
| mvrhel_laptop | have to pick up car. bbiaw | 18:52.11 |
| Robin_Watts | rayjj: It might be on my repo rather than golden ;) | 18:52.26 |
| rayjj | Robin_Watts: I see. Sounds like it might be interesting / handy. Any docs on how it works ? | 18:53.07 |
| Robin_Watts | rajj: No docs yet. | 18:53.37 |
| rayjj | guesses the answer is "read the source" ;-) | 18:53.39 |
| Robin_Watts | But essentially we have pdf_processor structs which are a list of function pointers. | 18:54.11 |
| | one function pointer for each pdf operator. | 18:54.17 |
| | The default set 'runs' that operator. | 18:54.28 |
| | We have other sets that write the operator back out again into a buffer. | 18:54.48 |
| | I have another set that removes extraneous stuff from the stream. | 18:55.33 |
| | So you can filter a page stream and get an identical page out with a cleaner page stream. | 18:55.59 |
| | One of the things the filtering does is to ensure that everything happens in a q/Q, so that the top level ctm isn't changed when the page completes. | 18:56.43 |
| rayjj | Robin_Watts: so how are the operands are presented to the func | 18:56.46 |
| Robin_Watts | Every func takes a pdf_csi *. | 18:57.22 |
| | Which is a pointer to the interpreter state (including the stack of operands) | 18:57.44 |
| | So if you filter the stream you can append stuff to add watermarks etc. | 18:58.13 |
| | or borders etc. | 18:58.24 |
| Seq | Robin_Watts, I'm shrinking and centering the page, adding a black border, header title, and footer page counter, as I'm concatenating a number of PDFs | 19:32.20 |
| Robin_Watts | Seq: Ah, so you *are* changing the page content streams. | 19:32.46 |
| | Are you also changing annotations to match ? | 19:33.26 |
| | presumably you are putting drawing operations for your stuff at the start of the streams, then changing the ctm, then including the existing page contents unchanged? | 19:34.43 |
| Seq | Robin_Watts, via BeginPage, adding the border/header/footer is simple. Then I'm doing a scale, then a translate to center the scaled page, and let the original page do it's own thing | 19:43.03 |
| Robin_Watts | Seq: Ah, you're using gs and BeginPage etc. | 19:43.34 |
| Seq | Regarding annotations, I'm ditching pdfmark outlines. Are there other things I should be on the lookout for? | 19:43.46 |
| | Robin_Watts, correct | 19:43.50 |
| Robin_Watts | Well, pdfwrite will render annotations as part of the page. | 19:44.23 |
| | (I believe) | 19:44.26 |
| | so things like 'stamps' will end up cooked into the doc. | 19:44.48 |
| | And things like clickable links will be lost. | 19:44.58 |
| Seq | that's fine. This is an overview, the original docs are still the original docs. | 19:45.25 |
| Robin_Watts | I'd thought you were working using pdf manipulation rather than by just letting gs rewrite the files. | 19:45.39 |
| Seq | letting gs rewrite seemed easiest to me. | 19:46.35 |
| | I think the issue I had, (thanks rayjj) is one of my sample pdfs was doing `/SIZE 828`, instead of the presumably correct `/SIZE 792`. That seemed to cause a mismatch in coordinates in relation to the page. | 19:48.53 |
| | so my border appears to be the correct dimensions based on the page, but 0,0 was off the bottom of the page. | 19:49.34 |
| rayjj | 5Tb USB 3.0 drive for $129 -- not bad. I need one to back up all my videos of the kids | 20:28.03 |
| Robin_Watts | Not bad at all. | 20:34.08 |
| rayjj | much closer. A few segfaults (some from PS files which I didn't expect) and 591 differences to look at with bmpcmp. The segfaults may not be due to my changes since we may not have tested with -dMaxPatternBitmap=10000 previously | 21:39.13 |
| | at least without MPB=10k there are no segfaults and no diffs | 21:39.36 |
| | I guess I could run a cluster on HEAD with MPB=10k | 21:39.58 |
| | after CA tax, the $129 drive costs $140, but still, that's $28/Tb | 21:48.19 |
| | interesting. fts_14_1416 and fts_31_3107 (p2) are clear progressions. They were quite ugly previously if we used -dMaxPatternBitmap=10k | 22:16.14 |
| | and now they match the raster pattern mode | 22:19.27 |
| | so, when I fix the segfaults, I'm good to go | 22:20.19 |
| | mvrhel: for the logs. My patch is on my git repository and has no regressions, and testing with -dMaxPatternBitmap=10k shows the above progressions. I am looking into the pattern-clist induced segfaults that have been around for a while (e.g. ftss_23_2303.pdf) | 22:52.16 |
| | mvrhel: Let me know if you have any problems. I may go ahead and commit this "as-is" while working on the segfaults that have been present for a long time | 22:53.20 |
| | mvrhel: the commit in its current state is at http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=ecff419c6e814a3f61282fecee91019b2e1f99f6 | 22:54.45 |
| | Forward 1 day (to 2015/02/13)>>> | |
IRC Logs