| | <<<Back 1 day (to 2013/01/21) | 2013/01/22 |
| ray_laptop | looks like marcos has been busy vetting the release for SEGV problems. I got (yet another) MT rendering bug. Who wants to bet it is color management related :-) | 05:29.54 |
| deleet | Robin_Watts: ping | 09:24.05 |
| | hey paulgardiner | 09:40.53 |
| paulgardiner | hey | 09:41.01 |
| deleet | I got a chance to try out the app on the tablet again | 09:41.20 |
| paulgardiner | Any luck? | 09:42.36 |
| deleet | basically, to display a 1920x1080 bitmap uses up to 40 MB heap (when a single one should use about 8 MB) .. so that means that you're handling 5 of them at once (between zooming and etc). The app doesn't crash but with a max heap of 60 MB, using 40 just for the PDF display is, imo, not sufficient | 09:43.04 |
| | the bitmaps will eventually be freed however so the memory is 'eventually' restored once the GC runs a few times | 09:43.43 |
| | this shows the behavior, GC_CONCURRENT is the GC calls to release memory that has no further references, GC_FOR_ALLOC is pre memory allocation GC: http://pastie.org/private/exkngshuj4epaulanqgkya | 09:44.37 |
| | also note how it frees up 8000k of memory (a full screen bitmap) a few times | 09:45.03 |
| | finally, this is not visible on simple text PDF's, it would have to be one with images and etc (I imagine the lib performs some optimizations there) | 09:45.32 |
| paulgardiner | Well, good that it doesn't crash now. I'm not following everything you say. Currently we use 4 screen-sized bitmaps if you are zoomed in on a page other than the first or the lastm, plus another for any update of those 4. | 09:49.26 |
| | But that's independent of document content. | 09:49.49 |
| deleet | 4 meaning, previous page, current page, zoomed in current page, next page? | 09:52.07 |
| paulgardiner | Exactly. | 09:52.34 |
| deleet | I see. That makes sense, however, not all devices will allow you to do this, especially if you bundle MuPDF with your application and there's other things happening in the background. In those cases it will definitely crash since you're taking up most of the heap | 09:54.16 |
| paulgardiner | I'm also still not understanding why we needed the recycle calls at all. We were already avoiding holding references to bitmaps other than the 5. | 09:55.41 |
| deleet | because when you zoom, you're allocating another bitmap. that allocation will happen before the previous zoomed bitmap is released unless you call recycle(), so now you have two zoomed bitmaps in memory, which makes that 6 bitmaps now | 09:57.13 |
| paulgardiner | 3 of our bitmaps don't need to be full resolution, especially on a retinal display. I'll talk to Robin about that later. That was my planned suggestion if the lastest change didn't work, | 09:57.28 |
| deleet | zoom again in a short period of time and you may have 7, depending on how often / fast your GC ran | 09:57.32 |
| paulgardiner | The new temporary one you get when zooming is the 5th I mentioned. | 09:58.18 |
| deleet | okay, so change 6/7 to 5/6 | 09:58.36 |
| paulgardiner | Surely GC is forced whenever an allocation fails. | 09:58.50 |
| deleet | it is but non-recycled bitmaps may not be GC'd at that point, even if there's no references to them, because GC on bitmaps is executed through finalizers | 09:59.24 |
| paulgardiner | I mean the OS should try to allocate; if it would fail, gc and try again. | 09:59.27 |
| deleet | which usually take a few GC runs to actually clear the whole thing | 09:59.44 |
| | It does, once | 09:59.57 |
| paulgardiner | Aaah! | 10:00.13 |
| deleet | if it fails a second time the app crashes with an out of memory exception | 10:00.15 |
| paulgardiner | Oh. So we good catch the exception and retry a few times. | 10:00.50 |
| deleet | it's a dalvik level exception, can't catch that | 10:01.31 |
| paulgardiner | Using recycle sounds cleaner but it is difficult to identify the exact time to call it | 10:01.36 |
| deleet | yeah I understand it might be hard to find the correct place to call it | 10:02.14 |
| paulgardiner | Well, having said that, I'm going by Robin and my last discussion. I haven't seen his latest version. He may have had an epiphany. | 10:03.49 |
| | Robin had previously suggested using explicit reference counting. I'm starting to thing that may be the best way. | 10:04.50 |
| | Independent of that we might reduce the size of some of the bitmaps for very high res displays. | 10:05.41 |
| deleet | That would probably be the safest bet, yes | 10:05.56 |
| paulgardiner | gtg biab | 10:06.25 |
| Robin_Watts | Morning. | 10:18.58 |
| paulgardiner | deleet: I remember what I've been meaning to mention to you: actually we'd prefer not to be churning bitmaps at all. On our first attempt at this, we tried just updating the bitmap currently set for the image view and then calling invalidate on that view, but for devices with hardware assisted graphics, the screen didn't update. | 10:19.10 |
| Robin_Watts | The number of bitmaps used is completely independent of content. | 10:19.39 |
| paulgardiner | I guess we needed to trigger the updated bitmap data to be reuploaded as a OGL texture but we never found out how. | 10:20.01 |
| Robin_Watts | So if you're seeing it vary with content, then it's not the bitmap size at play. | 10:20.04 |
| paulgardiner | If we found out how to do that, many of these problems disappear | 10:20.30 |
| Robin_Watts | paulgardiner: I think that's a red herring though, as ultimately we still need to hold 1 more bitmap for each active render. | 10:20.55 |
| paulgardiner | Robin_Watts: I thought not | 10:21.25 |
| | I still think not... but I may be wrong. :-) | 10:22.06 |
| Robin_Watts | We hold 1 bitmap each for current/prev/next page at thumbnail size. | 10:22.36 |
| | Plus 1 for the 'current hq render of the current page'. | 10:22.52 |
| | SO when we want to redraw the current hq render, we still need a new bitmap. | 10:23.11 |
| paulgardiner | Just draw to the current one. | 10:23.26 |
| Robin_Watts | If we get a redraw of the screen in the meantime, we'll see a partially drawn section on the screen. That's not acceptable. | 10:24.09 |
| paulgardiner | In any case, even if it saves no bitmaps, all the complication with bitmap holder the old problem with async tasks creating huge numbers was due to work arounds to avoid the problem of not being able to reuse bitmaps | 10:24.28 |
| | Robin_Watts: we wont because curently we cant make the screen show the update even at the end after an invalidate call | 10:24.55 |
| Robin_Watts | So you're relying on the opengl 'delay' ? | 10:25.37 |
| paulgardiner | I don't know. I'd need to look back at the old version. All I'm saying is the first version of this was really simple, and all the complcations introduced sinces have been because of not being able to get the screen to update after writing to the current bitmap, so it would be useful to know how to do that if deleet happened to know. | 10:28.45 |
| Robin_Watts | And the worry I have, is that if we start to rely on the delay in going from bitmap -> texture, and that delay disappears (possibly because of a system update or something), we'd need to revisit it again. | 10:30.05 |
| | While changing *might* give us simpler code, I don't believe it can reduce the number of bitmaps we have to hold at any given point. | 10:30.38 |
| | (and some early android devices might not have the delay at all) | 10:30.52 |
| paulgardiner | Yeah, you'd think so, but it was the earlie devices for which the non-churning version worked. I used to have a test "churn only if harware assisted" | 10:33.02 |
| Robin_Watts | The problem would get even worse if we get cancelling of render tasks working. | 10:34.00 |
| | cos then our one and only bitmap would have a section of it that was partially rendered. | 10:34.24 |
| paulgardiner | Sounds like a good argument to me, but it did work. It worked well on just not on hardware assisted graphics. I'm not saying it's the way to go, but just lets not rule it out when we currently have a horrendously complicated mechanism (which I more than anyone else take the blame for :-) ). Admittedly I haven't seen your latest changes, but when we last spoke we were both struggling to... | 10:38.40 |
| | ...reason that we were handling all cases, especially with all the concurency | 10:38.42 |
| deleet | paulgardiner: did you try destroyDrawingCache? | 10:41.42 |
| paulgardiner | :-) No. I don't think I did. | 10:42.01 |
| | ... although my memory isn't that good, so I might have. | 10:42.22 |
| deleet | that's one of the things that may cause your display not to update .. there's a bunch of others though | 10:42.25 |
| Robin_Watts | paulgardiner: New patch pushed to my repo. | 10:42.26 |
| paulgardiner | Robin_Watts: ok ta. I'll have a look now | 10:42.43 |
| deleet | Robin_Watts: this .apk on your dir, is that with my patch or without the recycle() calls? | 10:42.53 |
| Robin_Watts | deleet: The apk that I mailed you the link to is built from http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=b9b12fb56e0337fd068ad5bf810914ffdc5a7e7a | 10:44.01 |
| | It DOES recycle (in almost all cases). | 10:44.13 |
| | It just doesn't free a bitmap before allocating the next one. | 10:44.25 |
| deleet | Robin_Watts: I don't think it recycles because you never call setBm(null)? | 10:46.38 |
| | which would explain the results I'm seeing with the log I posted aboce | 10:47.01 |
| | *above | 10:47.04 |
| Robin_Watts | deleet: We do call setBm(null). | 10:47.08 |
| | We also call setBm(bm); which has the effect of recycling the old one once the new one is safely in place. | 10:47.40 |
| | You need to look at the entire source, not just that last patch. | 10:48.02 |
| deleet | ah k | 10:48.06 |
| | in any case, the crash is gone but the problem remains of very high memory usage (40 MB out of 60 MB total) | 10:49.26 |
| Robin_Watts | deleet: Right. We will continue to look for ways to improve that. | 10:49.48 |
| deleet | so for people bundling the library on smaller heap phones, the remaining heap will be much smaller | 10:49.54 |
| Robin_Watts | deleet: No, the problem will not be there on phones, as the screen sizes will be smaller! | 10:50.33 |
| paulgardiner | smaller heap phones will likely have lower res screens, although as Robin_Watts ways it is something we wish to address | 10:50.39 |
| deleet | imagine a G1 with 16 MB .. you'd use up 10 mb, be left with 6 for your application | 10:50.52 |
| Robin_Watts | The easiest way to make a dent in this, is to limit the 'thumbnail' size, probably. | 10:51.08 |
| paulgardiner | In many ways it is good to stop the crashes while maintaining the high usage thus confirming we are recycling where possible. | 10:51.16 |
| Robin_Watts | We could hold prev/current/next bitmaps at 1/4 real size. | 10:51.49 |
| paulgardiner | Robin_Watts: my thoughts exactly | 10:52.04 |
| | Robin_Watts: I think we should go with your current patch and keep this on the back boiler for improvements later. | 10:53.26 |
| Robin_Watts | OK. I'll commit that now then. | 10:53.36 |
| paulgardiner | deleet: very much appreciate your help with this. I think we will be able to reduce the memory usage. | 10:54.25 |
| Robin_Watts | deleet: indeed, many thanks. | 10:54.52 |
| deleet | you're welcome | 10:55.41 |
| | I have something else to annoy you with | 10:55.47 |
| | if you're zoomed in, why on earth does tapping the side of the page take you to the next/previous one ... while zoomed in? either: a) dont do anything or b) reset the zoom to 100% | 10:56.22 |
| | I would prefer a) in most cases but b) would be fine as well .. just that if I'm looking closely at a small image and I tap the sides, I have no clue what happened or where I am (or where my content went to) | 10:57.40 |
| Robin_Watts | deleet: You can at least, always get back by tapping the other side. | 11:06.43 |
| | b) would stop that being the case. | 11:06.50 |
| | Lots of pages have sizable white borders around the edge. | 11:07.19 |
| | so you might zoom in to lose the borders, but you'd still be effectively viewing full screen. | 11:07.38 |
| | OR you might be in landscape mode, and you might zoom so that a line of text across the page just fits on the screen. | 11:08.05 |
| | and then paging left/right does still make sense. | 11:08.14 |
| | So, IMHO b is wrong, and a is worse than we have now. | 11:08.38 |
| deleet | I think that if you zoom past a certain amount it should be disabled. say once you double the size or similar. | 11:23.03 |
| | I also think the margins are too wide, they should be 75% the width they are now (maybe 50%) | 11:24.00 |
| | but that's just personal preference | 11:24.07 |
| paulgardiner | It may be that the size wants to be different between tablet and phone | 11:35.19 |
| deleet | the size on a tablet appears to be 25% of the screen on each side, which is too much (especially in landscape) | 11:43.51 |
| Robin_Watts | e.getX() < super.getWidth()/TAP_PAGE_MARGIN | 12:00.27 |
| | Where TAP_PAGE_MARGIN is 5 | 12:00.36 |
| | so it's 20%. | 12:00.39 |
| paulgardiner | Coo. Git is allowing me to cherry-pick across the app rename. | 12:20.01 |
| Robin_Watts | tor8! | 12:20.09 |
| tor8 | Robin_Watts: hi! | 12:21.01 |
| Robin_Watts | tor8: I believe we are ready to publish on the android store. | 12:21.17 |
| | Do you want to test the apk before we do? | 12:21.32 |
| tor8 | Robin_Watts: ah, good work! um, yes please. I'd like a chance to revisit the icons before you release if necessary. | 12:22.21 |
| Robin_Watts | http://ghostscript.com/~robin/MuPDF.apk | 12:23.04 |
| | I can update the apk by uploading a new one, so I don't think we should be afraid of releasing then changing. | 12:23.35 |
| tor8 | Robin_Watts: indeed. it seems like there's an update almost every day on most android apps, enough to almost be annoying | 12:25.35 |
| sebras | tor8: I like the fact that you are not exaggerating that a bit... ;) | 12:30.53 |
| | tor8: but it's like we said. most apps and libs are not zlib/libjpeg-stable... | 12:31.21 |
| tor8 | Robin_Watts: the "copy" icon should be replaced I think. It looks more like "bookmark" than clipboard to me | 12:32.20 |
| | maybe use the same icon for entering select mode and committing a copy? | 12:32.43 |
| | also, I wonder if we can get the current directory name/path in somewhere in the file browser and make the directory and file icons the same width | 12:33.21 |
| Robin_Watts | tor8: I agree about the copy icon. It really doesn't look like a clipboard to me. | 12:34.02 |
| paulgardiner | I'm adding a strike-through icon to the copy-to-clipboard blade, so there will soon be two things you can do from the select-text icon, hence making it a clipboard might not make sense | 12:40.29 |
| | On the other hand, we might want to restructure the menus so that copy to clipboard is unrelated to strike-through etc | 12:41.00 |
| Robin_Watts | why would making it a clipboard be bad? | 12:41.11 |
| tor8 | paulgardiner: oh, right! | 12:41.20 |
| | Robin_Watts: I think he's referring to me mentioning using a clipboard icon for both entering select mode and committing to selecting | 12:41.50 |
| Robin_Watts | oh, right, yes. agree then. | 12:42.01 |
| | but the current 'bookmark' icon should be replaced with a clipboard (or better, IMO, a clipboard with an arrow onto it) | 12:42.25 |
| tor8 | the pointer can stay, I can't think of a much better icon for that (other than a "marker" pen or something) | 12:42.25 |
| paulgardiner | greeked text with a selection loop around? | 12:43.01 |
| tor8 | paulgardiner: maybe a marching ants rectangle thingy? | 12:43.30 |
| paulgardiner | yeah, or that. | 12:43.42 |
| Robin_Watts | Not sure we can get them done with the current style of icons. | 12:44.00 |
| | but either of those might be fine if we can. | 12:44.10 |
| paulgardiner | Or a text page with an inverted region | 12:44.11 |
| tor8 | well, it's an obscure button but the clipboard should change. we could swap icon sets altogether. | 12:44.12 |
| Robin_Watts | http://thenounproject.com/tag/clipboard/ | 12:45.34 |
| | Look at the 'clipboard' icon on that page. | 12:45.42 |
| | imagine it flipped in the Y axis, with an arrow added indicating that the paper is moving into the clipboard. | 12:46.18 |
| tor8 | http://fortawesome.github.com/Font-Awesome/ | 12:46.48 |
| paulgardiner | Yeah. Nice. I think that spells it out | 12:46.51 |
| Robin_Watts | What size did we need? 24x24 ? | 12:47.01 |
| tor8 | search for "icon-copy" | 12:47.12 |
| | and "icon-strikethrough" | 12:47.23 |
| Robin_Watts | icon-strikethrough, yes. icon- copy - don't see it. | 12:47.52 |
| | I mean, I see it, but it doesn't mean 'copy to clipboard' to me. | 12:48.04 |
| paulgardiner | I have a reasonable strikethrough icon built in GIMP, but of course it might not fit with another icon set if we swap | 12:48.25 |
| tor8 | Robin_Watts: it's the same icon that's used in all windows applications for "copy" | 12:48.37 |
| paulgardiner | ... although yes that Font-Awesone strikethrough looks good | 12:49.24 |
| tor8 | the font-awesome icons look fairly plain and generic, but there's a lot of different ones there and it makes it easy to mix and match | 12:49.56 |
| paulgardiner | icon-paste looks closer to Robin's idea | 12:50.28 |
| tor8 | IIRC robin has expressed reservations against the style of the current icons, but that may just have been against the black-and-white nature of them? | 12:50.31 |
| | paulgardiner: yeah, but that's the common paste icon that's been used everywhere on windows so that's a bit confusing I think | 12:50.56 |
| | another option is to just use text on the buttons | 12:51.03 |
| Robin_Watts | tor8: I can cope with the current icon style. | 12:51.12 |
| tor8 | hm, http://developer.android.com/guide/practices/ui_guidelines/icon_design_action_bar.html | 12:52.45 |
| paulgardiner | Now I'd choose icon-paper-clip from Font-Awesome for copy to clip board, but I realise that's not popular | 12:52.53 |
| | Robin_Watts, tor8: on a different subject, should I create a pdf device which internally builds up a pdf_dict for resources and an fz_buffer for an appearance stream? | 12:55.19 |
| Robin_Watts | paulgardiner: to build resources, we need to build new PDF objects. | 12:55.54 |
| tor8 | paulgardiner: that would be handy, I think. for both the appearance generation and robin's pdfwrite | 12:56.04 |
| Robin_Watts | Which means it needs to be associated with an xref. | 12:56.05 |
| tor8 | but it needs streams for the fonts and image data, which means it needs an xref (or extending pdf_obj yet again with more fields) | 12:56.41 |
| paulgardiner | For my needs, the new objects need to go in the existing xref | 12:56.46 |
| Robin_Watts | It's probably worth looking at the pdfwrite commit on my repo. | 12:56.54 |
| tor8 | I think an xref to fill or reuse would both be useful. | 12:57.04 |
| Robin_Watts | There may be something there that can get you a leg up. | 12:57.05 |
| | Yeah. | 12:57.11 |
| tor8 | with an xref it could reuse objects you create between different invocatiions of the device | 12:57.39 |
| paulgardiner | Maybe a device is the wrong model for what I'm doing. I'm just trying to add things to the current document. I already do that for text widgets that had no appearance stream in the document when loaded, and I manage to do it without running my own xref | 12:59.07 |
| tor8 | paulgardiner: I think reusing the pdfwrite device mechanics would be perfect. | 12:59.35 |
| paulgardiner | a device already exists? | 13:00.18 |
| tor8 | Robin_Watts has the beginnings of one | 13:00.26 |
| Robin_Watts | fz_device *pdf_new_device(pdf_document *xref, fz_buffer *buffer, pdf_dict *resources); sounds good to me. | 13:00.28 |
| | create an empty buffer (or reuse an existing one, which will be appended to). | 13:00.54 |
| | create an empty dict for resources (or reuse an existing one) | 13:01.10 |
| paulgardiner | Oh right. Okay. Does sound perfect | 13:01.12 |
| | And I can use the xref of the current loaded document? | 13:02.17 |
| Robin_Watts | that would be the plan | 13:05.31 |
| | http://ghostscript.com/~robin/copyclip.png | 13:05.48 |
| | That's 24x24, knocked up in paint.net | 13:06.00 |
| paulgardiner | One other concern. For my needs, only a few display objects need to work, so we'd need to publish the device to the main repo in a very incomplete state. | 13:07.15 |
| Robin_Watts | paulgardiner: That sounds fine to me. | 13:07.39 |
| paulgardiner | Yes, I like that. | 13:07.41 |
| | the icon that is | 13:07.48 |
| Robin_Watts | We just label it as "this is an experimental, incomplete device, subject to change without notice." in the comments. | 13:08.07 |
| paulgardiner | Wants to be transparent backgorund, but otherwise... | 13:08.11 |
| Robin_Watts | We've done that before, I believe. | 13:08.14 |
| | paulgardiner: Right. I couldn't figure out how to do that in paint.net | 13:08.30 |
| paulgardiner | :-) | 13:08.38 |
| Robin_Watts | Ignoring my artistic skills, that unquestionably says "selection -> clipboard" to me. | 13:09.11 |
| sebras | tor8: would it make sense to ask your webdesigner to draw a suitable artifexian icon-set for mupdf? | 13:10.20 |
| | tor8: IIRC it was he who drew your mupdf logo, no..? | 13:10.45 |
| deleet | web designer? is someone in here that filthy rich? | 13:17.20 |
| kens | Hmmm just constructed a CIEBasedABC image to test my new code, started by running it through the old code. THe image get written with no colour space..... | 13:25.02 |
| tor8 | sebras: no, that was somebody else | 13:57.03 |
| sebras | tor8: ah, ok. it was just an idea anyway. | 14:23.26 |
| Robin_Watts | Hmm. I've drawn versions of that icon in both sizes, and while it looks clearer, it's clearly less chunky than the other icons. | 14:31.42 |
| paulgardiner | Has to be an improvement I'd have thought | 14:56.10 |
| Robin_Watts | I've just done chunkier versions. Trying now. | 15:07.55 |
| | That's better on the tablet. let me try the phone. | 15:10.36 |
| henrys | hard to get going after the 3 day weekend | 15:19.06 |
| Robin_Watts | Well, you have at least 2 meetings to look forward to, so that should help. | 15:19.34 |
| | :) | 15:19.36 |
| henrys | If only I had the foresight to make meetings on mondays, how many would we miss because of holidays? | 15:20.49 |
| | meeting in 5 | 15:56.20 |
| paulgardiner | ok | 15:56.30 |
| henrys | Why are we so sure the explicit recycle is required - is this something we've reproduced in-house - don't like trusting a single outside party? | 16:00.45 |
| Robin_Watts | henrys: The docs seem to support the desirability for it. | 16:01.19 |
| henrys | okay | 16:01.27 |
| Robin_Watts | What we have now should be fine, with 2 provisos. | 16:01.50 |
| paulgardiner | henrys: I wondered also... sorry baib | 16:02.16 |
| Robin_Watts | 1) We don't call recycle in one case. The memory will get freed, but it just might take 2 rounds of gc. | 16:02.26 |
| | 2) We don't free a bitmap before making a new one and drawing into it. | 16:02.57 |
| | Given that we draw into the new bitmap in a background thread while continuing to use the old bitmap to redraw the screen on the foreground thread, I think this is unavoidable, unless we can find some cunning way of safely telling the system that the OpenGL textures are needed, but the bitmap object from which they are created is not. | 16:04.08 |
| | In short, we have something that is safe, and works. | 16:04.21 |
| | We'll keep thinking about better approaches in the background, but it's not a dealbreaker. | 16:04.44 |
| henrys | status of google play? | 16:05.05 |
| Robin_Watts | I have a button here I can push to publish us to the site. | 16:05.17 |
| henrys | fire when ready | 16:05.39 |
| Robin_Watts | I've got updated icons for the clipboard ready to go. | 16:05.54 |
| | and I've found a bug on older phones with a missing class. | 16:06.05 |
| | paulgardiner is just writing me a bit of code that I'll patch in to fix that. | 16:06.22 |
| | Then we should be ready to give it one last test, and to publish it. | 16:06.32 |
| paulgardiner | Just about to push it | 16:06.33 |
| Robin_Watts | paulgardiner: Thanks. | 16:06.39 |
| paulgardiner | pushed | 16:07.22 |
| henrys | paulgardiner: do you have a schedule guess on the annotation list? | 16:07.38 |
| | the other thing on my list is do we want to do some sort of android fanfare at release time possible putting the api up with the other releases? | 16:08.45 |
| | s/api/apk | 16:08.58 |
| | or possibly a pointer to google play on the release page so any customer downloading our stuff sees the android stuff | 16:09.42 |
| paulgardiner | henrys: Difficult to guess, but I'm hoping to have strikethrough working by next week. Then the other text-adornments should be simple to add too. The other types of annotation require more complicated UI , and I haven't thought out exactly how to do them yet | 16:10.29 |
| henrys | tor8:what's the mupdf release date? | 16:11.27 |
| paulgardiner | To match Adobe Reader, we'll also need to add facility to edit the color and thickness of things like strikethrough. | 16:11.45 |
| Robin_Watts | henrys: Yes, we should mention Google Play in the Android release news. | 16:11.51 |
| tor8 | henrys: that time again? :( | 16:12.27 |
| henrys | All of this info has to go into the release news letter and it would be nice if all the android stuff were tied to mupdf release. | 16:12.44 |
| | s/info/android info/ | 16:12.57 |
| tor8 | I've got an API simplification that will require some changes for customers, that'll need to go in before we make a 1.2 | 16:13.08 |
| Robin_Watts | henrys: We can update the Google Play version at any time, so I think we just rebuild and update when 1.2 comes due. | 16:13.25 |
| henrys | Robin_Watts: okay, so the code is stable enough now for Google Play | 16:14.07 |
| | ? | 16:14.08 |
| Robin_Watts | yes, I believe so. | 16:14.20 |
| henrys | tor8:it would be nice to get both gs and mupdf out at the same time - we are shooting for early february - is that okay? | 16:16.02 |
| | paulgardiner: anything more for the meeting? | 16:17.41 |
| | look forward to seeing you in Miami | 16:17.50 |
| tor8 | from my point of view, I should be ready for february. no new gtk+ viewer in that release though. robin and paul will have to decide when they're ready so I'll leave the final decision to them. | 16:18.41 |
| henrys | tor8:fair enough | 16:18.58 |
| paulgardiner | ES has finally updated their file manager according to our requests and now XLS files load direct to MuPDF | 16:19.04 |
| tor8 | paulgardiner: are you coming to the miami meeting? | 16:19.12 |
| paulgardiner | yeah, be great to see you all face to face again. | 16:19.27 |
| Robin_Watts | I think its safe to say that we won't get annotations by the start of Feb. | 16:19.27 |
| | so I believe we're good to go now. I can't think of anything obviously missing. | 16:19.57 |
| paulgardiner | Robin_Watts: yeah. Possibly a demo of them. | 16:19.59 |
| | of some of them I mean | 16:20.05 |
| Robin_Watts | paulgardiner: Well, any we get that work will be a bonus, but I don't think we should hold the release for them. | 16:20.24 |
| henrys | right so you guys will work out freezing and all that for mupdf. | 16:20.27 |
| tor8 | I am a bit worried about the increasing bug count for mupdf in bugzilla | 16:20.50 |
| | we're up to 99 bugs now | 16:20.58 |
| Robin_Watts | tor8: We can do a quick runthrough on that before the release. | 16:21.28 |
| henrys | are you working on catching up with gs at 600 or so. | 16:21.53 |
| | ? | 16:21.56 |
| tor8 | Robin_Watts: I have a suspicion we can close 1/3 of them if we just say no and close enhancement requests | 16:21.58 |
| Robin_Watts | tor8: Yeah. | 16:22.08 |
| henrys | how many aren't enhancements? | 16:22.21 |
| | anyway good meeting thanks! | 16:23.18 |
| tor8 | henrys: 72 are not flagged with enhancement | 16:23.35 |
| | though some of those probably should be | 16:23.42 |
| Robin_Watts | I'm uploading a release candidate apk now. | 16:24.38 |
| | It would be nice for everyone to download it and try it on the devices they have. | 16:25.03 |
| henrys | okay my nexus 7 is ready to go | 16:25.18 |
| Robin_Watts | oh, bugger. I'll need to rebuild. | 16:25.39 |
| | Doing a clean rebuild now. If the meeting is over, I've got to pop out for a mo. back before 5 easily. | 16:26.45 |
| henrys | I'm done | 16:27.19 |
| Robin_Watts | paulgardiner, tor8: There are a few reviews with the last fixes on in my repo. | 16:27.36 |
| tor8 | Robin_Watts: tap area and icon changes look fine. paul will have to weigh in on the clipboard stuff. | 16:36.56 |
| ray_laptop | Robin_Watts: where will you put the .apk so I can try it. I have 4 different devices | 16:41.05 |
| paulgardiner | Robin_Watts: clipboard stuff looks good. | 16:42.15 |
| | So margin is MIN(width/5, MAX(100px, 1inch)) | 16:46.25 |
| | Yeah, that makes sense | 16:47.59 |
| Robin_Watts | paulgardiner: yes. | 16:48.01 |
| paulgardiner | all looks good to me | 16:48.24 |
| Robin_Watts | ray_laptop: I'll announce the location when it's uploaded :) | 16:49.08 |
| ray_laptop | Robin_Watts: Ta | 16:50.35 |
| Robin_Watts | henrys, tor8, paulgardiner: One other thing... Miles and Scott had the idea that we should do a youtube video talking people through the features of MuPDF. | 16:51.58 |
| | I spent some time on saturday experimenting with my camera etc to try and sort something out. | 16:52.30 |
| | I think I have a setup now where I can shoot it (need to turn the screen brightness down to avoid the white table cloth background looking orange, and possibly turn autofocus off, as it seeks during filming otherwise). | 16:53.20 |
| henrys | your 15 minutes of fame has arrived ;-) | 16:53.40 |
| Robin_Watts | But I think we need to work on a script. | 16:53.45 |
| | henrys: No, the first job was to find a way of lighting it so that my big bald head isn't visible reflected in the tablet :) | 16:54.12 |
| tor8 | Robin_Watts: a screen capture thing might be sufficient otherwise. a screen with a voiceover but we'll need some way to make visible touch gestures. | 16:54.38 |
| Robin_Watts | http://ghostscript.com/~robin/MuPDF.apk <- tor8, paulgardiner, henrys, ray_laptop, mvrhel_laptop | 16:55.00 |
| tor8 | Robin_Watts: talc powder :) | 16:55.16 |
| henrys | Robin_Watts: I'll have a look after the next meeting | 16:55.36 |
| | which is in 5 minutes | 16:55.48 |
| Robin_Watts | tor8: Shooting downwards with a camera means we can swap portrait -> landscape and show that it works on phones etc too. | 16:56.05 |
| kens | meeting time ? | 17:00.08 |
| henrys | so let's start with the latest printer customer - seems like ray_laptop should take the lead on this, yes? | 17:00.11 |
| kens | THe one that Miles sent all the questions for ? | 17:00.29 |
| henrys | kens:yes | 17:00.34 |
| kens | ray seems like the right person to me | 17:00.42 |
| henrys | ray_laptop is that okay? | 17:00.43 |
| | alexcher how is the P1 bug coming, do you need help - very important we fix that quickly. | 17:01.20 |
| | oh it looks like we lost ray_laptop at some point, he was here. | 17:02.22 |
| alexcher | henrys: I'm testing the fix. | 17:03.14 |
| henrys | so chrisl when is freeze? | 17:03.20 |
| | alexcher:great! | 17:03.29 |
| chrisl | henrys: I'm thinking next Monday, unless there are objections | 17:03.55 |
| paulgardiner | Robin_Watts: quick test of the apk looks good. I'll try to hammer it a bit more later | 17:04.07 |
| henrys | chrisl: fine for me. | 17:04.18 |
| mvrhel_laptop | the freeze is in Jan? | 17:04.19 |
| chrisl | mvrhel_laptop: if we want an rc in the first week of Feb | 17:04.39 |
| mvrhel_laptop | ok | 17:05.00 |
| Robin_Watts | paulgardiner: It checks out on my tablet and my phone. | 17:05.09 |
| alexcher | There are so many SEGVs found recently. It's unlikely thet they all will be fixed by Monday. | 17:05.17 |
| ray_laptop | I'm here, sorry. I was just looking at bug 693573 | 17:05.18 |
| | henrys: I'll take on the customer's questions | 17:06.15 |
| henrys | ray_laptop:okay just want to make sure you are going to follow up with the new printer customer - did you see that from Miles? | 17:06.17 |
| | ray_laptop:thanks | 17:06.28 |
| ray_laptop | henrys: that's the "Moving Forward with Ghostscript" topic, right ? | 17:07.14 |
| | (that's the latest I have from Miles) | 17:07.29 |
| henrys | right have we gotten them a customer number? | 17:07.35 |
| ray_laptop | Joann usually generates those, and I don't think she was in yesterday | 17:08.35 |
| kens | Not that I see | 17:08.36 |
| henrys | I'll ping Miles about it. | 17:08.58 |
| mvrhel_laptop | Looks like they have some color questions. ray_laptop: let me know if you want any input from me | 17:09.05 |
| ray_laptop | mvrhel_laptop: OK. | 17:09.11 |
| henrys | anything else we should talk about? | 17:10.36 |
| kens | I've just put a comment on bug #693575, I'd appreciate it if Ray/chris/Alex could take a look | 17:11.07 |
| chrisl | kens: I think I stumbled across that before, but the problem went away when I fixed something "upstream", so I didn't pursue it | 17:12.43 |
| kens | chrisl I'm pretty sure the uninitialised variable is wrong, and causing the problem, I'm 'fairly' sure the correct fix is to make cdev = dev, but I'm not certain | 17:13.23 |
| | I think this happens because ps2write can accumulate clips itself | 17:13.40 |
| chrisl | Actually, why are we testing with DisableFAPI? Are we really wasting time testing deprecated code like that? | 17:14.47 |
| ray_laptop | chrisl: so do you want to have a look at it ? It's not in clist mode, so I (afaict) have no particular expertise in gx_image_fill_masked_start | 17:14.54 |
| Robin_Watts | tor8: Start Mupdf (windows or mac) on a file. Hit 'n'. Does it infinite loop for you? | 17:14.59 |
| kens | chrisl I put that as my first comment :-) | 17:15.03 |
| | But in this case I think it may be exhibiting a deeper problem | 17:15.23 |
| Robin_Watts | ah, not infinite loop, just takes a long time. We shouldn't search for the empty string anyway. | 17:15.32 |
| ray_laptop | marcosw: can you recall -- do we have any customers that are relying on DisableFAPI ??? | 17:15.33 |
| chrisl | ray_laptop: I'm rather tied up with this GC issue, but I can certainly take a look when I get time | 17:15.47 |
| ray_laptop | chrisl: fair enough. The GC issue is plenty hairy | 17:16.06 |
| marcosw | ray_laptop: I don't know of any customer using DisableFAPI | 17:16.25 |
| henrys | DisableFAPI should live on a bit longer right? We haven't really agreed when it should actually disappear? | 17:17.13 |
| kens | As soon as possible :-) | 17:17.31 |
| ray_laptop | chrisl: I assume you have looked at all the discussion on bug 693179 | 17:17.45 |
| chrisl | henrys: DisableFAPI for PCL/XPS needs to be around for a while, but for GS? | 17:18.13 |
| | ray_laptop: that's not the issue here | 17:18.19 |
| ray_laptop | henrys: Why not kill it this release (not take any code out, but make it not work so that it's easily patched back in) | 17:18.43 |
| tor8 | Robin_Watts: not infinite loop, just a slow search for nothing... | 17:18.52 |
| | which should be aborted early, like in the ios and android apps | 17:19.07 |
| Robin_Watts | Yeah. But like I say, we shouldn't be searching for nothing. | 17:19.10 |
| tor8 | Robin_Watts: yeah. it may be my patch to factor out the searching into a common function that re-introduced this. lemme check real quick. | 17:19.31 |
| | oh wait, I didn't change pdfapp.c to use the new functions... | 17:20.15 |
| henrys | I don't see how cdev can uninit without an error return. | 17:20.19 |
| chrisl | ray_laptop: this GC problem is caused because we're getting into the garbage collector when a chunk hasn't been "closed" so the (in this case) bottom address for the chunk hasn't been written back to the chunk list, and we try to scan freed memory. | 17:20.47 |
| kens | gx_image_fill_masked_start never returns an error | 17:20.53 |
| | oops except a VMerror | 17:21.06 |
| tor8 | the new function (fz_search_text_page) aborts early on an empty string, but that still doesn't stop trying to load every page | 17:21.17 |
| henrys | it returns a VMError if pcdev is null | 17:22.13 |
| kens | henrys, it can fail to enter there. | 17:22.24 |
| | if (gx_dc_is_pattern2_color(pdevc) || gx_dc_is_pattern1_color_clist_based(pdevc)) { | 17:22.31 |
| ray_laptop | henrys: I agree, looking at the code. | 17:22.37 |
| chrisl | henrys: if the conditional on line 41 is true and the one on line 42 is false, then cdev doesn't get written to | 17:22.39 |
| ray_laptop | kens: but then it should return _cdev = dev | 17:22.52 |
| kens | thanks, what chrisl sdaid | 17:22.53 |
| | ray_laptop : no | 17:23.00 |
| henrys | I see there is no else on that nested if if so that is the case you are in. | 17:23.00 |
| kens | I have a patch which adds an else clause | 17:23.14 |
| | and I'm testing it | 17:23.19 |
| chrisl | henrys: exactly | 17:23.22 |
| ray_laptop | oops. I see it now, I was (also?) reading it as a combined if, not two separate if stmts | 17:23.41 |
| tor8 | Robin_Watts: I was considering adding some high level convenience functions like fz_draw_page(doc, page, zoom) and fz_search_page(doc, page, needle) but that'll probably not happen before 1.2 release if we're doing the release in two weeks | 17:23.42 |
| kens | However I also set cdev=dev in gx_image_fill_masked because I think the uninitialised variable is dangerous | 17:23.59 |
| Robin_Watts | tor8: right. | 17:24.19 |
| ray_laptop | kens: there was probably a static analyzer warning we ignored sometime in the past about this :-) | 17:24.45 |
| kens | ray_laptop : I've no doubt you are corect, all I can sy is 'not my area of the code guv' | 17:25.21 |
| ray_laptop | kens: mine neither (ray steps backwards) | 17:25.39 |
| Robin_Watts | touches nose. | 17:25.47 |
| kens | Well everyone seems agreed that cdev should be set to dev, which is what I was unsure about. If the regression test is OK I'll commit it | 17:26.05 |
| tor8 | Robin_Watts: paulgardiner: http://ghostscript.com/~tor/stuff/awesome.zip has the font-awesome icons extracted to svg and rendered to png in all android resolutions for action buttons (18x18, 24x24, 36x36, and 48x48). they're white so will need to have the "tint" to get black icons for the outline view. I'll see about using those sets for the app, but if you want to have a look yourselves the files are there. | 17:26.15 |
| chrisl | kens: I'll have a proper look tomorrow morning, but I think you're on the right track (from what I remember!) | 17:26.29 |
| ray_laptop | kens: thanks for fixing it, however. I think returning *cdev = dev is correct when the device has the gxdso_pattern_can_accum return true | 17:26.53 |
| kens | What really confused me awas that in the debugger, cdev 'just happened' to be pointing at a clipper device..... | 17:26.53 |
| ray_laptop | kens: maybe from a previous call ?? who knows with uninitialized stack variables | 17:27.33 |
| kens | Yeah, exactly, dead confusing though.... | 17:27.47 |
| henrys | almost the half hour anything else? | 17:27.51 |
| alexcher | marcosw: There was a message recently with encrypted PDF that contains questions and bug reports. We need a sample file for the issue #11. | 17:27.59 |
| ray_laptop | not from me. I'll go back to my segfault. | 17:28.07 |
| kens | henrys I doubt that the colour conversion stuff will make it into the release, even turned off. I don't think I can finish it by Monday | 17:28.36 |
| | For pdfwrite that is | 17:28.46 |
| henrys | kens:np | 17:28.47 |
| alexcher | I need to leave at 12:30 for about 40 min. | 17:28.50 |
| ray_laptop | chrisl: I am curious about the latest GC psignal issues, BTW. Please ping me (or SMS me if I am not responding) if you find something or want to discuss | 17:28.55 |
| henrys | even thought freeze is monday I think even now is late for anything large. | 17:29.17 |
| | s/thought/though | 17:29.38 |
| marcosw | alexcher: I'm not sure what encrypted PDF message you mean. Was this an email or a bug? | 17:29.44 |
| kens | henrys I was going to include it but 'turned off' with a switch to enable it for the curois, but I don't think I'll manage that | 17:29.48 |
| ray_laptop | unless it is "off by default" and is just in there so it can be tested | 17:29.58 |
| henrys | alexcher:are you talking about ray_laptop work to dispatch? | 17:30.13 |
| alexcher | marcosw: Moving forward with Ghostscript | 17:30.33 |
| chrisl | ray_laptop: okay, but as I say, this problem is *exposed* by the psignal change, but not caused by it. We should never get into GC with an "unclosed" chunk. | 17:30.46 |
| henrys | alexcher:ray_laptop has agreed to go through that and dispatch appropriately | 17:30.51 |
| | oh the gx_image_fill_mask_start might have been introduced by Robin_Watts with the dev_spec_op change. | 17:35.26 |
| kens | Ah, that makes sense | 17:35.38 |
| Robin_Watts | hmm, what? | 17:35.46 |
| kens | is not looking to blame anyone, jsut for an opinion o the rightness of the fix | 17:36.20 |
| ray_laptop | henrys: alexcher: what message is that. The latest email I see from that (new) customer was last May | 17:37.32 |
| Robin_Watts | tor8: review up for you. | 17:38.16 |
| henrys | ray_laptop:jan 21 from miles | 17:39.04 |
| tor8 | Robin_Watts: nod. | 17:39.41 |
| Robin_Watts | tor8: Thanks. | 17:39.47 |
| ray_laptop | oh. I was looking in the body and didn't see the attachments. Sorry. Opening now | 17:39.49 |
| henrys | Robin_Watts:I think you just changed it to use a difference mechanism to query the device... | 17:40.18 |
| kens | Hmm I got some surprising differences with pdfwrite, I'll have to look at this some more tomorrow. | 17:42.40 |
| | I htink I may have left some colour code enabled. Anyway, goodnight all | 17:43.07 |
| ray_laptop | have to run a quick errand for the wife. bbiab... | 17:47.12 |
| marcosw | henrys: speaking of the jan 21 email from miles with the "GS-Queries_20130121_enc.pdf" attachment. Do you want me to enter bugs/enhancement requests for the issues? Except of the memory leak that alexcher asked about the remaining issues are performance questions or color questions/issues. | 17:49.06 |
| henrys | marcosw:go ahead and make a bug for the leak. | 17:51.55 |
| marcosw | henrys: okay. | 17:52.30 |
| henrys | we don't have a number yet | 17:52.51 |
| alexcher | I'm back. | 17:56.10 |
| Robin_Watts | tor8: I had an idea for an enhancement to the android app (I mentioned this briefly to paulgardiner earlier). As well as having regions on the left/right of the screen to tap to flip to the next page, we should have regions at the top/bottom. | 18:02.29 |
| tor8 | okay, what would those regions do? | 18:02.53 |
| | Robin_Watts: ugh, the default icon sizes from that android developer page are *tiny*! | 18:03.11 |
| Robin_Watts | If you tap at the bottom, then we look at the region of the page visible in the current zoom. If we can move that region down, we do so. | 18:03.17 |
| | If we can't move it down, then we think about moving it to the top of the current page, but moved to the right. If that would overshoot the edge of the page (by more than 50%), then we move to the top of the next page (with a magically generated x position) | 18:04.46 |
| tor8 | Robin_Watts: sounds like you want a vertical non-paged layout :) | 18:05.16 |
| Robin_Watts | The idea being that you can adjust the zoom so that a column of text fills the screen widthways. | 18:05.29 |
| | Then tapping down will move through that column. | 18:05.40 |
| tor8 | Robin_Watts: in practice, I think that behaviour would be warranted for the current left/right zones | 18:05.43 |
| marcosw | I need to run to Uni, but will be back on-line later today. | 18:05.54 |
| Robin_Watts | When you hit the bottom of the page we skip back to the top for the next column, if there is room for one, or we go to the next page (shuffling back to the left hand column) if there isn't one. | 18:06.30 |
| | tor8: I'd be annoyed to lose pure page flipping for this. | 18:06.56 |
| | which is why I thought up/down would work well. | 18:07.07 |
| tor8 | Robin_Watts: I dunno if that'd work well ergonomically though | 18:09.43 |
| | we could still have the swipe to flip pages | 18:09.52 |
| Robin_Watts | clicking 'down' to move down the column makes sense to me. | 18:10.10 |
| | The swipe is less useful if you've zoomed in. | 18:10.53 |
| tor8 | Robin_Watts: and in zoomed out mode, both down and right would behave the same | 18:11.17 |
| Robin_Watts | yes. | 18:11.27 |
| tor8 | so the bottom-right overlap, should that be bottom? | 18:11.40 |
| Robin_Watts | possibly. | 18:11.54 |
| tor8 | in which case I think the ergonomics may work out. having to tap in the bottom middle screen when holding it by the edges would be awkward. | 18:12.10 |
| Robin_Watts | I think I should try to code it. If it turns out to work really well, then we can consider making it left/right instead. | 18:15.37 |
| tor8 | Robin_Watts: paulgardiner: try tor/icons android app | 18:21.28 |
| Robin_Watts | tor8: Can you upload an apk somewhere? | 18:22.59 |
| tor8 | http://ghostscript.com/~tor/stuff/MuPDF-debug.apk | 18:24.10 |
| Robin_Watts | Using gitweb to view the icons is... unhelpful. It puts them on a white page :) | 18:24.13 |
| tor8 | the file picker icons are untinted there, so they're not very nice. but I can tint them like I do the link icon | 18:24.55 |
| | I hope. just need to figure out the xml but dinner needs to be cooked. | 18:25.15 |
| Robin_Watts | How can your MuPDF-debug.apk be only 8Meg ? | 18:26.30 |
| tor8 | I don't know :) | 18:26.47 |
| Robin_Watts | oh, no V* ? | 18:27.07 |
| | V8? | 18:27.09 |
| | I have to say, that overall I prefer all those icons. (If the filepicker ones were black rather than white). Except for the copy icon. | 18:28.04 |
| | but the copy icon is not a dealbreaker. | 18:32.04 |
| tor8 | Robin_Watts: bah, ((ImageView)v.findViewById(R.id.icon)).setColorFilter(Color.argb(255, 0, 0, 0), PorterDuff.Mode.MULTIPLY); doesn't work... | 18:33.38 |
| | Robin_Watts: ah, yes. no v8 | 18:33.50 |
| henrys | the new app did not replace the old for some reason. | 18:41.51 |
| paulgardiner | tor8, Robin_Watts: I like the new icons, other than the A for text select. Wouldn't say I lothed the A though. | 18:41.56 |
| Robin_Watts | tor8: Can't we just change the pngs rather than relying on it being done on the fly? | 18:42.07 |
| | henrys: No. Uninstall, then reinstall. | 18:42.16 |
| paulgardiner | henrys: I seem to have to uninstall explicitly too for some reason | 18:42.17 |
| Robin_Watts | I hope that that should be solved once we start using versions downloaded from google play as they are versioned. | 18:42.38 |
| paulgardiner | ... that was assuming we re changing the folder view ones back to black of course | 18:43.13 |
| Robin_Watts | paulgardiner, tor8, possibly we should make our own icon which is 'A' with a pointer over it. | 18:43.28 |
| | or 'A' with a pointer dragging a rectangle over it. | 18:44.17 |
| paulgardiner | I'd prefer some greeked text than a single char | 18:44.47 |
| | ... but if everyone else like A... | 18:45.36 |
| henrys | I've smoke tested on the nexus 7 seems okay | 18:51.07 |
| | lunch | 18:54.57 |
| tor8 | Robin_Watts: paulgardiner: "A" for text manipulation actions | 18:57.57 |
| | Robin_Watts: I'd prefer the icon pngs all the same color and do the tinting in the xml or java, so we can reuse them in different contexts as needed | 18:58.21 |
| Robin_Watts | tor8: If we use them in 2 different colors, let's include them twice. | 18:58.46 |
| paulgardiner | You can apply a filter to an ImageView to change white to black. | 19:02.11 |
| tor8 | Robin_Watts: then we need to encode the color in the file name | 19:05.15 |
| | like light and dark for two versions | 19:05.26 |
| Robin_Watts | tor8, marcosw: Do we not test xps files for mupdf in the cluster ? | 19:05.38 |
| marcosw | Robin_Watts: no. would probably be easy to add. | 19:06.07 |
| Robin_Watts | that'd probably be good, I guess. | 19:06.23 |
| | tor8: A review for you online then. | 19:09.03 |
| | (no hurry) | 19:09.07 |
| marcosw | Robin_Watts: Is there anything special that has to be done to process an xps file with mupdf? | 19:09.41 |
| Robin_Watts | Nope. | 19:09.51 |
| marcosw | Robin_Watts: I've added xps testing to mupdf. Until someone does a mupdf commit the clusterpush results won't included any xps data (except for xps files which are generating errors, of which there are two). | 19:46.06 |
| Robin_Watts | marcosw: Can we schedule a retest of the last mupdf commit ? | 19:46.32 |
| marcosw | good thinking. I'll do that. | 19:47.01 |
| Robin_Watts | Thanks, cos my next commit is the one I want the xps tested for :) | 19:47.16 |
| UukGoblin | hi :-) I have a postscript file in landscape, and I'd like to rotate it 90deg clockwise and convert it to portrait | 20:28.03 |
| | but I can't figure out how to do it - can pstops do this? | 20:28.16 |
| | all my pstops output seems to be in landscape, or if I force the -w and -h, the output is cropped | 20:28.48 |
| | i.e. this: pstops -h297mm -w210mm 'L(297mm,0)' q2b-plot.ps test.ps | 20:30.33 |
| | seems to rotate fine (OK it's counterclockwise but that doesn't matter), but produces output in landscape :-/ | 20:31.08 |
| | and if I swap it, i.e. do -h210mm and -w297mm, it produces portrait but it's cropped | 20:31.43 |
| | and when I convert it to pdf with ps2pdf it becomes cropped landscape :-/ | 20:32.21 |
| alexcher | UukGoblin: the best way to do it is to hack the file a little. | 20:34.46 |
| UukGoblin | hmm :-> | 20:36.01 |
| | OK I see two candidates for hackery: "%%BoundingBox" and "ClipToBoundingBox { newpath... }" | 20:37.42 |
| | but I can't quite say I speak much postscript - and I'm not sure if it would rotate it? | 20:38.16 |
| alexcher | UukGoblin: If the file has /PageSize [842 595] change it to portrait. | 20:39.42 |
| UukGoblin | I created the input file with: echo -e 'set terminal postscript\nset output "q2b-plot.ps"\nplot sin(x)' | gnuplot | 20:40.24 |
| | it doesn't have /PageSize :-/ | 20:40.39 |
| alexcher | UukGoblin: Insert this after the set-up: 842 0 translate -90 rotate | 20:41.27 |
| UukGoblin | alexcher, hmm, I tried to put it after /^newpath$/ and before "(Helvetica) findfont 140 scalefont setfont" and it produced a blank landscape page | 20:45.12 |
| alexcher | UukGoblin: Actually: 842 0 translate 90 rotate | 20:45.15 |
| UukGoblin | ah, 90 did produce a non-blank landscape output | 20:45.49 |
| | however I can only see a small bit of the graph :-> | 20:45.59 |
| alexcher | UukGoblin: can I have the file. | 20:46.08 |
| UukGoblin | alexcher, have you got gnuplot installed? | 20:46.22 |
| alexcher | UukGoblin: No, but I can get it. | 20:47.01 |
| UukGoblin | echo -e 'set terminal postscript\nset output "q2b-plot.ps"\nplot sin(x)' | gnuplot | 20:47.17 |
| | ^ that'll produce the file, q2b-plot.ps | 20:48.32 |
| | I'm surprised pstops can't do it :-> | 20:49.08 |
| alexcher | Insert after the header comments: <</PageSize [842 595]>>setpagedevice 0 595 translate -90 rotate | 20:55.07 |
| UukGoblin | \o/ magic | 20:56.26 |
| | looks like landscape in gv, but after converting to pdf with ps2pdf, it looks perfect in xpdf :-D | 20:57.19 |
| | thanks :-) | 20:57.39 |
| BradleyGZ | Wondering if someone might can help me in what direction to go to help solve this problem. | 22:02.47 |
| | The converter 'PostScript/PDF to PDF/TIFF/Printer (PS2PDF)' cannot convert the file 'D:\Esker Platform\Storage\queue\attach\20130122\15\68c67f54Z0e01000.xgf_Msn_20203610_2w2.pdf' from format '.pdf' to format 'gdi'. | 22:02.49 |
| UukGoblin | looks like something's trying to use a wrong tool | 22:03.26 |
| | ps2pdf converts postscript to pdf | 22:03.33 |
| | whereas your message implies converting pdf to gdi | 22:03.45 |
| | (but I'm no expert) | 22:03.51 |
| BradleyGZ | I thought the same thing but wasnt sure. I plan on contacting Esker support tomorrow since this is their application but figured I would try to troubleshoot it myself first | 22:04.39 |
| | Forward 1 day (to 2013/01/23)>>> | |
IRC Logs
