| | <<<Back 1 day (to 2015/09/24) | 20150925 |
| mvrhel_laptop | running bmpcmp now this fix shaved off a good bit of time according to the regression tests | 04:42.00 |
| | we will see what diffs look like.... | 04:42.15 |
| | diffs look reasonable | 04:50.38 |
| | henrys: speed up in the regression testing was pretty significant | 04:54.45 |
| | gs went from 19:42:34 to 15:25:29 | 04:55.06 |
| | not sure how marcosw computes those | 04:55.23 |
| | pushing this and then closing the bug | 04:56.03 |
| | I really wonder if we should put this in the RC | 04:59.01 |
| | but we can talk about it tomorrow | 04:59.08 |
| | and no customer bugs for me. so back to gsview... | 05:00.09 |
| | but bed time now | 05:00.23 |
| tor8 | Robin_Watts: question: why do we call fz_register_document_handlers manually? | 09:16.50 |
| | is that an attempt to keep down the executable sizes for mutool? | 09:17.05 |
| Robin_Watts | tor8: The idea is that other people can add new document handlers. | 10:31.46 |
| | fz_register_document_handlers is merely a convenience function. | 10:32.05 |
| tor8 | Robin_Watts: yeah, but shouldn't our default handlers be installed by default? less stuff you have to remember to set up when you init mupdf... | 11:16.06 |
| Robin_Watts | tor8: I think we want the ability to not install the default stuff. | 11:39.39 |
| | For space, as you say. | 11:39.44 |
| | tor8: OK, so I'm going to have a quick look at the VS2005 build problem, OK? | 12:39.23 |
| tor8 | Robin_Watts: okay. | 12:39.31 |
| Robin_Watts | tor8: OK, so the problem is because of the: typedef int64_t fz_off_t; line. | 12:59.19 |
| | Using int there it compiles with no problems. | 12:59.28 |
| | So it's not something that can fixed by tweaking includes. | 12:59.43 |
| tor8 | so it crashes if we pass int64_t values to 64-bit file functions? | 13:11.59 |
| Robin_Watts | tor8: No. Or at least not obviously that. | 13:13.19 |
| | It's a compiler optimisation bug that seems to be triggered when we are using int64_t's *somewhere*. | 13:13.45 |
| | I'm trying disabling link time code generation... | 13:13.57 |
| | Right, that solves it. | 13:14.02 |
| | I think that's a reasonable fix. | 13:14.09 |
| tor8 | if changing the compiler options works, then that's good enough for me | 13:14.40 |
| Robin_Watts | So, there is 1 more problem we could look at before release. | 13:15.12 |
| | actually, maybe we could benefit by doing a quick sweep of bugzilla. | 13:16.14 |
| | but http://bugs.ghostscript.com/show_bug.cgi?id=696115 was the one I had in mind. | 13:16.20 |
| tor8 | we should merge the gl branch and put mupdf-gl in the release | 13:16.31 |
| | but yes, a quick sweep of the bugzilla wouldn't hurt either | 13:16.39 |
| Robin_Watts | The problem is that the latest gcc doesn't treat longjmp as a function call. | 13:16.40 |
| tor8 | I've not looked at bugs at all since coming back from vacation... | 13:16.56 |
| Robin_Watts | hence when we longjmp it doesn't flush memory writes. | 13:16.57 |
| | I think maybe we need an fz_longjmp. | 13:17.12 |
| tor8 | also, there is something that bugs me | 13:17.14 |
| | if we can't recognize a file type, we default to PDF and if it isn't a PDF we try to repair it | 13:17.30 |
| | if it's obviously not a PDF, we should bail at some point | 13:17.38 |
| | now we error out with the document having 0 pages instead | 13:17.45 |
| Robin_Watts | tor8: yeah, if we can't find a valid PDF header within the first 4K (or trailer maybe)? we should bale. | 13:18.09 |
| tor8 | wow, that's sounds like plain broken gcc behaviour | 13:19.06 |
| chrisl | IIRC, the PDF spec says the PDF header should be inside the first 1K | 13:20.20 |
| Robin_Watts | tor8: Yes. | 13:20.21 |
| tor8 | yeah, start by looking for a version in the first 4K before we seek to the end to look for startxref would be okay | 13:20.24 |
| Robin_Watts | chrisl: Yes, but I think Acrobat is more forgiving. | 13:20.35 |
| | We should do 4097 bytes so as to be even more forgiving than acrobat :) | 13:20.59 |
| tor8 | Robin_Watts: something confuses me, we check explicitly for if we have a /Root object and if we don't we make one up in pdf_repair_ | 13:21.09 |
| | why not just bail then and there? | 13:21.15 |
| Robin_Watts | tor8: What if it's the /Root object that has been corrupted? | 13:22.10 |
| | It's not atypical for the /Root to be the final object in the file. | 13:22.24 |
| | (And you wrote that code, I think :) ) | 13:22.49 |
| tor8 | a long long looooong time ago! | 13:23.27 |
| | header check sounds like the best way out here | 13:23.37 |
| | and maybe a sanity check that we have at least one page after repairing | 13:24.06 |
| Robin_Watts | tor8: hehe. I've just been retrofitting stuff to the SOT PDF agent. Which I first wrote back in 1995 ish. | 13:24.37 |
| tor8 | hmm. we start repairing because we can't find the version marker if you run it on a non-pdf file | 13:25.37 |
| Robin_Watts | tor8: Yeah, having a corrupted version marker is something we want to fix. | 13:30.11 |
| | But we should probably insist that either the version marker, OR the trailer should be valid. | 13:30.29 |
| | Or maybe that at least we spot an x x obj ... endobj within the top part of the file or something. | 13:30.55 |
| tor8 | Robin_Watts: I have a two-line fix that should work well enough | 13:42.23 |
| | if we found no objects during the scan, we can safely bail | 13:42.34 |
| Robin_Watts | tor8: seems reasonable. :) | 13:45.01 |
| tor8 | Robin_Watts: two commits on tor/master | 13:45.03 |
| | updating the example.c file to use the new convenience function | 13:45.14 |
| | and add proper error handling | 13:45.20 |
| | if people are going to copy & paste examples, better show them how to deal with errors as wel | 13:45.32 |
| | l | 13:45.34 |
| Robin_Watts | The style in the examples.c file is at odds to the rest of mupdf. | 13:46.22 |
| | if (asdasd) { | 13:46.26 |
| | Other than that, looks good. | 13:47.18 |
| tor8 | Yes. But it's the most commonly found C style :) | 13:47.36 |
| | actually, I should amend the comment at the top. the usage is wrong, it has an 'output.png' in there | 13:47.54 |
| | I figure printing as PPM would show how to access the pixel data better than an opaque 'write to png' call | 13:48.15 |
| Robin_Watts | And chlamydia is the most commonly found STD. Doesn't mean you want it though. | 13:48.15 |
| | tor8: sure. | 13:48.41 |
| tor8 | which style does gs use? | 13:48.48 |
| Robin_Watts | 'style'. 'gs'. Does not compute. | 13:49.07 |
| tor8 | I think sebras is to blame for the current brace style in mupdf ... my personal preference is for K&R. | 13:49.25 |
| Robin_Watts | My preference is for if ()\n{\n...\n} (i.e. what MuPDF has). | 13:52.47 |
| | so I'm with sebras. | 13:52.51 |
| chrisl | I think that makes it much easier to see "blocks" of code, and thus follow the logic of the code | 13:53.26 |
| Robin_Watts | tries to persuade Ubuntu to install gcc 5. | 13:53.27 |
| | chrisl: Indeed. | 13:53.32 |
| chrisl | Which is why I prefer it, too | 13:53.45 |
| | Hmm, my ubuntu doesn't have a gcc 5 package..... | 13:54.34 |
| Robin_Watts | g++-5 ? | 13:56.03 |
| chrisl | You must be more up to date than me | 13:56.31 |
| Robin_Watts | Hmm. I can't get 5 either. | 13:57.02 |
| chrisl | There's a ppa you could try | 13:57.13 |
| | https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test | 13:57.21 |
| Robin_Watts | Supposedly I have 4.9 already, and 4.9 should exhibit the bug... but doesn't for me. | 13:57.22 |
| tor8 | Robin_Watts: okay, style updated example.c on tor/master | 13:57.31 |
| Robin_Watts | much nicer. Looks good to me. | 13:59.18 |
| tor8 | Robin_Watts: oh, did you review the epub commits on tor/master? | 14:00.25 |
| Robin_Watts | looking now. | 14:02.23 |
| | So, fallback text and text can be interleaved. | 14:02.33 |
| | l k t h | 14:02.42 |
| | i e i s | 14:02.49 |
| | bah. That'd have been more impressive if I got that right. | 14:03.03 |
| | My point is that suppose we have a sTrInG, where the capitals are only in the fallback font. | 14:03.39 |
| | Then we'll write that to the device interface as srn TIG, which will upset any text extraction we ever do. | 14:04.04 |
| | or text -> speech etc. | 14:04.13 |
| | All the other commits look good though, and that's a minor point, so I wouldn't hold up the commit for that. | 14:04.46 |
| tor8 | Robin_Watts: yeah. I want to rewrite that code to buffer up longer strings of text into one fz_text instead of creating one per word. | 14:07.36 |
| | this was just the fastest way to get things done | 14:07.50 |
| Robin_Watts | Sure. Go for it then. | 14:08.00 |
| tor8 | but as you say, that's for later :) | 14:08.43 |
| Robin_Watts | bug 696194 sounds like a "I am not going to help you with this until you get a commercial license" one. | 14:09.35 |
| tor8 | Robin_Watts: another idea I had was to add fallback fonts to the actual fz_font structure | 14:10.01 |
| Robin_Watts | DFOEindia sound like a 'digital textbooks' company to me, and if they are using MuPDF, we should get paid. | 14:10.04 |
| | tor8: Yes, I was about to say that maybe fallback should be something we handle at a lower level. | 14:10.21 |
| tor8 | not very useful for either XPS or PDF but for everything that does text layout like EPUB it would be handy | 14:10.28 |
| Robin_Watts | SOT has the idea of fallback fonts in that way - we make a list of fallbacks so as to try to cover the different scripts available. | 14:11.01 |
| tor8 | Robin_Watts: yeah. being able to chain fallback fonts would be quite handy. | 14:11.34 |
| | especially if you've got lots of fonts for various scripts. | 14:11.50 |
| henrys | kens, tor8, chrisl: posted this after you left yesterday feel free to edit, but let me know if you do: http://twiki.ghostscript.com/do/view/Ghostscript/URWFontWork | 14:12.09 |
| chrisl | henrys: I saw - it looks fine. If I think of anything, I'll let you know, or comment on the wiki | 14:13.06 |
| tor8 | henrys: point 1, might be useful if we're explicit about the list (i.e. mention Century Schoolbook, Bookman, Gothic, Palladio/Palatino, and Chancery) | 14:13.41 |
| | other than that it looked fine | 14:13.51 |
| | Chancery is just the one font, not a family | 14:14.15 |
| henrys | tor8: oh good point I'll fix that. | 14:14.28 |
| tor8 | and probably the one base35 we could conceivably ignore | 14:14.34 |
| | apart from the obvious symbol/dingbats | 14:14.42 |
| sebras | t m p t | 14:19.38 |
| | ehm.. | 14:19.54 |
| | tor8: I am to blame for the brace style? ok. I wasn't aware of that. I was under the impression that you taught it to me... ;) | 14:20.26 |
| henrys | chrisl: tor8: if we want 35 we need to fill in the rest of the helvetica's right? or are we good with just the 4 done last time? | 14:29.35 |
| kens | henrys, I certainly have nothiing to add, I@m sure chrisl knows way more about it than me | 14:29.59 |
| henrys | there are 8 helveticas right? | 14:30.19 |
| chrisl | Yes, we don't have the Helvetica Narrow family updated - I think it would be best to get those, too | 14:31.56 |
| | henrys: ^^ | 14:31.59 |
| henrys | okay | 14:32.29 |
| Robin_Watts | tor8: Can you look at bug 696182 for a mo? | 14:34.23 |
| | zenikos first patch seems reasonable. | 14:34.33 |
| | but his second patch looks to conflict with what we have there already. | 14:34.50 |
| | It looks like you added some stuff, but it's different to his. | 14:35.07 |
| | Any thoughts? | 14:35.10 |
| | ooh. mutool draw -p test doesn't work | 14:39.33 |
| | Missing : in the getopt line. | 14:40.35 |
| henrys | I had forgotten all about those other helveticas until I tried to add stuff up and wasn't getting 35 ;-) | 14:49.29 |
| Robin_Watts | tor8: oops. I'm blind. | 14:50.01 |
| tor8 | henrys: good catch! | 14:53.31 |
| | I'd completely forgotten about helvetica narrow | 14:53.39 |
| chrisl | It's easy (even preferable) to forget..... | 14:54.35 |
| tor8 | Robin_Watts: yeah, missing a : in the getopt for mudraw | 15:00.43 |
| | Robin_Watts: with our current master, we can open with the 'user' password | 15:01.00 |
| | the 'owner' passwords passes authentication, but then fails to decrypt stuff correctly | 15:01.11 |
| | any other password fails the authentication | 15:01.18 |
| Robin_Watts | tor8: I have commits to fix that. | 15:05.23 |
| | Hey marcosw. | 15:06.45 |
| marcosw | Robin_Watts: morning | 15:07.12 |
| Robin_Watts | I've been trying to reproduce bug 696115 here. | 15:07.21 |
| | I have Ubuntu 15.04 with gcc 4.9.2 and it won't fail for me. | 15:07.36 |
| | BUT... I have a commit that I hope should work around the stupidness. | 15:07.50 |
| | Could I trouble you to test the fix for me please? | 15:08.06 |
| marcosw | sure. I also have a amazon vm that shows the problem, in case your commit doesnât work and you want ot investigate further. | 15:08.47 |
| Robin_Watts | marcosw: Ah, if the commit doesn't work, I'd love to try that out. | 15:09.45 |
| marcosw | Robin_Watts: is the commit in your repository? | 15:14.01 |
| Robin_Watts | It is. Sorry, should have said that :) | 15:14.34 |
| marcosw | Robin_Watts: oops, was about to compile your code on my macbookpro. That would not have been a useful exercise :-) | 15:17.26 |
| | Robin_Watts: unfortunately you commit does not work. Let me find the amazon vm ip address⦠| 15:21.50 |
| Robin_Watts | marcosw: I wonder if it's the FZ_NORETURN stuff... | 15:22.52 |
| marcosw | i can test that easily enough⦠| 15:24.09 |
| | nope, disabling FZ_NORETURN doesnât change anything. so far the only thing that has worked is declaring ctx volatile. | 15:27.49 |
| Robin_Watts | marcosw: I am confused. | 15:37.08 |
| marcosw | Robin_Watts: welcome to my world | 15:37.35 |
| Robin_Watts | Oh, sorry, ignore me. | 15:38.00 |
| | marcosw: OK. I have a fix. | 15:57.51 |
| | Let me just get this into a commit. | 15:57.58 |
| marcosw | that was fast... | 16:01.14 |
| Robin_Watts | It's a trivial fix, just to force the compiler to behave. | 16:02.37 |
| | marcosw: New fix on robin/master if you want to see it. Cluster testing now. | 16:08.47 |
| | tor8: Various commits there for review too. | 16:09.29 |
| marcosw | Robin_Watts: fix works for me. | 16:14.38 |
| Robin_Watts | marcosw: Thanks. | 16:14.51 |
| marcosw | Robin_Watts: thank you. I should have tried something like this myself. | 16:15.35 |
| Robin_Watts | marcosw: I wrote those macros and they still scare the pants off me. I'm not surprised they are confusing to others. Especially when faced with a compiler bug. | 16:19.00 |
| rayjj | mvrhel_laptop: thanks for following up with MQ. BTW, there is a comment in gxshade.c (that you just touched). Did you look at the area in shade_init_fill_state that says: /****** WRONG FOR MULTI-PLANE HALFTONES ******/ | 16:28.15 |
| mvrhel_laptop | hi rajj | 16:28.32 |
| | rayjj | 16:28.36 |
| rayjj | that kind of thing laying around always worries me | 16:28.40 |
| mvrhel_laptop | I did not see that | 16:28.47 |
| | hold on let me look | 16:28.54 |
| Robin_Watts | rayjj: Delete the comment. Problem solved. | 16:28.59 |
| rayjj | and since tiffsep is a planar device and is halftoned, it would have been affected (possibly) | 16:29.21 |
| mvrhel_laptop | tiffsep is not halftoned | 16:30.13 |
| rayjj | Robin_Watts: thanks. I hadn't dug into it, but as long as you or mvrhel_laptop are happy about it, then my worries are allayed | 16:30.23 |
| | mvrhel_laptop: sorry tiffsep1 | 16:30.30 |
| Robin_Watts | rayjj: I was being fascetious. | 16:30.46 |
| rayjj | Robin_Watts: oh. | 16:30.55 |
| Robin_Watts | or facetious. | 16:31.12 |
| | The vowels in that word are easy to get right. The consonants are harder. | 16:31.28 |
| rayjj | Robin_Watts: yeah, one of those. | 16:31.36 |
| mvrhel_laptop | who wrote that comment... oh I did | 16:32.08 |
| Robin_Watts | git blame --doh | 16:32.20 |
| mvrhel_laptop | hmm | 16:32.27 |
| | that was when I cut out WTS | 16:32.32 |
| rayjj | how about that. Chatzilla spell checker knows which is right, but if flags Chatzilla as misspelled ;-/ | 16:32.47 |
| mvrhel_laptop | oh but the comment predated me | 16:33.09 |
| | I just removed some wts related stuff | 16:33.34 |
| | and that moved this line | 16:33.41 |
| | I suppose someone should beat upon tiffsep1 and see what is going on | 16:34.20 |
| | and I suspect that someone will be me | 16:34.31 |
| rayjj | mvrhel_laptop: it's not a big deal since it doesn't affect any of our tests, AFAIK (pkmraw would also show it, I think), so it's not worth spending more time on. I just thought you might understand the issue since you were mucking about in the shading just now | 16:35.11 |
| mvrhel_laptop | no sorry. I will poke around a bit at it though. I don't like things like that in the code either | 16:35.40 |
| rayjj | mvrhel_laptop: maybe put a gs_abort in that 'if' and run a regression with filter=pkmraw and see if any tests error out. That'll give you something to look at | 16:36.43 |
| mvrhel_laptop | right | 16:36.53 |
| rayjj | and you can just run gs since PCL doesn't use shadings AFAIK | 16:37.20 |
| rayjj | wonders if henrys stalks "PCL" ? | 16:38.02 |
| mvrhel_laptop | so that comment has been in there since before 2008 | 16:39.13 |
| | and before 2002 | 16:40.43 |
| | furthest I can get is gs 6.0 | 16:42.08 |
| rayjj | mvrhel_laptop: what's the git command to run a blame from before a known version | 16:42.23 |
| mvrhel_laptop | I have no idea | 16:42.33 |
| Robin_Watts | git blame SHA~1 | 16:44.46 |
| | That says run the git blame starting at the commit before SHA | 16:44.58 |
| | If you know the change is in file 'x' you can do: gitk -- x | 16:45.34 |
| | and that will show just changes that affected that file. That falls down when stuff moves between files though. | 16:45.58 |
| mvrhel_laptop | My history ends though were Ralph did the split | 16:46.07 |
| | s/were/where/ | 16:49.33 |
| frenda_ | gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=png16m -r1000 -sOutputFile='page-%00d.png' input.pdf | 16:51.18 |
| | I used this command to convert a pdf file to a bunch of PNGs | 16:51.39 |
| | Now, I can't open png files by gimp | 16:51.53 |
| | it crashes | 16:52.00 |
| | I can't run 'convert' on them | 16:52.12 |
| | it's killed | 16:52.20 |
| Robin_Watts | frenda_: Try a smaller resolution. | 16:52.40 |
| | If that works, then the odds are just that the other things are erroring out due to the size of the pngs. | 16:53.05 |
| frenda_ | Robin_Watts: I wanted to get the maximum resolution | 16:53.09 |
| rayjj | mvrhel_laptop: I've got old gs versions (not all of them), but I have 5.10 and it has gxshade.c with that comment | 16:53.09 |
| mvrhel_laptop | wow | 16:53.24 |
| frenda_ | png16m vs pngalpha? | 16:53.46 |
| Robin_Watts | use png16m. | 16:53.55 |
| | Presumably you're not actually using the pngs at 1000dpi? | 16:54.19 |
| frenda_ | Can I use 100% for the switch -r, someway? | 16:54.26 |
| Robin_Watts | frenda_: Step 1) ascertain what the problem is with your workflow. | 16:54.47 |
| | Step 2) Figure out if there is a way to sidestep the problem. | 16:54.59 |
| | We're still on step 1. Do the test, and we'll worry about step 2 later on. | 16:55.09 |
| frenda_ | Ah, ok | 16:55.36 |
| | I tried 150dpi --> It gave me a bab png | 16:55.55 |
| Robin_Watts | A bad png? | 16:56.07 |
| frenda_ | I tried 300dpi, not goot, but a little better! | 16:56.10 |
| | bad png: bad quality, bad resolution | 16:56.26 |
| Robin_Watts | Ok, so you mean 'it gave me a valid png, but it didn't look nice' | 16:56.32 |
| frenda_ | exactly | 16:57.00 |
| Robin_Watts | OK. so try... gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=png16m -r1000 -sOutputFile='page-%00d.png' -dDownScaleFactor=3 input.pdf | 16:57.07 |
| frenda_ | Ok, now I try for 500 | 16:57.13 |
| | -dDownScaleFactor=3? | 16:57.46 |
| marcosw | chrisl: are you going to release a 9.18rc2 that fixes the disable-compile-inits issue? | 16:58.21 |
| chrisl | marcosw: Yeh, I guess I could - given mvrhel_laptop's recent fix, too | 16:59.09 |
| marcosw | it would be nice to have it before the weekend so I can run the regression tests (but I do realize the weekend as already started for you). | 17:00.08 |
| Robin_Watts | frenda_: -dDownScaleFactor=3 tells the system to render at the specified dpi (1000) and then scale the resultant image down by 3 in each direction. | 17:00.23 |
| chrisl | marcosw: You only need the tag, though? | 17:00.32 |
| Robin_Watts | This means you get effectively a 333dpi image with antialiasing. | 17:00.49 |
| marcosw | instead of a branch? I think thatâs correct. | 17:00.50 |
| chrisl | marcosw: the branch is (almost) up to date | 17:01.06 |
| Robin_Watts | frenda_: i.e. you get most of the benefits of the 1000dpi image in a smaller file. | 17:01.24 |
| frenda_ | Robin_Watts: Well, now I run it on the pdf file :) | 17:02.03 |
| chrisl | marcosw: the tag is done "ghostpdl-9.18rc2" so you can commence your testing | 17:03.54 |
| marcosw | chrisl: thx | 17:05.04 |
| chrisl | marcosw: I'll do the release archive on Monday - unless I feel especially enthused over the weekend | 17:06.03 |
| | s/release archive/release candidate archive | 17:06.18 |
| Robin_Watts | tor8: mutool draw -o out.html in.pdf | 17:12.27 |
| | That correctly decides it should output html, but does so to stdout, not to the file. | 17:12.45 |
| rayjj | mvrhel_laptop: actually, it wasn't 5.10 that had shading. It was added in 5.34 (which I don't have) Version 5.50 (that I have) has that "WRONG" comment in it. 5.34 date was 5/14/98 | 17:15.01 |
| | so I expect that it has been in the code since LPD wrote it. | 17:15.30 |
| Robin_Watts | tor8: A commit to fix that with the others on robin/master | 17:32.06 |
| mvrhel_laptop | rayjj: ok, I am not going to worry about it at this time then | 17:44.32 |
| | have to run a few errands | 17:44.42 |
| | bbiaw | 17:44.43 |
| frenda | Robin_Watts: -r600 -dDownScaleFactor=3 --> still convert can't handle them to create a pdf file O_o; Anyway, Is it possible to make a pdf by `gs`? Do you know any other tools? | 17:45.12 |
| | convert *.png a.pdf --> killed! | 17:45.54 |
| | Resolution: 1150x1720 | 17:46.39 |
| Robin_Watts | frenda: Eh, what? | 17:46.40 |
| | You're taking a pdf in, feeding it through gs to make a png, and then feeding that png to convert to make a pdf? | 17:47.10 |
| frenda | I've converted a pdf to PNGs --> Then I croped them by convert --> Now, I want to concatenate them to create a new PDF file | 17:47.51 |
| henrys | the new distiller, I love it. | 17:47.54 |
| Robin_Watts | frenda: That's just insane. | 17:48.28 |
| frenda | huh, why? | 17:48.43 |
| Robin_Watts | You're taking a PDF (which can have vector graphics etc), and reducing it to rendered version. Then you're putting that version back into a PDF. | 17:49.03 |
| | That's going to end up with a larger file, with worse quality. | 17:49.30 |
| frenda | So, I couldn't find a tool to crop PDF in-place | 17:49.42 |
| Robin_Watts | frenda: gs is capable of doing pdf in -> pdf out. | 17:50.04 |
| frenda | Robin_Watts: I know, this was the reason I choosed -r1000 | 17:50.11 |
| Robin_Watts | the question is whether we can crop while we are doing it. | 17:50.23 |
| frenda | for file in *.png; do convert "$file" -crop 1150x1720+74+50 aa/"$file"; done | 17:50.33 |
| Robin_Watts | That's a question you'd need to ask kens, but he's gone for the day. | 17:50.39 |
| frenda | It was the command on PNGs to crop them | 17:50.47 |
| Robin_Watts | http://stackoverflow.com/questions/6183479/cropping-a-pdf-using-ghostscript-9-01 | 17:51.29 |
| frenda | You mean I can crop by gs? | 17:51.41 |
| | Ah, ok, let me check the link | 17:51.49 |
| henrys | frenda: kurt is very good also | 17:52.09 |
| | well is gs kung fu is pretty good usually | 17:52.54 |
| rayjj | frenda: just so you understand, 'convert' (imagemagick) runs gs on a PS or PDF input to get a raster, then operates on the raster image. This is less efficient than having gs translate and clip the input and generate the desired size raster image in the first place. | 17:59.45 |
| | frenda: the method that the stackoverflow thread shows (using translate and clip) is mostly correct, but with a file that does 'initgraphics' as PS input does, or 'setpagedevice' as the PDF interpreter does, the translate and clip need to be in an /Install proc which sets the initial coordinate space, coupled with a -gWWWxHHH to "lock" the page size to a specific pixel dimension | 18:02.18 |
| | (presumably -g1150x1720) | 18:02.40 |
| | it would be nice if imagemagick 'convert' used the parameters to set up gs properly, but I am fairly sure it doesn't | 18:03.25 |
| frenda | It's a math book, probabely with lots of graphs | 18:03.40 |
| rayjj | frenda: doesn't matter what the content is. | 18:03.54 |
| | what format is it? PS or PDF ? | 18:04.03 |
| frenda | pdf | 18:04.09 |
| rayjj | frenda: and you want a PDF out ? | 18:06.12 |
| frenda | sure | 18:06.34 |
| rayjj | and the values 1150x1720 are the desire page size (in pixels at 200 dpi ?) | 18:07.28 |
| | frenda: and 74 and 50 are the desired lower left at 200 dpi in the original page that you want shifted to the origin in the output ? | 18:08.51 |
| frenda | in pixels at 600 dpi | 18:09.44 |
| | 1150x1720 at 600 dp | 18:09.55 |
| | 74-->1150<--75 | 18:10.56 |
| | I'm calculating croped zone for original size of the pdf | 18:11.49 |
| rayjj | I have to run. sorry, frenda | 18:13.52 |
| frenda | ok, thank you | 18:16.31 |
| | Original size of pdf in pt given by Gimp: W=467.3, H= 656.6 | 18:17.03 |
| | Desired: Left=28.1, Bottom=18, R=439.2, Top=628.5 | 18:19.53 |
| | in 'points' | 18:20.08 |
| | DIDn't work :'( | 18:31.45 |
| | Anyway, can I concatenate PNGs to create a pdf by gs? | 18:32.18 |
| frenda_ | This is the file that I'm trying to crop: http://libgen.io/get.php?md5=5b5a2d00b1221164ebb94c2c3c8eb797 | 18:43.58 |
| | my problem with `convert`: http://uploadkon.ir/fl/dd/76812 | 18:44.19 |
| | gs -sDEVICE=bbox -f input.pdf --> http://uploadkon.ir/fl/dd/76813 --> each page different size in points! | 18:46.08 |
| | I tried for http://stackoverflow.com/questions/6183479/cropping-a-pdf-using-ghostscript-9-01 --> it create completely the same file! | 18:46.50 |
| | with 0B as size! | 18:47.32 |
| | When I click on cropped file, it open the original file; it seems it is kind of a soft link! | 18:48.06 |
| rayjj | I guess frenda gave up | 19:44.24 |
| | I'm finally back. Hopefully "frenda" will be back, so I'll see if I can make sense of what is being attempted, since it seems to be a somewhat common need | 19:45.40 |
| | at least I have a sample input :-) | 19:46.05 |
| | well, I guess not. http://uploadkon.ir/fl/dd/76812 gives me an error, and the other link is for the PNG (of no use) | 19:48.15 |
| | frenda (for the logs): if you come back, I need to see and input file. BTW, the size for the result don't make much sense to me: 1150 pixels at 600 dpi is 1.92 inches and 1720 is 2.86 inches. These would make more sense at 200 dpi (5.75" x 8.6") but even that is a bit small | 19:51.01 |
| | frenda: and in points, they seem a bit large: 16"x24" | 19:51.58 |
| | frenda (or whoever else may care about cropping/transforming a PDF): frenda wanted "Original size of pdf in pt given by Gimp: W=467.3, H= 656.6" to be converted to "Desired: Left=28.1, Bottom=18, R=439.2, Top=628.5" (all in points) | 19:57.50 |
| | so the gs command line to take a PDF file in and write a PDF file out with PageSize [ 411.1 610.5 ] (411.1 = 439.2-28.1 and 610.5 = 628.5-18.0) is: | 20:00.45 |
| | drumrolll... (BTW, a page size of 467.3 pts == 6.5" x 656.6 == 9.12" is at least reasonable, although seems small for a textbook) | 20:02.46 |
| | gs -sDEVICE=pdfwrite -o cropped.pdf -dDEVICEWIDTHPOINTS=411.1 -dDEVICEHEIGHTPOINTS=610.5 -dFIXEDMEDIA -c "<< /Install { -28.1 -18.0 translate } >> setpagedevice " -f input.pdf | 20:09.14 |
| | Note that the above just clips (doesn't "fit") the input page to the output page, but this seems like what frenda wanted. Note the '-' for the translate to shift the origin to the left and down by the stated amounts | 20:11.14 |
| | I tested this with examples/annots.pdf that I created to the stated 'input.pdf' pagesize using: gs -sDEVICE=pdfwrite -o input.pdf -dDEVICEWIDTHPOINTS=467.3 -dDEVICEHEIGHTPOINTS=656.6 -dFIXEDMEDIA -dFitPage examples/annots.pdf | 20:12.30 |
| | the use of -dFitPage fits the input page to the desired output page size (467.3x656.6), centering the pagesize from the annots.pdf on to the output page size. | 20:14.21 |
| | Note that the use of Ghostscript to read a PDF and create a PDF is preferred to rendering to a raster image (even with anti-aliasing of images and/or text) since the original input graphics will be at full resolution and can be zoomed, and text will be able to be zoomed without 'jaggies' and will be searchable (hopefully) | 20:17.10 |
| | with text, it's always dependent on the input pdf. If the iinput pdf is a scanned "image" pdf of a page, then there is no improvement, but text that is searchable in the input pdf (even if it is "invisible" text overlay on an image) should (caveat emptor) be searchable in the output | 20:18.52 |
| henrys | rayjj must have a terrible bug... | 20:57.17 |
| rayjj | henrys: because I'm distracted by a free user issue :-) | 21:02.54 |
| | but, I've been trying to reproduce an indeterminism with the PCL files and can't, so, yeah, that's frustrating. | 21:04.17 |
| | I was hoping to get that resolved before the release | 21:04.31 |
| henrys | this was the fts thing? | 21:12.37 |
| rayjj | henrys: yeah, but I have been able to find an indeterminism with tests_private/pcl/pcl5cats/Subset/AC6ZHSC3.BIN.pbmraw.600.1 | 21:18.16 |
| henrys | fts.2291? | 21:18.18 |
| rayjj | I can get an indeterminism on peeves with repeated runs of the ats/Subset file | 21:18.57 |
| | so, now back to see if I can duplicate the issue on Windows. It is two pixels difference on the entire page | 21:21.16 |
| | I have to pick up my kids from school. bbiaw | 21:21.30 |
| henrys | okay | 21:21.40 |
| rayjj | email coming about my situation that may have me away during the day more often for a brief time. | 21:22.17 |
| jogux | henrys: /now/ you can test the rebrand on your iphone :-) | 22:16.04 |
| henrys | jogux: will do | 22:38.32 |
| jogux | thanks :-) | 22:38.38 |
| | Forward 1 day (to 2015/09/26)>>> | |
IRC Logs