| | <<<Back 1 day (to 2015/04/06) | 20150407 |
| rayjj | Robin_Watts: before that, can you look back into the faster scan line rasterizer for GS ? That could help a lot of folks, possibly | 00:03.12 |
| | Robin_Watts: I was looking into the bottlenecks in GS transparency and I suspect we see the same things there since both are based on Raph's "libart", iirc | 00:04.59 |
| | many touching of pixels multiple times, reading and writing and relying on a *magic* CPU and RAM cache to make it hurt less | 00:06.05 |
| | but from looking at it, mupdf does pre-mulitplication of color+alpha more than GS | 00:07.02 |
| | IMHO, "Normal" (also "Compatible" and maybe some other) blending modes may be amenable to GPU processing at least for the 'blend' step in GS which touches every pixel in the "dirty" rect | 00:09.07 |
| kens | Morning chrisl | 06:52.26 |
| | THanks for sorting out that Marcos bug, I'mpuzzled as to why it only exhibits with Luratech though, just memory layout ? | 06:52.49 |
| chrisl | kens: NP, it was pretty trivial. The reason it only happens with Luratech is because that check is idef'ed specifically for Luratech..... | 07:14.33 |
| kens | Yes I see that, but I don't think that line has changed, has it ? | 07:15.06 |
| | Or did I add it recently ? | 07:15.24 |
| chrisl | <shrug> It was obvious new with the getparam spec op work, but beyond that... dunno. It was clear the tests were reversed, though | 07:16.22 |
| kens | Yeah, clearly so. WHat do you plan to do now though ? I'd be tempted to leave the free release and just do a new customer release | 07:16.52 |
| chrisl | That's what I was going to suggest - I figured we'd discuss it at the meeting this afternoon | 07:17.17 |
| kens | OK. The man putting new flooring down has just arrived so I have to go move furniture. This may involve me being offline most of today as the router will have to move at least and may need to be disconnected. | 07:17.58 |
| | So if I disappear for an extended period, that's why. | 07:18.09 |
| chrisl | Have "fun"...... | 07:18.16 |
| kens | Its not too bad, just a table and sideboard, did the rest yesterday.... | 07:18.34 |
| Robin_Watts | Morning tor8 | 09:24.55 |
| | tor8: Updated commits on robin/master | 09:48.44 |
| | and a fix for vertical text mode stuff on robin/text_fiddling | 09:49.05 |
| | bug 695909 requires a fix to the man page. | 09:49.58 |
| tor8 | Robin_Watts: could rename the option to 'pagetree' | 10:29.39 |
| Robin_Watts | which option? | 10:29.51 |
| tor8 | to reduce potential jumping to wrong conclusions | 10:29.54 |
| Robin_Watts | mutool pages -> mutool pagetree ? | 10:30.00 |
| tor8 | mutool show file.pdf pages | 10:30.01 |
| | bug 695909 | 10:30.18 |
| | mutool pages is fine | 10:30.35 |
| Robin_Watts | oh, I see. | 10:30.49 |
| | It's [pages] not <pages> | 10:31.01 |
| | How long has it been called pages? | 10:31.27 |
| | If it's longer than just this release, I vote we leave it. | 10:31.38 |
| tor8 | in truth, it's [p] not [pages] ... the code only looks at the initial character :) | 10:31.42 |
| | you could use 'mutool show file.pdf pffft' and it'd work the same... | 10:32.05 |
| Robin_Watts | I see. | 10:32.11 |
| tor8 | so changing the usage message and manpage would not break anybody's code | 10:32.32 |
| Robin_Watts | Go for it then. | 10:32.42 |
| | I'm about to go for a run. | 10:33.11 |
| | I once again think that we've done everything we need to for the release. | 10:33.25 |
| tor8 | Robin_Watts: okay. I'm looking through your commits now. | 10:33.34 |
| Robin_Watts | Ta. back in a bit. | 10:33.40 |
| tor8 | there is one thing I've forgotten to do which I'd like to get into the release | 10:33.45 |
| | hopefully it'll be a quick fix I can do today, otherwise we can skip it | 10:33.56 |
| | I want to add some basic margins to HTML/EPUB documents | 10:34.16 |
| Robin_Watts | ah, yes. | 10:34.34 |
| tor8 | as it is, there's no top/bottom margin which can look dreadful | 10:34.34 |
| Robin_Watts | Could we specify a base font size too? | 10:35.15 |
| | so people that want larger text can at least restart with a bigger value ? | 10:35.39 |
| tor8 | we could add an option to mudraw and mupdf-x11 | 10:36.21 |
| Robin_Watts | yeah. | 10:36.31 |
| tor8 | ideally for both font size and page size | 10:36.44 |
| Robin_Watts | -epub-margin, -epub-fontsize, -epub-pagesize | 10:37.03 |
| tor8 | actual font selection and margins I'm planning to add user stylesheets for | 10:37.04 |
| Robin_Watts | OK, that's all sounding like more than a quick fix though. | 10:37.23 |
| tor8 | but the default font size and page size should be easily changed from the viewer | 10:37.24 |
| | -W -H and -S? | 10:38.03 |
| | we don't have any long-options elsewhere | 10:38.14 |
| Robin_Watts | These options are specific to one format. | 10:38.33 |
| | which is why -epub-blah felt right. | 10:38.44 |
| tor8 | so are several other options in mudraw :( | 10:39.04 |
| Robin_Watts | but -W, -H, -S would do in a pinch. | 10:39.12 |
| tor8 | like band height -B | 10:39.17 |
| Robin_Watts | Band Height works for all input formats. | 10:39.27 |
| tor8 | according to the usage text, it only works for pnm and png | 10:39.47 |
| | and it has no effect for the text output and md5 checksums | 10:40.02 |
| Robin_Watts | I thought it should work for all bitmap outputs.... but OK. | 10:40.21 |
| tor8 | I'm not familiar enough with that code... if it does work for all bitmap outputs, we should change the usage text | 10:40.45 |
| Robin_Watts | yeah, just pXm and png so far. | 10:42.23 |
| tor8 | Robin_Watts: the #ifdef DUMP_GELS should #ifndef NDEBUG (which is what we use for the other dump functions) | 10:42.39 |
| Robin_Watts | ok. | 10:42.53 |
| | Urm, no. | 10:43.32 |
| | Cos DUMP_GELS causes fz_sort_gel to call fz_dump_gels too. | 10:44.00 |
| tor8 | oh... | 10:44.22 |
| | I thought this was like the miscellaneous other function that we can call from gdb to inspect data structures | 10:44.52 |
| | like fz_print_path and obj, etc | 10:44.58 |
| Robin_Watts | It's like DUMP_GROUP_BLENDS | 10:45.01 |
| | or DUMP_STACK_CHANGES | 10:45.06 |
| tor8 | some of which are call print, and others dump | 10:45.07 |
| | right. then it's good. | 10:45.13 |
| Robin_Watts | fab. back soon. | 10:45.37 |
| tor8 | just a minor niggle with the comments in vertical mode text... the origin for CJK vertical text is usually 'top center' not 'top left' | 10:48.43 |
| | code looks good | 10:48.55 |
| Robin_Watts | tor8: but as far as we are concerned, in that routine, it's top left. | 12:19.22 |
| tor8 | Robin_Watts: okay. | 12:20.26 |
| Robin_Watts | so all commits are good to go? | 12:20.44 |
| | Should I wait to push the final '1.7' one until after your tweaks? | 12:21.02 |
| Robin_Watts | pushes all but the 1.7 one. | 12:27.13 |
| tor8 | Robin_Watts: I've got EPUB layout option commits on tor/master | 12:28.26 |
| | still working on the margin one | 12:28.31 |
| | and yes, all commits are good to go but I'd wait for the 1.7 until I'm done or give up for the day | 12:28.55 |
| Robin_Watts | Well, we're back under 100 bugs :) | 12:32.04 |
| tor8 | Robin_Watts: woo! \o/ | 12:32.11 |
| Robin_Watts | Page width in points. So is the page width in pixels affected by the -r flag? | 12:33.40 |
| tor8 | yes | 12:37.04 |
| Robin_Watts | cool. All lgtm then. | 12:37.18 |
| | Shall I push them? | 12:37.21 |
| tor8 | thanks | 12:37.21 |
| | go ahead | 12:37.23 |
| Daiz | hi | 13:05.05 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 13:05.05 |
| Daiz | so I'm rendering PDFs to PNGs with ghostscript | 13:05.26 |
| | and I was wondering if it was possible to separately render images, graphics and text | 13:05.41 |
| kens | Not easily no | 13:05.50 |
| | You could hack the PDF interpreter but I wouldn't reccomend it | 13:06.03 |
| Daiz | hmm | 13:06.09 |
| | basically I have pdf files that have large full page background images with text and vector graphics on top | 13:06.27 |
| | and I'd like to render the images and everything else separately | 13:06.35 |
| chrisl | Or you could write your own device(s)..... | 13:06.43 |
| kens | Yes, that would work too, or hacking pdfwrite for that matter | 13:07.05 |
| Daiz | I see | 13:07.25 |
| | just thought it could be possible with some command line options since it's already possible to do things like separate color management for these aspects | 13:07.48 |
| kens | You could alter the definition of the Do operator to a no-op. But removing everything *except* the Do would be harder | 13:07.48 |
| chrisl | Daiz: you can't color manage to "transparent" | 13:08.17 |
| Daiz | yeah, I noticed | 13:08.29 |
| | which is why I came here to ask about it | 13:08.39 |
| kens | Broadly speaking, the colour management deos waht chrisl was suggesting, when writing your own device. | 13:08.50 |
| | It is an internal 'device' which treats the three classes of objects differently. | 13:09.09 |
| chrisl | Daiz: is there a reason you want this? | 13:09.22 |
| Daiz | yes | 13:09.27 |
| | basically I'd like to do image processing on the image parts of the pdfs | 13:09.48 |
| | while doing something different to the vector graphics & text | 13:09.58 |
| | then merge them back together | 13:10.00 |
| kens | Conceptually you could do the same thing with a rendering device. However, you would have to do multiple passes, I think it would be hard to have multiple rendering canvases in GS (though perhaps not impossible) | 13:10.06 |
| | A custom device would let you do the processing on the different elements as (or before) they are nredered, just like the colour management currently does | 13:11.00 |
| | THen you wouldn't need to do multiple rendering passes and a merge | 13:11.14 |
| Daiz | that doesn't really fit my use case | 13:11.54 |
| | basically I work with comic books | 13:12.01 |
| | and I have pdfs as source files | 13:12.27 |
| | that I make lower-res digital image versions of | 13:12.39 |
| kens | Yes..... | 13:12.54 |
| Daiz | the main thing I'd like to do is use different resize algorithms for images and text at certain target resolutions | 13:13.21 |
| | plus being able to render the images and everything else separately | 13:13.42 |
| chrisl | Text is scalable..... or it's not "text" | 13:13.45 |
| Daiz | would also help in the future with multi-lingual stuff | 13:13.55 |
| | the distribution format is plain images so the text gets merged in there | 13:14.32 |
| kens | RIght, so you create a custom device, you interpret the PDF and have a target resolution (already known, as you must set hte resolution before rendering). Then you apply the relevant scaling to the image data before passing it to the GS graphics library | 13:14.34 |
| Robin_Watts | Daiz: So you want to be able to do a Dorling Kindersley and reauthor books in different languages. | 13:14.42 |
| Daiz | well, the multilingual part isn't that important right now | 13:15.14 |
| chrisl | Daiz: so, erm, if the text is in images, how are you going to differentiate between an image that's an image, and an image that's "text"? | 13:15.15 |
| Daiz | the text is actual text in the master pdfs | 13:15.34 |
| | basically right now I'm rendering these PDFs to PNGs at 1200 DPI | 13:16.00 |
| chrisl | So, if you leave that as text, you don't need to worry about scaling it | 13:16.03 |
| Daiz | then do further image processing from there | 13:16.12 |
| | or really, just scaling and compressing to target resolutions | 13:16.24 |
| | chrisl: can't really leave text as text when you're distributing plain image files | 13:16.49 |
| kens | TBH I would expect you would get better results by rendering at the target resolution, though I know some people like anti-aliased text. | 13:17.13 |
| Robin_Watts | Daiz: It strikes me that MuPDF would be a better starting point for this. | 13:17.14 |
| chrisl | Well, don't distribute plain images..... the whole point of PDF is that it's "portable" | 13:17.24 |
| Robin_Watts | You can use the pdf filtering stuff to fairly easily strip all the text/line art/images out of PDFs. | 13:18.06 |
| Daiz | chrisl: that's not really a solution sadly | 13:19.10 |
| chrisl | Daiz: it's exactly what PDF was designed for..... | 13:20.13 |
| Robin_Watts | Daiz: Do you have an example file? | 13:21.42 |
| | It would probably be easier to discuss this with reference to one specific file. | 13:21.59 |
| Daiz | true | 13:22.10 |
| | I do have files but I'll probably need to ask a co-worker to make a special sample file for this | 13:22.39 |
| | anyway | 13:23.55 |
| | https://dl.dropboxusercontent.com/u/144182/166.png | 13:24.03 |
| Robin_Watts | png is no good. | 13:25.02 |
| Daiz | yeah, this is more an example of the end product | 13:25.10 |
| | the original pdf has the big bg image | 13:25.20 |
| | then everything else is vector graphics or text | 13:25.25 |
| Robin_Watts | had an example like this somewhere... | 13:25.34 |
| Daiz | so I render out the PDF at 1200 DPI | 13:25.56 |
| | which I use as a source file | 13:26.07 |
| | to scale down to three different resolutions | 13:26.16 |
| | and for this particular resolution | 13:26.24 |
| | I'd like to use different scaling algorithms for the image and the rest | 13:26.34 |
| Robin_Watts | Strikes me as you'd just be much better using mudraw to render direct to the required resolutions. | 13:26.38 |
| kens | Robin_Watts : but then you could simply use GS the same way | 13:27.01 |
| Robin_Watts | kens: Antialiasing etc is easier/faster with mudraw. | 13:27.52 |
| kens | But it doesn't gice him what he asked for | 13:28.21 |
| Robin_Watts | not to mention image scaling. | 13:28.29 |
| chrisl | It's not exactly tough with Ghostscript...... | 13:28.30 |
| Robin_Watts | true. | 13:28.35 |
| kens | custom algorithms on different types of object | 13:28.38 |
| Daiz | yeah | 13:28.44 |
| Robin_Watts | I'd like to see an example of why he wants it. | 13:28.59 |
| kens | The prototype code for device subclassing would make this trivial, but its not finished yet | 13:29.12 |
| Daiz | ghostscript seems to only offer two kinds of scaling, fast and crappy (which uses nearest neighbor scaling?) and slow and decent (mitchell-netravali scaling) | 13:29.21 |
| chrisl | I've got to think rendering to the right resolution in the first place works best for all object types | 13:29.46 |
| Robin_Watts | so many times we have people coming here saying "I want to do X" when actually when they explain what they want they want something else entirely. | 13:29.51 |
| kens | is inclined to agree | 13:29.58 |
| Robin_Watts | Daiz: Indeed. nearest neighbour or mitchell. | 13:30.07 |
| Daiz | yeah | 13:30.31 |
| kens | with Again, if you want something else, a custom device would let you do it. | 13:30.33 |
| Daiz | I use lanczos for image scaling at higher resolutions | 13:30.39 |
| kens | implemented this years ago (in a different product) for a customer doing medical imaging. Took a matter of hours to knock up the device on that product. | 13:31.34 |
| Robin_Watts | You could bend mupdf or gs to do lanczos. | 13:31.41 |
| Daiz | kens: I guess I might end up looking into that, then | 13:35.09 |
| kens | If you're up for writing some code, and only need PDF input, probably better to look at MuPDF | 13:36.00 |
| | Writing Ghostscript devices is a bit harder (and *looks* much harder) | 13:36.24 |
| | I may implement somethign helpful in this line in a future version of Ghostscript, but it depends on me getting time to finish the code I'm working on. | 13:37.23 |
| Daiz | alright | 13:37.36 |
| | thanks for the help | 13:37.39 |
| Robin_Watts | Daiz: Would still be interested in seeing an example file, and having you talk through what the problems with the existing output is. | 13:39.11 |
| | s/is/are/ | 13:39.21 |
| Daiz | it's not that there's a problem with gs output, but it'd just be nice to be able to render things separately for easier image processing with external tools (imagemagick in my case) | 13:41.18 |
| | ghostscript in itself has already made my life much nicer | 13:42.32 |
| | basically the editors who do the lettering on these | 13:42.48 |
| | work in indesign | 13:42.50 |
| | adobe indesign | 13:42.53 |
| | and the PNG export on that program is a horrible piece of shit | 13:43.14 |
| | that will completely ruin your image quality a lot of the time and just mess things up randomly whenever it feels like it | 13:43.37 |
| | PDF exporting on the other hand doesn't mess things up | 13:43.56 |
| | and ghostscript allows me to render the pages into images from there with no quality issues | 13:44.14 |
| Robin_Watts | Right. But presumably there *must* be quality issues somewhere otherwise you wouldn't be seeking to separate the PDF into different 'layers'. | 13:45.13 |
| | There must be *something* that you feel you can gain by using a more complex workflow. | 13:45.52 |
| Daiz | well | 13:45.57 |
| | it's more that ghostscript doesn't offer the same image processing capabilities as imagemagick | 13:46.35 |
| Robin_Watts | Right, but there must be an issue that drives you to *want* image processing capabilities that gs does not offer. | 13:47.09 |
| Robin_Watts | grabs lunch. | 13:47.14 |
| Daiz | well | 13:47.18 |
| | these black & white pages | 13:47.24 |
| | use screentones | 13:47.25 |
| | and halftone patterns | 13:47.27 |
| | which are pretty hard on image scaling algorithms | 13:47.47 |
| | when you scale them down enough | 13:47.52 |
| Robin_Watts | So don't scale them. Render direct at the required output resolution. | 13:48.14 |
| Daiz | the pages are bitmaps | 13:48.37 |
| Robin_Watts | Or use tiffscaled and render at a far higher resolution than you need, and let that decimate. | 13:48.45 |
| Daiz | so they have to be scaled one way or another | 13:48.50 |
| | Robin_Watts: another thing that makes me use separate image processing - I want to different things to color pages and black & white pages | 14:09.50 |
| | I have a scripting setup that achieves that based on json data about what pages are color & what are black and white | 14:10.20 |
| | anyway, I have a sample pdf for you | 14:11.09 |
| | https://dl.dropboxusercontent.com/u/144182/sidcut.pdf | 14:11.09 |
| | something that also makes me use external image processing is that I can't seem to be able to do stuff like consistent height output with gs | 14:13.23 |
| | like, say I want all my rendered pages to be 1800px in height | 14:13.38 |
| kens | That should not be a problem | 14:13.39 |
| Daiz | but variable width | 14:13.44 |
| | if necessary | 14:13.52 |
| kens | You can't have variable width if you fix the height | 14:14.00 |
| Daiz | there might be pages of different size | 14:14.16 |
| kens | GS can cope with pages of differing sizes. But it won't scale anamorphically | 14:15.07 |
| | You could write PostScript to do so | 14:15.14 |
| | THe -dPDFFitPages code is what does the job | 14:15.25 |
| Daiz | imagemagick has a really handy resolution argument for this | 14:15.38 |
| | you can do -resize x1800 to define just the resize height | 14:15.49 |
| | or you could do 1800x to define width | 14:16.00 |
| kens | Like I said, you can witre code to do it, its not something which is commonly asked for. | 14:16.18 |
| Daiz | well I'm not surprised | 14:16.38 |
| kens | You could calculate it by setting the resolution based on the media size and required hegith | 14:16.42 |
| Daiz | but as I said, my image processing pipeline handles that part already | 14:16.49 |
| kens | A custom BeginPage procedure woudl do the trick easily enough I suspect | 14:17.09 |
| | Look at the requested media size, calculate hte required resolution from the height (or width), add teh /HWResolution key to the page device dictionary and call setpagedevice. | 14:18.10 |
| Daiz | sounds pretty complicated, and even with that I'd end up missing out on other image processing things I do | 14:19.10 |
| | basically right now | 14:19.15 |
| | I render out the source pdfs into 1200 DPI images | 14:19.24 |
| kens | Its trivial to do, I could add it in seconds in your place. Just pointing out that many things are possible with GS | 14:19.40 |
| Daiz | no doubt | 14:19.45 |
| | I'm just terrible at C/C++ | 14:20.09 |
| kens | If the images are always 1800 pixels high, but of variable height, they can't always be rendered at 1200 dpi | 14:20.16 |
| | THat woudl be PostScript, not C :-) | 14:20.31 |
| Daiz | well, add that to the "never even used it" pile | 14:20.44 |
| kens | Almost nobody has, but its a useful language in publishing/printing | 14:21.06 |
| Daiz | anyway, 1200 DPI rendering is for making high res source images to scale down from | 14:22.01 |
| | like if you render the pdf linked above with -r1200 | 14:22.11 |
| | you get 6800x9200 images | 14:22.18 |
| | then I'd run those through my image processing pipeline | 14:22.36 |
| Robin_Watts | Daiz: mudraw -h 1800 -o out.pgm sidcut.pdf | 14:22.48 |
| Daiz | which would make versions in x1800, x2600, x3200 with various kinds of processing depending on whether they're color pages or B&W pages etc | 14:23.09 |
| kens | Its the requirement for different processing algorithms which makes this awkward. TGe other requirements are easy to trivial to handle. But to get different processing you have to get | 14:23.57 |
| | inside the rendering pipeline | 14:24.03 |
| | Like I said, maybe in the next version my code branch will make it to release, in which case I could do it easily afterwards. | 14:24.49 |
| kens | returns to smaking head against wall trying to repair corrupted PDF file. | 14:25.15 |
| Robin_Watts | Daiz: OK, so page 1 of that file - both black and white and color are images. Just the lettering is line art. | 14:27.08 |
| Daiz | exactly | 14:27.34 |
| Robin_Watts | linewise page 2. | 14:27.57 |
| chrisl | Daiz: http://www.ghostscript.com/~chrisl/images002.png | 14:28.46 |
| | http://www.ghostscript.com/~chrisl/lineart002.png | 14:29.12 |
| Daiz | how'd you go about thaT? | 14:29.32 |
| | that* | 14:29.34 |
| chrisl | Postscript programming...... | 14:29.43 |
| henrys | meeting time, Robin_Watts sent out a link about MuPDF vs. Ghostscript, can everyone have a look? | 14:30.28 |
| chrisl | Daiz: So, it's pretty naive, but I'll tidy it up, and you have a play with it | 14:30.49 |
| marcosw | morning | 14:31.28 |
| henrys | kens: I wonder if there couldn't be more pdfwrite stuff in the document or text extraction. | 14:31.28 |
| kens | henrys I'm not sure I follow what you mean | 14:31.55 |
| Daiz | chrisl: would it be easy to make the latter with a transparent BG too? | 14:32.10 |
| henrys | kens: did you read Robin_Watts' document? | 14:32.43 |
| kens | I did yes, I don't now recall the details | 14:32.54 |
| chrisl | Daiz: it might work with pngalpha, but that's well beyond the scope of what I've knocked up just now | 14:33.03 |
| Daiz | okay | 14:33.33 |
| kens | henrys Robin's document does say 'if you want to output to pdf or xps then you need to use Ghostscript' | 14:34.12 |
| henrys | kens: I thought the document was "light" on what pdfwrite is capable of for users and you could improve it. | 14:34.14 |
| | probably no big deal. | 14:34.35 |
| kens | Is it meeting time ? | 14:34.49 |
| Daiz | Robin_Watts: I gave that mupdf command of yours a try | 14:34.56 |
| fredross-perry | howdy all | 14:34.59 |
| rayjj | kens: actually gs can scale x and y independently: -r300x200 will have 300 dpi across and 200 vertically | 14:34.59 |
| Daiz | https://dl.dropboxusercontent.com/u/144182/halftones.png << mupdf output left, -r1200 GS render put through image processing pipeline on the right | 14:35.23 |
| Robin_Watts | It was not intended as a comprehensive guide - just to determine which of mupdf or ghostscript you want for a particular job. | 14:35.26 |
| kens | rayjj yes I know, but you can't do it from teh command line without calculating it yourself, unelss there's an option I've overlooked | 14:35.31 |
| Daiz | if you look at the halftones you can see they have some ugly patterning on the mupdf output | 14:35.54 |
| kens | Robin_Watts : given that you said 'if you need PDF out use GS' I didn't think there was a lot to add..... | 14:36.08 |
| Robin_Watts | kens: indeed. | 14:36.15 |
| rayjj | kens: right FitPage just centers it | 14:36.19 |
| Daiz | that's really why I prefer to have quite precise control over how things are scaled and why I'm using ImageMagick | 14:36.29 |
| kens | Daiz : I see the patterning in both | 14:36.31 |
| Robin_Watts | Daiz: What command line are you using with gs? | 14:36.55 |
| Daiz | gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r1200 -dDOINTERPOLATE -dTextAlphaBits=4 -dGraphicsAlphaBits=4 | 14:37.14 |
| henrys | rayjj: are you happy with the mupdf vs. gs document? | 14:37.18 |
| rayjj | any image that starts halftoned is going to be hard to get "smooth" unless you know the halftone cell size and convert each cell to a contone value | 14:37.42 |
| henrys | it's going in the newsletter, please don't complain afterward. | 14:37.43 |
| rayjj | henrys: I'll have a look and let you know in a few minutes | 14:38.11 |
| kens | henrys I think its a reasonable document, perhaps we can refine it if people ask specifics, or as the products continue to develop | 14:38.30 |
| henrys | marcosw: I assigned a non banding / banding bug back to you now I can't find it. Was it fixed? | 14:38.47 |
| Daiz | kens: well halftone patterns will obviously look like patterns, but on the left the scaling has caused this "grid" like lines to appear in the halftone pattern | 14:38.54 |
| Robin_Watts | Part of the attraction of having it as a Twiki page is that it's 'live'. | 14:39.01 |
| | Any one of us can edit it. | 14:39.11 |
| marcosw | henrys: yes. i thought I updated the bug and closed it... | 14:39.15 |
| kens | Daiz : Yes I see that, but to me both look less than ideal, I'm not going to comment on the differences as I find such thinkgs to be quite subjective. | 14:39.41 |
| | Daiz : if you're happier with the one on the right I won't qwuibble | 14:40.03 |
| | Or even quibble | 14:40.11 |
| Robin_Watts | Daiz: What version of mupdf are you using? | 14:40.11 |
| chrisl | Halftones are resolution specific...... | 14:40.21 |
| Daiz | http://www.mupdf.com/downloads/ << just grabbed the latest windows version from here | 14:40.39 |
| marcosw | henrys: assuming it's <http://bugs.ghostscript.com/show_bug.cgi?id=690993> it's closed. | 14:40.41 |
| Robin_Watts | Daiz: OK. | 14:40.48 |
| henrys | tor8, Robin_Watts are we still on schedule for mid april? | 14:41.01 |
| Robin_Watts | henrys: We are waiting for 1 more fix from tor. | 14:41.14 |
| | Hopefully today, then we can tag and build. | 14:41.23 |
| henrys | it seems there is a lot of new code close to a release ... | 14:41.32 |
| Robin_Watts | Yeah. Shiny! | 14:42.04 |
| mvrhel_laptop | :) | 14:42.12 |
| henrys | mvrhel_laptop: gsview stuff for the meeting? | 14:42.32 |
| Daiz | kens: the thing I'd like to improve with the right is to use a sharper resizer (lanczos) for the text | 14:42.36 |
| Robin_Watts | Daiz: The text is line art. Lanczos doesn't apply here. | 14:43.24 |
| chrisl | henrys: there's the issue with 9.16 that cust 670 raised.... | 14:43.27 |
| marcosw | what are going to do about <http://bugs.ghostscript.com/show_bug.cgi?id=695905>? I feel we need a 9.17 release. | 14:43.35 |
| Daiz | Robin_Watts it would apply if I rendered the text out to a 1200 DPI image first | 14:43.54 |
| kens | Daiz, right now you would have to do coding to get anythign out of either GS or MuPDF. If you're comfortable with C then MuPDF is probably easier to work with. Failing that, then the best I can suggest is waiting for a bit and see if my code matures to hte point of genuine utility. But that will be at least 1 release away, 6 months, maybe more. | 14:44.04 |
| chrisl | marcosw: my feeling is to just do a commercial release, rather than a complete new one.... | 14:44.05 |
| mvrhel_laptop | henrys: Robin and Ken gave me a detailed list of things they found. I am hoping to have almost all of those fixed this week. At that point, I am hoping we can push out the beta. | 14:44.14 |
| | I fixed one of the nastier ones this weekend | 14:44.30 |
| marcosw | chrisl: that's fine as well. | 14:44.34 |
| Robin_Watts | chrisl: Does the bug only show up with luratech? | 14:44.46 |
| chrisl | Yeh | 14:44.51 |
| Robin_Watts | Then that seems entirely reasonable. | 14:44.57 |
| Daiz | kens: alright | 14:44.57 |
| | I might try tinkering with mupdf and see if I can make anything of it | 14:45.12 |
| | if not, then I guess I'll just end up waiting | 14:45.19 |
| chrisl | The code is conditionally compiled if you opt to include luratech, so it's not even there in a AGPL build | 14:45.23 |
| henrys | chrisl: was that a regression? | 14:45.29 |
| chrisl | Yes | 14:45.35 |
| henrys | marcosw: how come the luratech test didn't catch that? | 14:46.13 |
| Daiz | right now this whole thing would mostly be just a matter of slight end product quality improvement | 14:46.22 |
| chrisl | henrys: read your e-mail..... | 14:46.26 |
| rayjj | Robin_Watts: under "banded rendering" we should mention that GS can automatically determine the band height based on a target memory usage taking transparency into account, mupdf requires specifying the band hieght | 14:46.28 |
| Robin_Watts | henrys: see marcosw's mail from last night. His spam filter got in the way :( | 14:46.34 |
| Daiz | it'd probably be a more pressing matter if we were actually doing things in multiple languages | 14:46.38 |
| marcosw | henrys: it did. the email was eaten by the spam filter. | 14:46.41 |
| Daiz | but even then it could be worked around | 14:46.44 |
| rayjj | and I think we should mention DeviceN color support for GS (supporting separations) | 14:46.56 |
| marcosw | I should have noticed that the email was missing and/or manually checked the log files before the release. | 14:47.03 |
| Robin_Watts | rayjj: True. MuPDF requires the caller to calculate the bandheight. | 14:47.25 |
| | rayjj: I think that's in there. | 14:47.53 |
| chrisl | Daiz: I've got some ideas to make my filtering Postscript code more robust..... | 14:48.13 |
| kens | Robin_Watts : I don't see a specific mention of DeviceN, though youy do mention colour management | 14:48.40 |
| Robin_Watts | Ah, the line I was thinking of is under Bitmap output. | 14:49.06 |
| | If you are outputting to a bitmap other than monochrome, greyscale, RGB or CMYK, use Ghostscript. | 14:49.15 |
| kens | MuPDF doesn't do separated output ? | 14:49.17 |
| | Oh right | 14:49.21 |
| henrys | chrisl: I'd prefer we not have two versions out there but your call. We at least need a new commercial version ... | 14:49.52 |
| chrisl | henrys: if you want a full release that will take me all tomorrow.... | 14:50.21 |
| rayjj | Robin_Watts: should we discuss changes, or should I just edit it ? | 14:50.30 |
| kens | THe commercial version differs by having Luratech already, sice that cannot affect the free release, why change it ? | 14:50.37 |
| Robin_Watts | rayjj: Just edit it. | 14:50.38 |
| | I can view the diffs. | 14:50.45 |
| rayjj | Robin_Watts: OK. | 14:50.59 |
| kens | phrased that very badly | 14:51.00 |
| | We already have two versions, the free release and the commercial release. THe bug only affects the commercial release, so changing that will not change the relationship with the free release. | 14:51.47 |
| rayjj | IMHO, just releasing a commercial update makes sense. It also makes it easy to spot customers using the AGPL version wrongly | 14:51.54 |
| henrys | kens: only that I'd like to have one "numbered" revisions out in the wild as current, not 2. But like I said it's up to chrisl | 14:52.07 |
| Robin_Watts | henrys: So 9.18 will be a customer only release. | 14:52.23 |
| kens | henrys I wasn't suggesting a new number for the commercial release :-O | 14:52.24 |
| | I was suggesting replacing the commercial 9.17 release with a different binary | 14:52.40 |
| Robin_Watts | kens: That's bad as early adopters won't know what version they are running. | 14:53.07 |
| chrisl | henrys: since we have customers reporting bugs against versions dating back to 8.64, I think the "more than one version in the wild" ship has saled | 14:53.13 |
| | sailed, even.... | 14:53.23 |
| kens | Robin_Watts : I doubt there are many early adopters | 14:53.23 |
| chrisl | No, I'd make a new commercial release with version 9.17 | 14:53.39 |
| marcosw | kens: The just released version is 9.16. | 14:53.47 |
| henrys | chrisl: I said "as current" | 14:53.51 |
| chrisl | And our development code would move to 9.18..... | 14:53.59 |
| Robin_Watts | D'Oh. Sorry. Exactly what chrisl said. | 14:54.08 |
| kens | Well, whatever people are happy with | 14:54.10 |
| Robin_Watts | I am numerically challenged today it seems. | 14:54.30 |
| kens | Me too I think | 14:54.38 |
| marcosw | chrisl: I agree with your suggestion, 9.16 for the GPL and 9.17 for customers. | 14:54.39 |
| chrisl | henrys: well, the thing is: do you want me to spend a day doing another release (as opposed to an hour)? | 14:55.19 |
| | A commercial 9.17 release can be ready before I finish today, a full release will take me all of tomorrow | 14:56.04 |
| henrys | chrisl: okay just do the commercial... | 14:56.19 |
| kens | Its not like there are big differences between 9.16 and the putative 9.17 | 14:56.24 |
| chrisl | Okay-dokey | 14:56.36 |
| henrys | anything else for the meeting? | 14:57.24 |
| tor8 | Robin_Watts: commits on tor/master for review | 14:57.51 |
| henrys | adjourned .... | 14:58.00 |
| tor8 | adding some basic page margins to the epub viewer | 14:58.01 |
| henrys | tor8: did you get a chance to look at sodapdf? | 14:58.17 |
| chrisl | marcosw: if you hold off replying to Dan, I'll have a release for him to download in a bit | 14:58.19 |
| Robin_Watts | tor8: looking now. There is 1 on robin/master to fix some warnings. | 14:59.00 |
| | hehe, you beat me to the warnings one :) | 14:59.25 |
| tor8 | :) | 14:59.35 |
| Robin_Watts | tor8: Can we not have left and right margins too ? | 15:00.26 |
| tor8 | The left and right margins are already added with the <body> tag. | 15:03.00 |
| | but the body tag top/bottom margins are only added at the very top and bottom of the chapter/document | 15:03.15 |
| Robin_Watts | Gotcha. | 15:03.32 |
| | OK. | 15:03.35 |
| tor8 | eventually I'll implement @page { margin: blah blah blah } in the CSS parser and pass that up somehow | 15:04.30 |
| | and figure out how that interacts with the <body> margins | 15:04.43 |
| Robin_Watts | tor8: All looks good to me. Push away. | 15:04.56 |
| tor8 | but this makes documents at least legible, not having text right up against the top/bottom of the window | 15:05.00 |
| | Robin_Watts: there's a whitespace fix I've done as well | 15:05.10 |
| | just ran all the code through 'git stripspace' and it found some trailing whitespace etc | 15:05.25 |
| | henrys: ah, no. haven't looked at sodapdf yet. | 15:06.00 |
| Robin_Watts | tor8: source/html/TODO probably ought to be in its own commit, not in with the whitespace? | 15:07.04 |
| | But otherwise, looks great. | 15:07.16 |
| tor8 | Robin_Watts: ah, oops! | 15:07.22 |
| | that one shouldn't be in there at all :) | 15:07.27 |
| Daiz | huh, mudraw supports cbz files | 15:22.54 |
| | seems kinda pointless considering you could just extract the images from the zip archive... | 15:23.07 |
| rayjj | Robin_Watts: how come MuPDF and GhostPCL are colored and underlined, but Ghostscript is not ? | 15:23.33 |
| Daiz | and then use whatever image processing tools you have at hand | 15:23.38 |
| chrisl | Daiz: not very convenient for viewing..... | 15:24.15 |
| rayjj | tor8: Robin_Watts: the mupdf/docs/thirdparty still mentions v8 and doesn't mention mujs along with jbig2dec as Artifex libs | 15:24.21 |
| chrisl | Oops, that's probably my fault.... | 15:24.48 |
| Robin_Watts | rayjj: Words which have more than 1 capital in LikeThis are taken to be 'WikiWords'. | 15:25.45 |
| | They are assumed to be links to other articles. | 15:25.57 |
| Daiz | chrisl: true, though I'd say mupdf isn't really the best tool for that :) | 15:26.08 |
| chrisl | Daiz: mupdf is primarily a viewer | 15:26.26 |
| Daiz | I guess we could make a distinction between viewer and reader | 15:26.51 |
| | but anyway cbz is what my end products are (among other things) | 15:27.32 |
| rayjj | Robin_Watts: so if I change it to GhostScript it will be wiki-ized ? | 15:27.35 |
| chrisl | Daiz: I take viewer to be something that displays things on the screen,,,, | 15:27.48 |
| Daiz | which is why I'm rendering things to plain images | 15:27.49 |
| Robin_Watts | rayjj: Yes. | 15:28.31 |
| | mvrhel_laptop: Can you still source copies of MSVC 2010 from your friend without paying a fortune for them? | 15:42.23 |
| | We may want to be obtaining one for Ron. | 15:42.44 |
| rayjj | Robin_Watts: Was there a rhyme or reason to the use of heading 2, 3, or 4 in the body ? | 15:42.47 |
| Robin_Watts | Heading 1 = top one. | 15:43.22 |
| | Heading 2 = sub headings. | 15:43.27 |
| | (like Output options) | 15:43.39 |
| chrisl | marcosw: the 9.17 release is in the customer download area now | 15:43.46 |
| Robin_Watts | Heading 3 = sub sub headings (like Printer Output or Bitmap Output) | 15:43.59 |
| | Heading 4 = sub sub sub headings (like Printer output from bitmaps and Printer output from high level) | 15:44.20 |
| rayjj | Robin_Watts: except Heading 2 is not as bold as Heading 3 or 4 | 15:44.22 |
| Robin_Watts | But it's bigger. | 15:44.35 |
| mvrhel_laptop | Robin_Watts: I doubt they sell it anymore | 15:46.22 |
| rayjj | I think that it's confusing since the "bold" seems to draw the eye. How about I change the Heading 2 to bold ? | 15:46.26 |
| mvrhel_laptop | you can't even buy windows 7 there | 15:46.31 |
| | for some time | 15:46.36 |
| | I could get 2013 | 15:46.54 |
| Robin_Watts | rayjj: You're talking about editing the twiki styles globally? | 15:47.03 |
| mvrhel_laptop | Although 2015 is coming out soon | 15:47.08 |
| Robin_Watts | mvrhel_laptop: We've standardised on 2010 for SOT work. | 15:48.03 |
| mvrhel_laptop | I understand | 15:48.11 |
| | but they don't carry legacy products at this particular store.... | 15:48.40 |
| rayjj | Robin_Watts: no, just in that doc. | 15:48.44 |
| Robin_Watts | rayjj: You're talking about manually adding tags to make the headings bold? No, please don't do that. | 15:49.05 |
| rayjj | Crap I can't undo changes ??? | 15:49.07 |
| Robin_Watts | rayjj: Are you editing in wysiwyg mode? or raw mode ? | 15:49.24 |
| Robin_Watts | uses raw mode. | 15:49.47 |
| | It's really simple text markup. | 15:49.59 |
| rayjj | Robin_Watts: wysiwyg mode | 15:50.22 |
| Robin_Watts | not a clue, then, sorry. | 15:50.33 |
| | One way is to copy your edits into a text buffer, then restart the editing and copy them back. Not ideal, I know. | 15:51.13 |
| rayjj | Robin_Watts: I don't agree that mupdf is better for embedded, so that makes the "Porting" section rather pointless for aiding a decision | 15:56.50 |
| Robin_Watts | rayjj: OK... | 15:58.14 |
| | I think it's clear that MuPDF is a better bet for building viewers from. | 15:59.34 |
| | so a 'Viewer' section would work for me. | 16:00.18 |
| chrisl | Daiz: here my Postscript filtering code (it's a bit more robust that my first punt: it doesn't rely quite so much on the construction of the input file): http://www.ghostscript.com/~chrisl/filter-obs.ps | 16:02.26 |
| | So, you'll call it like this, for example: ./gs -r300 -dFILTERIMAGE -dDELAYBIND -dWRITESYSTEMDICT -sDEVICE=pngalpha -o lineart%03d.png filter-obs.ps sidcut.pdf | 16:03.47 |
| | That will filter out images..... | 16:04.17 |
| rayjj | Robin_Watts: that's mentioned under Interactive Behavior | 16:05.00 |
| chrisl | Or: ./gs -r300 -dFILTERFILL -dFILTERSTROKE -sFILTERTEXT -dDELAYBIND -dWRITESYSTEMDICT -sDEVICE=pngalpha -o images%03d.png filter-obs.ps sidcut.pdf | 16:05.14 |
| | which will filter out line art | 16:05.22 |
| | Oops that should be -dFILTERTEXT | 16:05.44 |
| rayjj | Robin_Watts: I'll go ahead and save my changes and you can have a whack at anything you don't like. | 16:06.04 |
| | I have to run... | 16:06.13 |
| chrisl | Dais: there are almost certainly marking operators that I have forgotten in there, if you use it, and find one I've missed, let me know and I'll tweak it | 16:06.51 |
| rayjj | Robin_Watts: darn. "Invalid Crypt Token". I will have to do this later (again) :-( | 16:07.13 |
| henrys | Robin_Watts: any idea abou the duplicate segments here, http://pastebin.com/Sy4eQPZz ? I posted this yesterday not sure if folks saw it. | 16:14.48 |
| kens | I saw it, but couldn't think of anythign constructive to say | 16:15.17 |
| chrisl | kens: do you know if there's a simple list in the PLRM of marking operators? | 16:15.48 |
| kens | I'm sure there isn't | 16:15.58 |
| chrisl | ah well... | 16:16.16 |
| kens | stroke fill eofill shfill, all the text operators..... | 16:16.43 |
| henrys | getting some coffee bbiam | 16:16.46 |
| chrisl | Yeh, I just realised I'd missed rectfill and rectstroke | 16:17.03 |
| kens | You could try the painting operators for starters I guess | 16:17.14 |
| | ustroke and ufill ? | 16:17.27 |
| Robin_Watts | henrys: That's... odd. | 16:17.32 |
| chrisl | kens: yeh, got those | 16:17.39 |
| kens | image, colorimage,imagemask | 16:17.42 |
| chrisl | And those.... | 16:17.49 |
| Robin_Watts | I'll have a look after I finish talking to Ron. | 16:17.55 |
| chrisl | Missed cshow.... | 16:17.58 |
| kens | well, all the text operators like I said | 16:18.09 |
| chrisl | I don't think the pdf interp uses cshow..... | 16:18.25 |
| kens | GS@s pdf interpreter does | 16:18.34 |
| chrisl | It does?? Wow.... | 16:18.48 |
| kens | Actually I think mayeb I mean pdfwrite | 16:19.09 |
| | No there it is, pdf_show.ps and pdf_ops.ps | 16:19.51 |
| | Its only used in pdf_ops.ps | 16:20.03 |
| | Somethign horrible to do with text show state | 16:20.35 |
| chrisl | Still, I'm a little surprised this works at all, so..... | 16:20.45 |
| kens | Looks like the 'painting operators' andthe marking text operators are it. | 16:21.41 |
| chrisl | glyphshow - I always forget that..... | 16:22.28 |
| kens | THere should be 10 text operators I think | 16:22.58 |
| | Right, I'm off, goodnight all | 16:23.18 |
| chrisl | Daiz: tweaked version with the operators I'd missed. | 16:28.06 |
| Daiz | chrisl: gave it a try | 16:49.19 |
| | it does almost exactly what I want, but it doesn't seem to cover everything | 16:49.32 |
| | even I if set it to filter everything (including FILTERSHOW) I'm still left with something | 16:49.45 |
| chrisl | Daiz: I did say it was a work in progress..... | 16:52.15 |
| | The text coming through *might* be related to caching..... | 16:52.50 |
| Daiz | https://dl.dropboxusercontent.com/u/144182/stuff.pdf << here's what I have left over after using all the filters on a page | 16:54.28 |
| chrisl | I assume that was actually text in the original PDF? | 16:55.02 |
| Daiz | I'm not entirely sure | 16:55.45 |
| | could be vector graphics too | 16:55.48 |
| chrisl | Daiz: Doh! Try using -dFILTERSHOW instead of -dFILTERTEXT | 16:59.11 |
| Daiz | that's what I did | 16:59.23 |
| chrisl | Hmm, I don't see a problem with the example you posted earlier..... | 17:00.03 |
| Daiz | that stuff.pdf is the result of -dFILTERFILL -dFILTERSTROKE -dFILTERTEXT -dFILTERSHOW -dFILTERIMAGE | 17:00.09 |
| chrisl | Can you put the original one up so I can see it? | 17:00.52 |
| | Oh, and what version of Ghostscript are you using? | 17:01.22 |
| Daiz | 9.15 | 17:01.50 |
| | I guess I could try updating to 9.16 | 17:01.53 |
| chrisl | I doubt it would make a difference, in this case | 17:02.10 |
| Robin_Watts | henrys: So... I think we're ready to do a MuPDF release now. | 17:06.17 |
| | or at least a release candidate. | 17:07.14 |
| | marcosw: Do you run any special tests before a mupdf release ? | 17:07.24 |
| Daiz | chrisl: I'll PM you a link | 17:08.53 |
| | as soon as this finishes uploading | 17:09.05 |
| chrisl | Daiz: Okay. I'm going to be running out of time in 15-minutes, so I may have to look at it tomorrow.... | 17:09.40 |
| Daiz | alright | 17:10.05 |
| | thanks a lot for looking into this | 17:10.23 |
| Robin_Watts | henrys: ping | 17:22.21 |
| henrys | Robin_Watts: yes | 17:22.37 |
| Robin_Watts | If I run 0 0 moveto 100 100 lineto stroke showpage | 17:22.44 |
| | I don't get any repeated segments. | 17:22.53 |
| | Actually... let me make sure I'm up to date. | 17:23.12 |
| henrys | so -ZP is different from yours? | 17:23.40 |
| Robin_Watts | Well, I don't have foo.ps to know what you have in it. | 17:23.54 |
| | but yes, assuming foo.ps is just that, it's different. | 17:24.09 |
| henrys | Robin_Watts: it's just that line | 17:24.18 |
| | Robin_Watts: can't imagine a platform issue there. | 17:33.28 |
| Robin_Watts | http://pastebin.com/DZND48Hv | 17:34.23 |
| | Same thing if I use foo.ps | 17:36.22 |
| | You're on a 64bit ubuntu ? | 17:36.56 |
| | What's your default device? | 17:38.16 |
| henrys | x11, but I thought I saw it in ppmraw too | 17:38.42 |
| | yes it is x11 | 17:40.27 |
| Robin_Watts | just spinning the ubuntu update roulette wheel. | 17:40.54 |
| henrys | I do not see the problem with ppmraw | 17:41.06 |
| Robin_Watts | rayjj: I updated the twiki CSS so that all headings are in bold now. | 17:45.43 |
| | henrys: <Smacks Forehead> I just did a release build. | 17:52.09 |
| | rebuilding now. | 17:52.14 |
| | rayjj: I updated the twiki CSS so that all headings are in bold now. | 18:01.46 |
| | henrys: Do you see the problem with the bbox device ? | 18:03.22 |
| | If memory serves, we have 2 ways of handling stroking within gs. | 18:05.16 |
| | I wonder if one device is going one way, and another the other. | 18:05.40 |
| | yeah, the display device ends up using stroke_fill. The bbox device uses stroke_add_fast. | 18:12.27 |
| | henrys: What's the issue with this? Is it just that you don't understand why there is a difference? | 18:12.46 |
| | My Ubuntu box doesn't appear to have the x11 development stuff on. | 18:17.09 |
| | Should I have to ./autogen.sh with --with-x to get X support? | 18:26.24 |
| | My ubuntu box does have the dev stuff, it's just autogen choosing not to enable X support. | 18:26.57 |
| | Nope. I've rebuilt twice now, and I can't get the x11 device to appear. | 18:36.09 |
| xace | Is there a patch for mupdf to jump to the previous page? | 18:37.47 |
| Robin_Watts | xace: On what platform? | 18:38.28 |
| xace | Robin_Watts: linux | 18:38.39 |
| Robin_Watts | left and right don't swap pages for you? | 18:38.53 |
| xace | I mean like, say you click a link in the pdf which jumps you to a different page, I want to be able to hit backspace to jump back to where I was | 18:39.07 |
| Robin_Watts | xace: Oh, I see. | 18:39.16 |
| | No, I don't think so, currently. | 18:39.23 |
| xace | Say there's a index on page 1, and I click on alink which leads to page 32, i wand backspace to take me back to page 1 | 18:39.30 |
| | Alright, maybe I'll write my own patch for this, is there a way to submit it upstream? | 18:39.50 |
| Robin_Watts | actually.... | 18:40.04 |
| | It looks like there is code in there to keep a history of what pages you were on, using m and t. | 18:41.33 |
| xace | don't believe this would be hard to implement; clicking links or using <number>g would just push the current page number to the stack, and backspace would pop and move to it | 18:41.42 |
| Robin_Watts | but that's not hooked up to clicking a link or g. | 18:41.54 |
| | Indeed, it shouldn't be hard. | 18:41.59 |
| | and it would be a good addition. | 18:42.09 |
| fredross-perry | is this something gsview should be doing? I notice that something like it works in Preview. | 18:42.35 |
| Robin_Watts | fredross-perry: It's something I miss massively in acrobat. | 18:43.07 |
| | so yes, having it gsview would be great. | 18:43.13 |
| fredross-perry | probably not hard, I can take a look | 18:43.48 |
| Robin_Watts | xace: The way to submit a patch would be to open an enhancement bug on bugs.ghostscript.com for mupdf. | 18:44.12 |
| | Then add the diff there. | 18:44.18 |
| | There is a form there you need to sign for anything other than a trivial patch. | 18:44.33 |
| xace | alright, ill look at it later this week or next | 18:44.56 |
| Robin_Watts | cool. | 18:45.12 |
| xace | is git/master stable? | 18:45.57 |
| Robin_Watts | chrisl: As far as I am concerned, gs is broken in it's current state with respect to detecting and using x. | 18:46.03 |
| | xace: It certainly should be. We're about to release 1.7 from it :) | 18:46.20 |
| xace | Robin_Watts: sweet, when's 1.7 scheduled for release? if possible i'd like to have this feature included | 18:46.51 |
| Robin_Watts | Fair enough if./autogen.sh fails to detect X11 on my ubuntu box for some reason (can't think why it shouldn't be found, but...) but it's unacceptable that ./autogen.sh --with-x completes without any problems and I still get no x11 devices built. | 18:47.35 |
| | xace: release candidate should be out tomorrow with a bit of luck. | 18:47.52 |
| | xace: In fact, does 't' not work now? | 18:51.35 |
| xace | Robin_Watts: ill see 1 sec | 18:51.45 |
| | 3gmGt < resulted in taking me back to page 3 as expected | 18:52.26 |
| | (keystrokes) | 18:52.42 |
| Robin_Watts | If I load pdf_reference17.pdf, page down a few times to get to the Contents, and click on a link, t takes me back. | 18:53.15 |
| henrys | Robin_Watts: I was concerned all paths had duplicate elements. | 18:53.17 |
| Robin_Watts | henrys: No, I don't believe that is the case. | 18:53.27 |
| xace | Robin_Watts: you are right, that seems to work too | 18:53.42 |
| Robin_Watts | henrys: but nevertheless, I think this has maybe uncovered a bug that should be fixed in the release. | 18:54.49 |
| xace | Robin_Watts: infact, t even goes back to where you <number>g:ed from | 18:54.51 |
| | it even handles history, I guess this feature is already implemented | 18:55.11 |
| Robin_Watts | If I can't figure out how the hell to get x11 devices building... | 18:55.19 |
| chrisl | Robin_Watts: It doesn't check for all the required libs, it's true, because there are masses of them, and I haven't got around to adding the tests for all of them | 19:14.15 |
| | Oh, and unless the X11 libs are in /usr/X11R6 it's not going to work either (which is problem as some OSs have them in /usr/X11R7) | 19:16.33 |
| henrys | chrisl: it sounded like autoconf wasn't building a makefile with X for Robin_Watts , which is just one library but not sure. | 19:17.12 |
| chrisl | I'd assume it wasn't finding the libraries, so not building the devices is the correct behaviour | 19:18.09 |
| henrys | chrisl: well you check 3 libraries but then only look at the Xt variable. I shouldn't say you I believe this predates you. | 19:19.15 |
| chrisl | henrys: that *should* be fine, as Xt depends on Xext which depends on X11, so if the AC_CHECK_LIB(Xt,XtAppCreateShell) succeeds, the preceding tests *should* have also succeeded - but if I were writing it, I would *not* rely on that! | 19:22.14 |
| rayjj | Robin_Watts: ok, I've managed to save my mods to the Twiki. Please review and correct anything you want. | 19:23.23 |
| chrisl | It's not something that comes up often for me since I have to gtk development libs installed, and those pull in all the X11 deps | 19:23.45 |
| rayjj | Robin_Watts: BTW, I wasn't sure about other things that we maybe should say about "Manipulation of PDF files" for MuPDF. Both can add a password, right? And can MuPDF do more (sign it) ? | 19:25.54 |
| henrys | I think it just X11, Xext and Xt. | 19:26.26 |
| | that is needed | 19:26.40 |
| rayjj | henrys: So the GhostScriptOrMuPDF has my input -- just needs Robin's review (you may want to look it over as well) | 19:27.10 |
| henrys | rayjj: okay | 19:27.20 |
| chrisl | The gsx "front end" needs gtk, hence why I have to have that installed | 19:27.28 |
| | henrys: the AC_CHECK_LIB() test adds the -l<lib> to the LDFLAGS hence the order of those three checks, but only checking the result of the final one should be fine, as the Xt test will fail if either of the previous two fail | 19:29.53 |
| henrys | chrisl: makes sense, usually I'd whine it needs a comment but I'll wait until I forget that next time I read it ;-) | 19:32.56 |
| chrisl | henrys: well, as I said, I would not rely on it working like that, personally..... | 19:34.08 |
| henrys | Robin_Watts: is this a side effect of reverse path which is oddly showing up in the X11 path dump | 19:45.47 |
| | ? | 19:46.08 |
| chrisl | henrys: could it be because x11 is also a bbox device? | 19:48.04 |
| | We could be scan converting twice - once for the bounding box, and once to actually draw | 19:49.24 |
| henrys | chrisl: no idea I can look at it easily enough though if Robin_Watts is busy. | 19:49.26 |
| chrisl | Oh, is this x11 or x11alpha? Might be down to the anti-aliasing..... | 19:50.46 |
| henrys | chrisl: how does that explain the duplicate lineto? | 19:50.48 |
| | chrisl: line 62 and 63 for example | 19:51.45 |
| chrisl | henrys: I figured we might clone the path for the bbox operation - it's too long since I looked at that stuff | 19:51.53 |
| henrys | chrisl: your around late? | 19:53.48 |
| | s/your/you're | 19:53.56 |
| chrisl | henrys: I really just stopped in to see if Daiz had found any more quirks with my Postscript filtering code, I saw Robin's comment, and couldn't just ignore it..... | 19:55.02 |
| | I'm half watching a world series squash tournament, too | 19:56.24 |
| | Okay, with the three required X libs installed, the Ghostscript configure detects them, and includes the x11 devices - so is working as intended. The GhostPDL configure script is much less comprehensive in its tests, but I would expect that to result in the x11 devices being included when they shouldn't, not vice-versa | 20:57.01 |
| Robin_Watts | I have a /usr/include/X11 | 23:00.54 |
| | This is the result of running ./autogen --with-x=yes | 23:06.04 |
| | There are no errors in there, and yet I get no X devices enabled at the end. | 23:06.20 |
| | That has *got* to be a bug. | 23:06.25 |
| | henrys: Different devices do stroking in different ways. | 23:07.11 |
| | There are at least 4 different 'line' routines within the stroking code. | 23:07.30 |
| | At least one of them works by building the stroke up in 2 paths; one up each side. | 23:07.56 |
| | When we get to the end we reverse one of the paths and concatenate it onto the other to get the whole path. | 23:08.20 |
| | That's why you see the reverse path. | 23:08.28 |
| | OK. I was missing libxt-dev. With that in the X11 stuff builds. | 23:14.08 |
| | But I still consider it a bug that the autogen did not bale out with an error. It was specifically told to include X devices. If it can't do that, it should error. | 23:14.51 |
| mvrhel_laptop | Robin_Watts: so what do you think should be the "previous page" interface? | 23:20.49 |
| | I like the idea of having that | 23:20.54 |
| | in gsview | 23:20.57 |
| Robin_Watts | mvrhel_laptop: I think backspace should take you back. | 23:21.22 |
| mvrhel_laptop | I quite often want to return after having hit a link | 23:21.34 |
| | ok | 23:21.36 |
| Robin_Watts | yeah. It's something that annoys me intensely in Acrobat. | 23:21.55 |
| | What do the <- -> arrows in the ribbon do on gsview? | 23:22.25 |
| | oh, they just move pages. | 23:23.31 |
| | I guess I'd like an alternative pair of arrows (call them <= and =>) that can move forwards and backwards through the page history. | 23:24.23 |
| | In the same way that they would on a web browser. | 23:24.32 |
| | backspace for <= and shift backspace for => maybe ? | 23:25.02 |
| | dunno if there is a standard binding for that in browsers. | 23:25.10 |
| rayjj | Acrobat _does_ have "Previous View" (a small left arrow icon) and "Next View" icons that are to the right of the last page number in the doc (at least on Acrobat 9). Their next page, previous page are down arrow up arrow icons to the left of the current page # box | 23:54.05 |
| Robin_Watts | rayjj: Just tweaking the twiki page. | 23:54.21 |
| | done. | 23:54.46 |
| rayjj | Robin_Watts: that was quick | 23:54.59 |
| Robin_Watts | I like twikis. So much easier to collaborate on stuff like this. | 23:55.37 |
| rayjj | how do I see what has changed (other than reading the whole thing) or can that not be done | 23:55.52 |
| Robin_Watts | must to bed. | 23:55.54 |
| | rayjj: You can see the diffs at the bottom. | 23:56.04 |
| rayjj | I like the "Input Languages" much better now | 23:56.29 |
| Robin_Watts | Where it shows: r5 < r4 < r3 < r2 the 'r's are the revisions. | 23:56.39 |
| | The '<' are the diffs. | 23:56.46 |
| | We have battling 'colours' :) | 23:57.38 |
| | We should standardise on one. At the moment I've dragged 'em all over to traditional english. | 23:58.15 |
| | Forward 1 day (to 2015/04/08)>>> | |
IRC Logs
