| | <<<Back 1 day (to 2015/04/13) | 20150414 |
| tor8 | Robin_Watts: yeah, there was a TODO item in the url() parsing. fixed now on tor/master. | 08:56.02 |
| Robin_Watts | So, no attempt to cope with encoded chars like %34 in urls ? | 08:57.53 |
| | but seems fair enough as a first step at least. | 08:58.30 |
| | In fact, all those commits, other than the fz_meta one look good. | 08:59.32 |
| | Using strings rather than ints is a really bad idea for fz_meta. | 09:00.08 |
| tor8 | Robin_Watts: yeah. nothing in the epub/css uses the url() tokens yet. | 09:01.12 |
| | the @font-face sections are ignored | 09:01.28 |
| | why are strings so much worse than ints there? a key is a key, and strings are easier to extend without accidental collisions and version numbering than int keys. | 09:02.46 |
| | also easier to mistype, hence the #defined string | 09:03.08 |
| | I'm still not thrilled about the fz_meta interface, as it is on my commit | 09:03.27 |
| | I've considered making the keys two-level instead of using the ':' namespace separator thing for the info metada | 09:03.51 |
| Robin_Watts | tor8: the essence of the fz_meta interface is that it should be very fast to compare a key (cos meta implementers need to check for each key they understand on every call) | 09:05.02 |
| | strcmp is not fast. | 09:05.11 |
| tor8 | fz_meta is called a grand total of 10 times when displaying the 'about document' dialog on windows | 09:05.38 |
| | I'd hardly worry about performance for that use case. if we used it for something other than getting human readable information strings from it, I'd possibly agree. | 09:06.08 |
| | and the FZ_META_INFO keys dig through pdf_obj dictionaries looking for the keys | 09:06.33 |
| Robin_Watts | The point is it's extensible. We can end up using it for more things later. | 09:06.53 |
| tor8 | then let's rename the current fz_meta to fz_meta_info (seeing as I already split the has_permission) and reintroduce and int-keyed fz_meta when we need it? | 09:07.39 |
| | and use the fz_meta_info for the human readable document info | 09:07.54 |
| Robin_Watts | and just think what a pain in the ass it is to deal with strings over jni for example. | 09:07.59 |
| tor8 | how does that sound? | 09:08.00 |
| Robin_Watts | It sounds like needless complication to me. | 09:08.09 |
| tor8 | I just remembered what a pain in the ass it was to use the int-keyed and void*'d fz_meta interface from C | 09:08.33 |
| | the JNI interface needs to deal with strings everywhere else, I don't see how this would be any worse than any of our other string-argument functions | 09:09.33 |
| Robin_Watts | It's no worse than our other string-argument functions. But they are a pain in the ass too. | 09:10.56 |
| tor8 | Robin_Watts: I think a big part is due to me not liking the general idea behind fz_meta (as in fz_stream_meta, for instance) | 09:14.37 |
| | it's adding dynamic type-unsafe extensions where I'd rather just add plain old code | 09:14.53 |
| | needless (IMAO) interface complexity | 09:15.26 |
| Robin_Watts | Then we should go down the route of adding explicit interfaces and not having fz_meta at all. | 09:19.43 |
| | Does your url fix fix hintaks latest bug? | 09:23.55 |
| tor8 | Robin_Watts: looking now. | 09:26.24 |
| | Robin_Watts: they open, but don't render (since we don't use DroidSansFallback for CJK text in our epub yet) | 09:27.32 |
| Robin_Watts | ok. | 09:28.14 |
| tor8 | it just shows the punctuation and blanks where text should be | 09:28.28 |
| | so I wouldn't close it yet, but it does fix the "crash" when opening | 09:28.47 |
| | okay, I've reworded the fz_meta comment in the header. do you want to rename the function as well? | 09:29.57 |
| | Robin_Watts: hm. if I change html-font to always load DroidSansFallback, we get CJK text but the line breaking fails... | 09:44.13 |
| Robin_Watts | fz_get_metadata ? | 09:44.14 |
| tor8 | fz_lookup_metadata maybe? | 09:44.26 |
| Robin_Watts | or lookup, yes. | 09:44.35 |
| tor8 | ah, the source text has no space characters | 09:44.45 |
| Robin_Watts | according to naming.txt, lookup returns a value or borrowed pointer. | 09:45.45 |
| | we're passing a buffer in, so I guess lookup is fine. | 09:45.59 |
| tor8 | yeah, the other option would be 'find' but we don't return a string that needs to be freed | 09:46.31 |
| | Robin_Watts: okay, amended commit on tor/master | 09:54.10 |
| | I have not tested it yet on win32 and android | 09:54.23 |
| | still wrestling with the most recent google SDK/NDK insanity | 09:54.46 |
| Robin_Watts | looks plausible. | 09:55.17 |
| tor8 | http://bugs.ghostscript.com/show_bug.cgi?id=695918 looks bad :( | 09:56.20 |
| | I'm guessing something's used printf rather than fz_fprintf? | 09:57.01 |
| Robin_Watts | yeah. | 09:57.16 |
| paulgardiner | I'm running into problems trying to build MuPDF for iOS. "Undefined symbols for architecture x86_64" _main | 09:57.22 |
| Robin_Watts | That would be an ecumenical matter. | 09:57.43 |
| paulgardiner | Drink!! | 09:58.01 |
| Robin_Watts | tor8: In mudraw, line 1150 | 09:58.58 |
| | should be: #if defined(_WIN64) || defined(_WIN32) | 09:59.09 |
| | We don't have a context there, so can't call fz_printf. | 09:59.26 |
| | and we can't call it while we have a context, or the numbers would be wrong. | 09:59.41 |
| tor8 | you forgot the morning prayer! 5 "hail steve"s and 12 flagellations before lunch. then I'm sure it'll build. | 10:00.10 |
| Robin_Watts | oops. That's wrong too. | 10:00.51 |
| | #if defined(_WIN64) | 10:01.10 |
| | #define FMT "%Iu" | 10:01.12 |
| | #elif defined(_WIN32) | 10:01.14 |
| | #define FMT "%u" | 10:01.16 |
| | #else | 10:01.18 |
| | #define FMT "%zu" | 10:01.19 |
| tor8 | Robin_Watts: I was just going to say | 10:01.20 |
| Robin_Watts | #endif | 10:01.21 |
| | Can I leave that with you? | 10:01.39 |
| tor8 | Robin_Watts: sure. | 10:01.45 |
| Robin_Watts | I'm stuck in http oauth2 madness :( | 10:01.47 |
| paulgardiner | I'm goint to have to give up. May be some XCode 6.3 strangeness | 10:15.19 |
| Robin_Watts | paulgardiner: Ask Joseph. | 10:15.42 |
| | he did the 64bit stuff for mupdf ios, I think. | 10:15.52 |
| | Actually... did that ever get finished? He mentioned it the other day. | 10:16.04 |
| tor8 | Robin_Watts: okay, I'm finally up and running with android and I get crashes on non-pdf documents. | 10:42.31 |
| Robin_Watts | tor8: ok... probably something is not checking the return value of pdf_specifics or something. | 10:43.12 |
| tor8 | yeah | 10:43.15 |
| | pdf_js_supported | 10:43.21 |
| Robin_Watts | Log is your friend. | 10:43.30 |
| tor8 | indeed. adb logcat gave me enough of a stack trace to figure out where it crashed :) | 10:44.10 |
| | Robin_Watts: you know what would be extra sweet? if the android app knew to call fz_layout_document with the screen aspect ratio :) | 10:45.18 |
| Robin_Watts | Does it even know about epub documents at all? | 10:45.47 |
| tor8 | I fixed that bug as well | 10:46.06 |
| Robin_Watts | tor8: oh, cool. | 10:46.12 |
| tor8 | the ChoosePDFActivity was looking at file extensions | 10:46.13 |
| Robin_Watts | perhaps we should set the screen aspect size (or aspect ratio) in the fz_context ? | 10:46.35 |
| tor8 | I still don't know why OI File Manager won't open XPS and EPUB documents in mupdf though | 10:46.39 |
| | Robin_Watts: you don't want that on desktop viewers though | 10:47.01 |
| | and ideally we want 2 side-by-side pages in landscape mode on the mobile viewer for epub at least | 10:47.25 |
| Robin_Watts | tor8: No, but it could be the default if no size/aspect ratio is given ? | 10:47.32 |
| tor8 | or maybe 2 side-by-side pages always if they fit? | 10:47.36 |
| Robin_Watts | tor8: Do we? | 10:47.48 |
| tor8 | we don't, but it would be nice | 10:47.59 |
| Robin_Watts | Would we not prefer a single page with wide lines ? | 10:48.01 |
| tor8 | I certainly would not. but that's because I hate wide lines. | 10:48.15 |
| | I guess it would depend on the actual width | 10:48.34 |
| | for phones I'd imagine wide lines would be good | 10:48.42 |
| | but not for actual tablets | 10:48.47 |
| | depends on the font size as well, I gather | 10:49.00 |
| Robin_Watts | I'd suggest that we go for wide lines until such time as we support 2 up page mode. | 10:49.03 |
| tor8 | it will cause problems when rotating the device though | 10:49.26 |
| Robin_Watts | And once we support that, the viewer could set the default size/aspect ratio to be such that 2 pages will fit. | 10:49.31 |
| tor8 | it'll need to relayout and then we might lose the page position. not sure we can cope with rotation changing the number of pages. | 10:49.48 |
| Robin_Watts | tor8: When the device rotates, the pages should (ideally) reflow. | 10:49.54 |
| | tor8: All this sounds like future work. | 10:50.02 |
| tor8 | it does. none of this is in the scope for the 1.7 release. | 10:50.11 |
| Robin_Watts | but getting the aspect ratio to match the screen might be? | 10:50.18 |
| tor8 | except maybe seeding the original layout size | 10:50.26 |
| | to match the screen in portrait mode | 10:50.33 |
| Robin_Watts | yeah. | 10:50.37 |
| tor8 | Robin_Watts: okay, I have it laying out in the screen size at the time of launch | 11:17.30 |
| | but no relayout when rotating | 11:17.34 |
| | going to see if I can add that after lunch | 11:17.41 |
| Robin_Watts | tor8: ok. | 11:17.45 |
| | Might it be better to always lay out in portrait mode? For now at least? | 11:18.15 |
| tor8 | the screen decorations make it impossible to tell the portrait screen size when in landscape mode, and vice versa | 11:18.17 |
| Robin_Watts | hmm. ok. | 11:18.30 |
| Robin_Watts | runs | 11:18.37 |
| tor8 | Robin_Watts: ugh. nastiness ensues... | 13:03.39 |
| | the page number is saved across the configuration change, but the page numbering will channge | 13:03.57 |
| | the cached page bitmaps are the wrong size | 13:04.05 |
| | and when flippig pages after a rotate, sometimes the image view widgets are the wrong size, but the bitmap has been re-rendered for the new size | 13:04.48 |
| Robin_Watts | tor8: The cached bitmaps should be invalidated. | 13:10.23 |
| | paulgardiner ? | 13:10.26 |
| paulgardiner | Right: latest source built for iOS, the share button causes a crash unless there are unsaved changes. I'll open a bug. Is that a blocker? | 13:20.45 |
| Robin_Watts | paulgardiner: If there is a simple fix... | 13:53.26 |
| | mvrhel_laptop: Morning | 13:53.37 |
| | mvrhel_laptop: I spotted something with gsview at the weekend. | 13:53.45 |
| | If you have a landscape file, you can't print it to a portrait printer. | 13:54.00 |
| mvrhel_laptop | Robin_Watts: oh | 14:09.11 |
| | ok thanks | 14:09.15 |
| | I am battling with this f***ing vertical scroll. | 14:09.27 |
| Robin_Watts | yeah, sorry. | 14:10.06 |
| | Windows apps generally suck massively at getting their scrollbars right. | 14:10.22 |
| mvrhel_laptop | an issue is that as I zoom in or out, pages that are out of view get delayed in their binding update of the scroll if I let wpf do everything | 14:10.24 |
| | yes I can see why | 14:10.32 |
| henrys | Robin_Watts: on windows right, the printing stuff is different on linux and mac, it might work there? | 14:11.00 |
| Robin_Watts | yes, I've only tested windows. | 14:11.23 |
| mvrhel_laptop | right it is different. I will take a look at the landscape issue. That should be a simple fix. | 14:11.37 |
| | I do need to do a fix to account for printable area I did notice too | 14:11.48 |
| | I need to do some refactoring of the code to when the dust settles | 14:12.30 |
| | s/to/too/ | 14:12.35 |
| paulgardiner | Fixed it | 14:13.16 |
| tor8 | paulgardiner: is there a quick call to invalidate all of the cached pages and views from MuPDFActivity? | 14:13.46 |
| | when I rotate all the EPUB document pages will change size (and the page count differs as well) | 14:14.08 |
| | I've made the page count save/restore in the SharedPreferences be based on a percentage to handle the first part | 14:14.36 |
| paulgardiner | I think you may be able to just call invalidateLayout | 14:14.48 |
| tor8 | paulgardiner: mDocView.invalidate() doesn't work as expected | 14:19.39 |
| | or did you mean some other function? | 14:19.45 |
| paulgardiner | invalidateLayout, I think | 14:20.09 |
| tor8 | grep can't find any call like that | 14:20.18 |
| paulgardiner | It's an Android method | 14:21.22 |
| tor8 | the page count in the scrubber also doesn't update | 14:21.40 |
| | I guess there are a lot of assumptions in the code that the page sizes and numbering will never change :( | 14:21.54 |
| paulgardiner | Assuming it exists at all and I haven't made it up | 14:22.28 |
| tor8 | invalidateLayout sounds iOS-ish | 14:23.01 |
| | google for "android invalidateLayout" returns nothing | 14:23.19 |
| Robin_Watts | http://www.bbc.co.uk/news/world-asia-32297367 | 14:23.39 |
| | actually, you might want not to look at that until after the meeting :) | 14:23.53 |
| paulgardiner | Two commits on master when someone has a chance | 14:24.00 |
| fredross-perry | morning | 14:25.37 |
| Robin_Watts | Morning fredross-perry | 14:26.49 |
| henrys | Robin_Watts: great that's like bringing the puzzles to the in-person meetings | 14:26.51 |
| paulgardiner | Morning fredross-perry | 14:27.17 |
| fredross-perry | I think Cheryl, Albert and Bernard must be on a train leaving Chicago⦠| 14:27.55 |
| paulgardiner | tor8: I should have said "requestLayout" | 14:27.58 |
| Robin_Watts | paulgardiner: Both look good to me, but tor8 should check the makefile one. | 14:28.15 |
| paulgardiner | Not that I'm sure that it'll work, but it's the call I was thinking of | 14:28.32 |
| | Robin_Watts: thanks | 14:28.35 |
| marcosw | Robin_Watts: that problem isn't hard. not sure why thousands of Singaporeans were stumped | 14:29.49 |
| | (got my comment in before the meeting) | 14:29.57 |
| paulgardiner | ReaderView::refresh looks interesting too | 14:30.02 |
| Robin_Watts | marcosw: Depends on the ages of the singaporeans. | 14:30.12 |
| henrys | mvrhel_laptop: shall we start with gsview? | 14:30.27 |
| | mvrhel_laptop: what's left to do? | 14:30.36 |
| fredross-perry | I am working through some feedback from mvrhel_laptop that should take ma another day or so. | 14:31.05 |
| | *me* | 14:31.17 |
| Robin_Watts | mvrhel_laptop has to finish burning the bill gates voodoo doll to get the vertical scroll to work sanely. | 14:31.29 |
| rayjj | I've heard that if you bury a statue of Bill Gates upside down in your front yard, things will work better ;-) | 14:32.20 |
| henrys | I was going to bring up the dreaded language switching. It's priority has gone down but I think it is something we want to keep pushing on. | 14:32.26 |
| chrisl | I've been dipping into it as I have time, but things keep getting in the way.... | 14:33.01 |
| henrys | but I can put it off for a week or so until we get through at least the mupdf release. Up to you guys. | 14:33.04 |
| chrisl | It hasn't been forgotten | 14:33.10 |
| mvrhel_laptop | henrys: I have almost all the issues fixed that Robin_Watts and kens found | 14:33.15 |
| | except the vertical scroll issues | 14:33.27 |
| | and the landscape print issue now | 14:33.33 |
| | I have things in pieces now working on the vertical scroll | 14:33.48 |
| rayjj | henrys: by bringing up l-s are you trying to get chrisl to work harder on cust 532 performance issues ? | 14:33.49 |
| mvrhel_laptop | I did have a question for marcows | 14:34.08 |
| | marcosw | 14:34.12 |
| henrys | chrisl, rayjj : I really would like to push back on the customer to get some tools. It can be approached from the top, from Miles to the director. What do you think? | 14:34.29 |
| rayjj | mvrhel_laptop: what's up with landscape printing (besides that it doesn't work)? | 14:34.37 |
| mvrhel_laptop | rayjj: I dont know | 14:34.45 |
| | I have not looked at it yet | 14:34.50 |
| chrisl | henrys: it's not like we haven't tried - over, and over...... | 14:34.52 |
| mvrhel_laptop | Robin_Watts just told me 5 minutes ago | 14:35.00 |
| Robin_Watts | rayjj: The file is printed without being rotated. | 14:35.08 |
| marcosw | mvrhel_laptop: yes? | 14:35.12 |
| mvrhel_laptop | so bug Bug 695845 | 14:35.18 |
| Robin_Watts | So a landscape file prints and you lose the right hand side. | 14:35.26 |
| mvrhel_laptop | did we ever hear back from the customer | 14:35.29 |
| | we were waiting to see if they were going to move to a more recent version | 14:36.04 |
| rayjj | henrys: I agree that tools would be nice. The problem is that their build system is *really* fragile and when building for the target they can't get a prof or debug build out it seems | 14:36.08 |
| mvrhel_laptop | If I recall from the staff meeting | 14:36.12 |
| kens | henrys I had occasion to look at Tesseract over the weekend. There are problems with us doing anything with it, at least as far as Ghostscript is concerned. | 14:36.44 |
| henrys | marcosw: I'd like to take henrysx6 off the list of available cluster machines, it's showing it's age with problems at high load, the mac is fine. | 14:36.52 |
| chrisl | rayjj: FWIW, I don't really think that's an excuse..... | 14:37.08 |
| marcosw | henrys: np, we have enough machines that it's disappearance will not be noted. | 14:37.21 |
| | mvrhel_laptop: I did hear back, I'll update the bug | 14:37.31 |
| henrys | kens: oh what's that? | 14:37.33 |
| mvrhel_laptop | marcosw: ok great | 14:37.45 |
| | I think | 14:37.48 |
| rayjj | chrisl: I know. Mostly the people that have the skills to put it all together are either on other priority projects (always) [Edwin] or don't work there [one of us] | 14:38.17 |
| henrys | Robin_Watts: you said you wanted to write up an api for the language swtich stuff, but it looks like you are pretty busy now. Do you want to hold off on that, or do you want a break from what you are doing? | 14:38.52 |
| tor8 | paulgardiner: nope, that didn't do it either :( | 14:38.58 |
| Robin_Watts | henrys: Did I? | 14:39.03 |
| rayjj | I still think a database of glyph outlines is the way to go to recognize glyphs | 14:39.06 |
| Robin_Watts | I said that I thought whoever was doing the language switch stuff should start with an API definition. | 14:39.27 |
| kens | henrys its written in C++< secondly it requires Leptonica, whic can't be built except on a Linux platform (or we would need to write a new maekfilefor it). I suspect that the format Tesseract uses to maintain shapes is Leptonica's PIX format. It woudl be hard to decompose glyphs into that format as glyphs are often overlappign discrete sections, not a single fill | 14:39.29 |
| paulgardiner | tor8: which? refresh or requestLayout? | 14:39.35 |
| chrisl | rayjj: I find it utterly baffling that projects where performance is a key component don't put a workable profiler as an "A-1" high priority | 14:39.37 |
| Robin_Watts | and yes, I'd love to. BUT... I'm buried in time critical SOT stuff at the moment. | 14:39.56 |
| henrys | Robin_Watts: oh I did read between the lines you wanted to do it. sorry | 14:40.02 |
| kens | henrys we could render a single glyph and pass tht to Tesseract as a bitmap for identificaion, there's an API for that. | 14:40.09 |
| Robin_Watts | henrys: I would like to be involved, yes. | 14:40.23 |
| tor8 | paulgardiner: requestLayout. trying refresh now. | 14:40.27 |
| chrisl | Robin_Watts: TBH, having looked in a bit more detail, I think extending the Ghostscript API (i.e. what's exposed by the DLL) is not a bad way to go | 14:40.59 |
| rayjj | chrisl: well, for them, they think they do have profile tools (hprof and AQtime) the problem is that they don't work well enough for us to get useful/reliable info | 14:41.00 |
| | kens: isn't Tesseract rather large ? | 14:41.35 |
| chrisl | rayjj: I guess we just have to take a stand, then. | 14:41.45 |
| kens | rayjj I'm not certain, let me look | 14:41.46 |
| tor8 | paulgardiner: neither. | 14:42.18 |
| Robin_Watts | chrisl: It's not the API exposed to the user that worries me, so much as the fact that every language should be bundled up so that it communicates through a strict API. | 14:42.20 |
| | i.e. no secret backdoor communications between parts. | 14:42.32 |
| henrys | kens: I wonder how hard the problem would be for us to write something to derive the character - given we know the font, and we have the outline, it just seems like we are throwing away information and then solving the problem using tesseract. | 14:42.38 |
| kens | tesseract is a 1.5b DLL, Leptonica is a 1.6Mb DLL. | 14:42.42 |
| mvrhel_laptop | marcosw: so this bug is a bit lower priority then.... | 14:42.43 |
| kens | henrys | 14:42.51 |
| rayjj | chrisl: we sort of have, saying "let us know what you find on the target" | 14:43.04 |
| kens | we don't exactly know the outline, at least not the way a OCR package wantsw it | 14:43.05 |
| chrisl | Robin_Watts: well, at the moment PCL and XPS don't have an API.... | 14:43.37 |
| kens | What we have is a path, whch may contain multiple overlappign sections, if you use charpath in PostScript on a font you will see what I mean | 14:43.52 |
| Robin_Watts | chrisl: Right. And they should be refactored so they do. | 14:43.59 |
| rayjj | kens: no, for outlines I don't think we should use an OCR -- just lookup glyph outline md5sums | 14:44.00 |
| kens | rayjj that only works if we know the font already | 14:44.14 |
| | OCR works with different and unknown fonts | 14:44.33 |
| chrisl | Robin_Watts: yes, and I would start that process also with reference to the Ghostscript API | 14:44.38 |
| Robin_Watts | chrisl: Maybe that can be done by reusing the gs... yes, possibly. | 14:44.52 |
| henrys | rayjj: I think we need something fuzzy. | 14:44.57 |
| rayjj | kens: I have 2000 fonts on my Windows systems, and another 1k or so on another system that I haven't bothered to load here | 14:45.35 |
| chrisl | Robin_Watts: I'd rather tweak, extend and massage the Ghostscript API and come up with a common superset for all languages, then the l-s API is a simple, shallow layer on top | 14:45.42 |
| henrys | chrisl: I can easily add something like gsapi to pcl and friends but Robin_Watts said he wanted to reconsider the overall api.... | 14:45.59 |
| Robin_Watts | chrisl: Right. I'm not opposed to that. | 14:46.05 |
| kens | rayjj so add in the thousands of glyphs in CJKX languages, multiple by all the fotns, and how big is your table of sums ? | 14:46.21 |
| rayjj | henrys: well, OCR is certainly fuzzy, but the problem is that it fails unpredictably and fixing a customer problem with a glyph not recognized correctly is a nightmare | 14:46.31 |
| chrisl | Robin_Watts: I'd prefer not to have GS, PCL and XPS all with different APIs, and then have complexity in the l-s layer to tie them all together | 14:46.52 |
| Robin_Watts | The main thing is that we proceed towards the goal of having a common API for each language. | 14:46.56 |
| kens | rayjj the OCR is less likely to fail when presented with a clean bitmap containing *only* the character | 14:46.57 |
| Robin_Watts | chrisl: precisely! | 14:47.01 |
| henrys | fredross-perry: have you had a chance to work on the mupdf problems? not gsview stuff? | 14:47.20 |
| chrisl | henrys: that may be the route we take - I'll get back to you! | 14:47.20 |
| henrys | chrisl: okay | 14:47.29 |
| kens | Also, since this is only really about text extraction/adding ToUnicode to PDF files, its not desperatre if its not 100% I feel. | 14:47.31 |
| Robin_Watts | chrisl: I think we're in total agreement about the goal. | 14:47.34 |
| fredross-perry | no but illl get back to it this week | 14:47.45 |
| | I did start studying iCloud a bit. | 14:48.01 |
| chrisl | Robin_Watts: yes, I think so. It's just my preference is to use the existing DLL as the initial template. | 14:48.26 |
| | But without been totally bound by it..... | 14:48.39 |
| Robin_Watts | And I have no huge objection to that, as long as we don't feel it's cast in stone. | 14:48.46 |
| henrys | I asked folks to work on bug aging problems but I only managed to fix one, the other is hell and I'll have to contact my pharmacist before I get any further ;-) | 14:48.49 |
| rayjj | every Tuesday I dust off norbert's bug 695845 :-) | 14:49.38 |
| | (gives me something to do during the staff meeting) | 14:49.53 |
| kens | rayjj not that bug number I htnk | 14:50.07 |
| | THat's the one Michael was asking about | 14:50.19 |
| chrisl | rayjj: I can't help but feel if we haven't managed to reproduce that yet, we're probably not going to. | 14:50.33 |
| henrys | fredross-perry: you've also got the icloud support stuff should we make a bug report of that? | 14:50.36 |
| rayjj | kens: oops, right. Bug 695568 | 14:50.37 |
| fredross-perry | yes please | 14:51.02 |
| henrys | rayjj: by the way I was looking at the pcl font page you sent from the samsung printer, is that the bitstream set? It's not UFST. | 14:51.40 |
| | rayjj: otoh the postscript fonts do appear to be ufst. Odd. | 14:52.20 |
| | I think we can finish early unless folks have more stuff? | 14:52.37 |
| fredross-perry | ok | 14:52.47 |
| rayjj | henrys: I don't know which fonts they are | 14:52.52 |
| mvrhel_laptop | I am done. Time to work on the voodoo doll some more | 14:53.03 |
| chrisl | henrys: I believe monotype does (or did) customised FCOs if you were willing to pay enough cash..... | 14:53.04 |
| henrys | chrisl: maybe that's it. | 14:53.24 |
| chrisl | henrys: the FCO data that cust 532 use is not the default ones we get with the UFST releases | 14:54.11 |
| | for example.... | 14:54.16 |
| henrys | chrisl: did you look at the font names though, a few of those I know are bitstream fonts... why would monotype use them? | 14:54.53 |
| chrisl | If the customer specified it | 14:55.11 |
| | Depending on the copyright situation, of course | 14:55.32 |
| henrys | oh one more thing please look at Robin_Watts and rayjj writeup of mupdf vs. gs and weigh in, if you want. | 14:56.02 |
| | it's a wiki so you can just jot in stuff. | 14:56.22 |
| marcosw | mvrhel_laptop: your recent commit e8142ce7390e2686 caused several regressions in the nightly test; I presume you are aware of those and I don't need to open a bug, correct? | 14:57.13 |
| Robin_Watts | henrys: mupdf release? | 14:58.39 |
| | The rc1 has had a bit of testing, and it's turned up a few bugs. | 14:59.03 |
| henrys | Robin_Watts: oh right | 14:59.04 |
| Robin_Watts | Tor fixed the crashy android one this morning, and tweaked it so that it can read epubs. | 14:59.30 |
| henrys | Robin_Watts: okay so another week? | 14:59.45 |
| Robin_Watts | And the cockup in the fz_meta stuff has been fixed too with tor reworking that. | 15:00.01 |
| | All that's left is to see if tor can make it cope nicely with rotations etc, I think? | 15:00.22 |
| | so hopefully by the end of the week. | 15:00.32 |
| tor8 | Robin_Watts: I'm inclined to leave the rotation until after the release. It's turning out to be trickier than I expected to coax the android app to do what I want. | 15:01.09 |
| | but I could bash on it some more tomorrow | 15:01.31 |
| | and maybe we should do the same for the iOS then? | 15:01.38 |
| Robin_Watts | tor8: Sounds reasonable. | 15:01.49 |
| tor8 | if I can't get it done by tomorrow, I say leave it until post release | 15:02.09 |
| Robin_Watts | cool. | 15:02.15 |
| tor8 | Robin_Watts: if you got a minute, could you sanity compile and test the fz_meta stuff on windows? | 15:02.39 |
| Robin_Watts | will do. Is it on golden? | 15:02.49 |
| tor8 | no, on tor/master | 15:02.53 |
| | I don't want to push until I know it doesn't break | 15:03.01 |
| | the EPUB fix (sans sizing pages to screen size) is on tor/master as well | 15:03.29 |
| henrys | okay I'll tell miles the 21st or so for the newletter.... | 15:04.34 |
| Robin_Watts | henrys: We can put the newsletter together before then, obviously. | 15:05.00 |
| | tor8: mudraw.c is broken. | 15:05.29 |
| mvrhel_laptop | marcosw: yes. I checked them. they basically are changes since those devices don't do overprint simulation of spot colors any longer | 15:05.39 |
| | we need to open a bug on our rework of that rayjj | 15:06.14 |
| henrys | Robin_Watts: it takes a couple hours to do the newsletter, not worried about that. We can't release the news until we have a release. | 15:06.32 |
| Robin_Watts | tor8: and dloginfoproc has an unused char perm[10] | 15:06.46 |
| rayjj | mvrhel_laptop: I'll open it. Thanks for the reminder | 15:07.07 |
| Robin_Watts | tor8: Instead of #else if defined(_WIN32) you want #elif defined(_WIN32) at the end of mudraw.c | 15:07.43 |
| | yeah, the permissions stuff isn't quite right on windows. | 15:08.35 |
| | tor8: OK, updated commits on robin/master that build/run file. | 15:22.14 |
| tor8 | Robin_Watts: LGTM | 15:23.58 |
| Robin_Watts | tor8: Can I leave them to you to push etc? | 15:24.13 |
| rayjj | mvrhel: (for the logs) I opened bug 695925 and assigned it to me. I made it a P1 cust 532 enhancement since they've definitely asked about it (w.r.t. Altona pages) | 15:24.39 |
| | I have to run an errand. bbiab | 15:24.56 |
| tor8 | Robin_Watts: Yes. | 15:25.17 |
| leot | tor8: I can confirm that the bug regarding url(...) syntax in CSS style is fixed... Thank you very much! | 15:55.49 |
| Robin_Watts | leot: Thanks for the report. | 16:01.04 |
| leot | i changed the status of bug 695922 to "RESOLVED FIXED" (but unfortunately it seems that the link to the commid id is wrong (just s/ghostpdl/mupdf/) :)) | 16:01.57 |
| | thank you again Robin_Watts for your tips | 16:02.07 |
| Robin_Watts | leot: No problem. | 16:02.22 |
| | leot: The crufty hackery in bugzilla to change hashes to point to git.ghostscript.com is mine, and it can't know what repo to point at. | 16:02.53 |
| | So it guesses at ghostscript. | 16:02.59 |
| | You can edit the url from ghostscript to mupdf easily enough :) | 16:03.10 |
| kens | I'm off for a pizaa, goodnight folks | 16:03.51 |
| leot | heh, no problem :) | 16:05.56 |
| tor8 | Robin_Watts: https://www.youtube.com/watch?v=QdDD9ViRZz4 | 16:18.03 |
| Robin_Watts | tor8: W.T.F? | 16:19.48 |
| tor8 | spoken wikipedia... used to be on https://en.wikipedia.org/wiki/Bhutanese_passport but sadly(?) now replaced | 16:20.48 |
| pipitas | Robin_Watts: Are there any special targets to "make" in order to get the mupdf EPUB viewer built from current Git (on OSX Mavericks)? | 16:42.47 |
| Robin_Watts | pipitas: I don't believe so. | 16:43.05 |
| pipitas | Robin_Watts: Or should I direct MuPDF build questions to someone else? | 16:43.05 |
| Robin_Watts | "make debug" or "make release" should do what you want. | 16:43.34 |
| pipitas | Robin_Watts: Hmm⦠my freshly built MuPDF opens only PDFs. When served an EPUB, it parses it as PDF and reports PDF-related errors⦠| 16:44.20 |
| Robin_Watts | tor8: ping | 16:44.52 |
| pipitas | Robin_Watts: Also, "make debug" and "make release" dont seem to be Makefile targets in MuPDF. | 16:45.48 |
| Robin_Watts | Then you aren't up to date. | 16:45.58 |
| | pipitas: Are you using git? | 16:51.29 |
| pipitas | Robin_Watts: Indeed, my last git pull is from last night. New pull just now gave new Makefile targets :) | 16:51.50 |
| Robin_Watts | ok. | 16:52.15 |
| | What is the name of the epub file you are trying to call mupdf on? | 16:52.36 |
| pipitas | It's one I bought, "kofler-pandoc.epub", and I checked if it opens in iBooks (which it does). | 16:55.39 |
| Robin_Watts | pipitas: Ah, so it has DRM? | 16:55.52 |
| | I suspect mupdf will bale out of reading it if it's DRM'd and then fallback to trying it as PDF. | 16:56.21 |
| | Try a non DRM'd one. Or feed it through calibre to remove the DRM :) | 16:56.42 |
| pipitas | Robin_Watts: To be honest, I don't know if it has DRM even | 16:56.52 |
| | Robin_Watts: But last night's MuPDF version had the same problem also with non-DRM EPUBs (self-created with the help of 'pandoc'). | 16:57.40 |
| Robin_Watts | unzip -t kofler-pandoc.epub | 16:58.13 |
| | does it mention rights.xml or encryption.xml ? | 16:58.30 |
| pipitas | I just did a new "make release", then "mupdf my.epub", and the second line says "warning: trying to repair broken xref" indicating it tried to parse it as PDF | 16:58.53 |
| leot | pipitas: can you check the latest version? Or apply that: http://git.ghostscript.com/?p=mupdf.git;a=patch;h=1bc74dac2b251764d373c164e2b5235875f27901 | 16:59.51 |
| Robin_Watts | Try this one: http://www.wumingfoundation.com/italiano/Wu_Ming_Armata_dei_Sonnambuli.epub | 17:00.33 |
| leot | A problem regarding EPUB was fixed few hours ago (and all the PDF I tryed had the url(...) syntax) | 17:00.46 |
| pipitas | No rights|encryption.xml in kofler EPUB (thanks for letting me know about it â so far hadn't explored how EPUB implements DRM) | 17:00.46 |
| leot | s/PDF/EPUB/ # :) | 17:01.05 |
| Robin_Watts | On windows, mupdf opens that file fine now. | 17:02.40 |
| pipitas | Robin_Watts: I had already downloaded the Wu_Mingâ¦.epub last night. It was mentioned in this #channel, and that's what drew my attention to MuPDFs newly acquired EPUB goodness initially. | 17:03.06 |
| Robin_Watts | And does that work for you? | 17:03.21 |
| pipitas | So no, Wu_Mingâ¦epub also doesnt work for my newly-made MuPDF either | 17:03.35 |
| | Let me try something else⦠| 17:04.14 |
| tor8 | Robin_Watts: pong. | 17:05.29 |
| Robin_Watts | tor8, pipitas is complaining that mupdf on macosx isn't opening epubs. | 17:05.50 |
| | The same file opens fine for me on windows. | 17:06.04 |
| tor8 | pipitas: have you tried make clean or make nuke? there may be some stale object and/or library files that could cause havoc | 17:06.26 |
| | the macosx version is the same as the linux and other unixes | 17:07.05 |
| chrisl_away | Wu_Ming_Armata_dei_Sonnambuli.epub works for me, too, on Linux..... | 17:07.37 |
| pipitas | Robin_Watts: Ok, some progress⦠If I'm using "mupdf-x11" I get different messages (this time clearly showing EPUB is parsed as EPUB): | 17:09.19 |
| | > mupdf-x11 kofler-pandoc.epub | 17:09.23 |
| | epub: found root: content.opf | 17:09.23 |
| | epub: found outline: toc.ncx | 17:09.23 |
| | epub: found spine cover.xhtml | 17:09.23 |
| | error: css syntax error: expected keyword after ':' (stylesheet.css:154) | 17:09.23 |
| | mupdf: error: cannot open document | 17:09.23 |
| | > mupdf-x11 Wu_Ming_Armata_dei_Sonnambuli.epub | 17:09.36 |
| | epub: found root: OEBPS/content.opf | 17:09.36 |
| | epub: found outline: OEBPS/toc.ncx | 17:09.36 |
| | epub: found spine OEBPS/Text/content0001.xhtml | 17:09.36 |
| | error: css syntax error: unexpected character (OEBPS/Styles/style001.css:6) | 17:09.36 |
| | mupdf: error: cannot open document | 17:09.37 |
| Robin_Watts | pipitas: What were you using before ? | 17:09.49 |
| pipitas | (2 different errors for 2 different epubs) | 17:10.03 |
| Robin_Watts | pipitas: the second error indicates that you are still not up to date with git. | 17:10.33 |
| | or that if you are, you need to make clean and rebuild, as tor8 said. | 17:11.10 |
| | your git head should be 3fdc712 | 17:11.32 |
| tor8 | pipitas: is the kofler-pandoc.epub available for download somewhere? | 17:11.33 |
| Robin_Watts | tor8: He said he had to buy it, so I'm guessing not. | 17:12.37 |
| | yeah, it's 10 euros from kofler.info | 17:13.36 |
| mvrhel_laptop | whew. finally making some progress on this. I had to rip everything apart and slowly start rebuilding. | 17:13.42 |
| pipitas | tor8: kofler-pandoc.epub I bought from https://kofler.info/ebooks/markdown_pandoc/, and it is in German. So I guess two reasons for you to rather not want to get it for yourself | 17:16.19 |
| | tor8: But I bet if you write to Michael Kofler telling him you work on MuPDF/EPUB support he'll send you one for free⦠:) | 17:17.26 |
| Robin_Watts | pipitas: Can you unzip the epub, and paste us line 154 of stylesheet.css please ? | 17:18.25 |
| | but definitely you can't be up to date, because the second error is the one that was fixed 3 commits ago. | 17:19.05 |
| pipitas | Lines 154-156 of the stylesheet.css for the kofler epub are these: | 17:21.48 |
| | h1.title::before, h2.author::before { | 17:22.17 |
| | content: ""; | 17:22.17 |
| | } | 17:22.17 |
| Robin_Watts | I bet it's the :: that's the problem. | 17:23.44 |
| | in fact, I bet ::before means something special in epub and we don't support it. | 17:25.31 |
| pipitas | won't bet against Robin_Watts here⦠| 17:25.43 |
| Robin_Watts | Try editing the ::before out and see if it gets further? | 17:26.12 |
| | but actually, you should figure out why Wu_wossname doesn't work. | 17:26.31 |
| pipitas | It may as well be that the ::before is a bug and that it should be :before | 17:27.19 |
| Robin_Watts | http://stackoverflow.com/questions/10267643/what-does-and-do-in-css | 17:28.33 |
| pipitas | Actually, ::before is part of standard CSS, not EPUB specific. http://www.w3schools.com/cssref/sel_before.asp | 17:28.59 |
| Robin_Watts | So ::before is correct. It is something we should at least accept even if we don't support it. | 17:29.11 |
| | One for tor8. | 17:29.16 |
| pipitas | my mupdf-x11 now opens the Wu_â¦.epub (after making clean and rebuilding) | 17:30.29 |
| | Robin_Watts: tor8: thanks for the help | 17:30.51 |
| tor8 | it looks like non-standard CSS syntax | 17:31.01 |
| Robin_Watts | tor8: No, ::before and ::after are both valid css. | 17:31.18 |
| | css 3, I think. | 17:31.21 |
| | they are 'special'. | 17:31.25 |
| tor8 | well... css3 in not part of epub2 | 17:31.38 |
| Robin_Watts | tor8: Can we tolerate it easily? | 17:31.54 |
| tor8 | :before and :after are standard css2.1 syntax and those we parse properly | 17:31.55 |
| Robin_Watts | pipitas, what were you trying to use before mupdf-x11 ? | 17:32.15 |
| tor8 | Robin_Watts: we could extend our css parser to handle (and possibly discard) css3 selector syntax | 17:33.03 |
| Robin_Watts | tor8: that would seem to make sense. | 17:33.14 |
| tor8 | but there is a lot of new crap in css3 | 17:33.37 |
| Robin_Watts | possibly ::before is just a 'tidied' version of :before | 17:33.46 |
| pipitas | Robin_Watts: it was also mupdf-x11, but a symlink named mupdf pointing to the older compilation of mupdf-x11 | 17:33.55 |
| tor8 | "This :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements." | 17:34.29 |
| | so I would hazard that yes, ::before is a tidied version of :before | 17:35.43 |
| | because the pseudo-classes in css2 are a bit wonky | 17:36.07 |
| | a:hover and a:before have completely different behaviour | 17:36.18 |
| Robin_Watts | tor8: right. Do we support :before, or just tolerate it? | 17:36.59 |
| tor8 | just tolerate it | 17:37.04 |
| Robin_Watts | So can we easily tolerate ::before ? | 17:37.12 |
| tor8 | as in, we parse it into our rules etc, but nothing in the formatter acts on it | 17:37.22 |
| | we could easily add :: syntax to the parser and handle it in our css rules | 17:37.44 |
| | but EPUB producers really shouldn't be using non-standard versions of specifications :( | 17:41.16 |
| | still, I expect everyone is going to be as sloppy as internet explorer when it comes to anything that smells like HTML | 17:41.48 |
| | we might be better off trying to recover from parse errors | 17:42.04 |
| Robin_Watts | yeah. | 17:42.43 |
| tor8 | Robin_Watts: there's a one-line temporary patch fix on tor/master which should work well enough for now | 17:42.59 |
| | but once we start seeing css3 selectors like :not(:nth-child(3)) we're going to have to think again | 17:43.26 |
| Robin_Watts | can't argue with that. | 17:43.26 |
| | push that, and then pipitas, can you pull it and test again? | 17:43.51 |
| tor8 | pushed. now for dinner though. | 17:44.30 |
| Robin_Watts | pipitas: OK, it should be there for you to test now. | 17:51.52 |
| | Does the book open properly now? | 17:51.58 |
| | tor8: We should probably start to put some .epubs into the mupdf tests. | 18:05.28 |
| pipitas | Robin_Watts: Moment⦠| 18:05.36 |
| | The problem with line 154 is fixed. But now I'm getting a different error: | 18:06.37 |
| | "error: css syntax error: expected selector (stylesheet.css:188)" | 18:06.37 |
| | The stylesheet.css file has these lines 188-190: | 18:06.37 |
| | tr:nth-child(even) { | 18:06.37 |
| | background-color: #f8f8f8; | 18:06.37 |
| | } | 18:06.37 |
| Robin_Watts | pipitas: Right, tor8 mentioned selectors like that above. | 18:07.08 |
| | Our target is to support epub 2.0 | 18:09.33 |
| | epub 2.0, AIUI, uses css 2.0 | 18:09.42 |
| | There is a newer version of epub, but (again AIUI, and I could be wrong), that's moving increasingly towards fixed format. | 18:10.10 |
| | We aren't aiming to use that. | 18:10.22 |
| | Now, it looks like your epub is using css 2.0 | 18:10.48 |
| | s/2.0/3.0/ | 18:10.56 |
| | so consequently we're tripping over ourselves. | 18:11.12 |
| | We should probably try to at least ignore stuff that we don't understand and continue. | 18:11.27 |
| pipitas | Robin_Watts: My guess is that EPUB v3 will become more popular+widespread than v2 (dunno if it isnt more widespread already) | 18:34.50 |
| tor8 | EPUB 3 is referencing non-final W3C specifications ... it's a moving target. a bad idea all round. | 18:38.40 |
| Robin_Watts | tor8: how hard is it to tolerate selectors like :nth-child(even) ? | 18:39.34 |
| tor8 | pipitas: what does the content.opf xml tag <package ... version=""> list for version number? | 18:40.18 |
| Robin_Watts | I guess when we hit an unexpected '(' we could ignore the rest of the string until we meet a balancing ')' ? | 18:40.30 |
| tor8 | Robin_Watts: I'm working on a patch to catch syntax errors in css rules and skip past to the next '}' token | 18:40.48 |
| Robin_Watts | tor8: Ah, ok. | 18:40.57 |
| tor8 | which should let us catch and continue parsing past most kinds of errors | 18:41.00 |
| | parsing css3 style selectors properly would take me a day or two | 18:42.15 |
| | but this fix should probably go in anyway | 18:42.26 |
| | Robin_Watts: commit on tor/master for css parsing resilience | 18:46.18 |
| qqz | in what unit do I need to give -dDEVICEWIDTH and -dDEVICEHEIGHT? | 18:54.11 |
| | is it independent from the -dDEVICEX/YRESOLUTION or not? | 18:54.29 |
| | I tried to give the size in bp basis points i.e. 1/72 inch units but ended up with a far too small page size | 18:55.32 |
| | what can I do? | 18:55.50 |
| | wanna use gs to scale pdf pages | 18:56.10 |
| | and just another question: should the -gXxY preserve the aspect-ratio? | 18:57.03 |
| | will that result in sth. that is not scaled as much as given by the parameter if it should try to preserve aspect ratio. | 18:58.09 |
| | ?? | 18:58.19 |
| rayjj | qqz: yes, gWWWxHHH will preserve the aspect ratrio If you use -dFitPage then the page will be "centered" in the image given by -g with blank areas on the side that needs "padding" to fill the -g area | 19:16.45 |
| | qqz: note that -gWWWxHHH also sets -dFIXEDMEDIA so that the file (be it PS or PDF) does not set a new page size | 19:17.38 |
| | as stated in http://www.ghostscript.com/doc/current/Use.htm | 19:20.20 |
| | -gnumber1xnumber2 | 19:20.21 |
| | Equivalent to -dDEVICEWIDTH=number1 and -dDEVICEHEIGHT=number2, specifying the device width and height in pixels for the benefit of devices such as X11 windows and VESA displays that require (or allow) you to specify width and height. Note that this causes documents of other sizes to be clipped, not scaled: see -dFIXEDMEDIA below. | 19:20.23 |
| | qqz: if you want to specify the page in "points" (1/72 of an inch) use: -dDEVICEWIDTHPOINTS=w -dDEVICEHEIGHTPOINTS=h | 19:21.16 |
| qqz | how can I make ghostscript add margins of specified length? i.e. specify a bounding box? | 19:21.27 |
| rayjj | qqz: and if you use those, don't omit the -dFIXEDMEDIA switch | 19:21.50 |
| Robin_Watts | tor8: if (s && p) return fz_new_css_rule(...) else { free(s) free(p) } ? | 19:23.44 |
| | and the catches that say "fz_warn(ctx, "ignoring stylesheet %s due to parsing errors"....)" should rethrow on non-SYNTAX errors ? | 19:25.17 |
| rayjj | qqz: -dFitPage will always do the "best fit" without margins. It may work with -c "<< /.HWMargins [ left bottom right top ] >> setpagedevice" -f inputfile | 19:26.12 |
| | qqz: but I haven't tried that with -dFitPage. Note that the .HWMargins are floats in 1/72 of an inch (points) | 19:26.14 |
| | qqz: the .HWMargins setpagedevice parameter is documented in http://www.ghostscript.com/doc/current/Language.htm | 19:26.58 |
| tor8 | Robin_Watts: tweaked commit on tor/master | 19:32.41 |
| rayjj | qqz: hmm... I just tried it and I don't think it works (hard to tell, but I used: -r72 -dFitPage=true -g600x900 -c "<< /.HWMagins [ 144 72 144 72 ] >> setpagedevice" -f examples/annots.pdf | 19:32.47 |
| | qqz: and it looks the same as -r72 -dFitPage=true -g600x900 -c "<< /.HWMagins [ 72 72 144 72 144 ] >> setpagedevice" -f examples/annots.pdf | 19:33.07 |
| tor8 | I expect to continue in the face of any errors in style sheets | 19:33.08 |
| rayjj | qqz: and it looks the same as -r72 -dFitPage=true -g600x900 -c "<< /.HWMagins [ 72 144 72 144 ] >> setpagedevice" -f examples/annots.pdf | 19:33.27 |
| Robin_Watts | tor8: You need fz_var(s) and fz_var(p) | 19:33.31 |
| tor8 | so I reworded the message | 19:33.33 |
| Robin_Watts | and I still think you need to free s and p. | 19:33.45 |
| | hmm. Did you push the changes? | 19:34.48 |
| tor8 | the css parsing code leaks on all errors; I'm planning on fixing it using free-lists that get zapped at the top when a document is finished parsing | 19:35.20 |
| Robin_Watts | oh, ok. | 19:35.39 |
| | That's a change in style from the rest of the code... | 19:35.53 |
| tor8 | the fz_vars are unnecessary; they are not used after the catch | 19:36.05 |
| Robin_Watts | tor8: I can't see any changes from when I last looked. | 19:36.43 |
| tor8 | it is... but it should be more robust once implemented... I thought I'd done it but I think I must've been feverishly misremembering while jetlagged | 19:36.46 |
| | Robin_Watts: ah, sorry. missed the -f to push | 19:37.06 |
| | my comments will make more sense once you see the actual code I'm talking about :) | 19:37.38 |
| | I rewrote the if (s) stuff so I wouldn't need to add fz_var | 19:38.06 |
| Robin_Watts | ok, that's fine. | 19:38.25 |
| qqz | rayjj: I have problems to combine the -c "... HWMargins ..." with -sDEVICE=pdfwrite - just wanna put everything into a file also using -dBATCH -dNOPAUSE -dQUIET | 19:38.56 |
| | and perhaps -sOutputFile; or does it need a different setup than the page scaling | 19:39.36 |
| rayjj | qqz: As I said, forget .HWMargins -- it doesn't seem to be compatible with -dFitPage | 19:40.35 |
| qqz | even if I process scaling first and then invoke gs a second time? | 19:41.17 |
| rayjj | qqz: and if you do want to use .HWMargins, it *MUST* be just before the -f inputfile (after the other options) | 19:41.21 |
| qqz | but how can I prevent it from outputting on the screen with this setup?, how would a full command line look like? | 19:43.38 |
| | can I write: gs -sDEVICE=pdfwrite -dBATCH -dQUIET -dNOPAUSE -sOutputFile=out.pdf yourcommandsinafile.ps input.pdf ?? | 19:46.57 |
| | I am not sure what the -c should do; it is not documented in my man page | 19:47.34 |
| | if I do that it apparently has no effect on a raw input file | 19:48.34 |
| rayjj | qqz: OK, so if I spell it correctly -c "<< /.HWMargins [ 144. 72. 144. 72. ] >> setpagedevice" _does_ work, but -dFitPage uses the "raw" page size, so I get a clipped image | 19:49.53 |
| | qqz: sorry, but I have to go, and this stuff isn't working the way I expect (and I implemented some of it). I'll figure out what's up and post it here with your tag (qqz) | 19:53.50 |
| qqz | hmm: http://pastie.org/10092570 | 19:55.25 |
| | rayjj: too bad; thank you for your support | 19:55.41 |
| | anyone else who could try to help me fix this issue | 20:01.40 |
| | unfortunately I am not familiar with the ps - stack mdoe of operation | 20:02.02 |
| | ok found it; just forgot about -f | 20:11.48 |
| | HwMargins seems to crop into the page but how can I actually extend the paper size by a given margin amount? | 20:23.44 |
| | why does it ignore -c '<< /PageSize [ 100 200 ] >> setpagedevice '? | 21:02.52 |
| | if I invoke pdfinfo on it later on it shows me the same page size as before? | 21:03.12 |
| | what if I wanna center existing content into the new page size without scaling it? | 21:03.48 |
| Robin_Watts | qqz: Are you trying to do this for a single file, or for many? | 21:04.59 |
| qqz | for a single file with many pages | 21:05.13 |
| Robin_Watts | qqz: I'd use mupdf. | 21:06.06 |
| | mutool clean -difggg in.pdf out.pdf | 21:06.16 |
| | That will give you an uncompressed version of the file. | 21:06.22 |
| | Then you can hunt through for MediaBox entries in a text editor and update them all as you see fit. | 21:06.40 |
| | That directly changes the size of the pages, without touching the contents. | 21:07.15 |
| qqz | ... and if I add an outermost mediabox? | 21:07.25 |
| Robin_Watts | I don't follow. | 21:07.37 |
| qqz | wanna have anything that will work on any *.pdf | 21:07.43 |
| Robin_Watts | So this isn't a question for a single file then. | 21:07.57 |
| qqz | where is explained what -dUseCropBox/MediaBox/TrimBox/ArtBox will do? | 21:12.38 |
| Robin_Watts | qqz: Are you at all familiar with the pdf specification? | 21:15.22 |
| | That defines what the CropBox, MediaBox,TrimBox, ArtBox are. | 21:15.37 |
| | Once you understand that, it's pretty obvious what -dUseCropBox etc do. | 21:15.56 |
| | Every page in a PDF can have multiple different bounding boxes. | 21:16.28 |
| | The largest is the MediaBox. | 21:16.36 |
| | The others all sit within that. | 21:16.50 |
| | If you want to make the page bigger, then you need to extend the mediabox. | 21:17.18 |
| | That's not something you can easily do with gs (unless you want to get into postscript programming, and trust me, you don't want that). | 21:17.41 |
| | MUCH easier to do it by manipulation of the existing PDF file. | 21:17.58 |
| | mupdf is the way to go there. | 21:18.04 |
| qqz | is there a nice introduction to it? | 21:19.22 |
| | it will somehow need to work with any pdf I get | 21:19.36 |
| | I blieved that there were just a few postfix operations to do that | 21:20.01 |
| | why is it so complicated? | 21:21.04 |
| | it simply can`t believe that it isn`t possible to set the MediaBox | 21:48.39 |
| | what does mupdf do? simply nothing but to show a page | 21:52.24 |
| | Forward 1 day (to 2015/04/15)>>> | |
IRC Logs