| | <<<Back 1 day (to 2012/05/06) | 2012/05/07 |
| Robin_Watts | while (blah) { ... } while (blah); | 10:11.26 |
| | spot the mistake made while converting from a do { } while () to a while { ... } | 10:11.51 |
| | :) | 10:11.54 |
| mace | neat | 10:35.21 |
| sebras | Robin_Watts: as long as blah == false then that might actually work. ;) | 10:58.00 |
| Robin_Watts | sebras: sadly in just a few cases blah was true. | 11:03.54 |
| | and hence the cluster was timing out. | 11:04.05 |
| kens | ah, that was what it was | 11:04.18 |
| Robin_Watts | tor8, sebras: ping. | 11:54.15 |
| | pdf_keep_obj(obj) starts with an 'assert(obj)'. Can anyone remember why we don't just: if (!obj) return NULL ? | 11:54.44 |
| tor8 | Robin_Watts: We (I) wanted to catch code that didn't deal with missing objects. | 11:55.44 |
| Robin_Watts | so you'd rather it stayed that way ? | 11:56.02 |
| tor8 | not a big deal, and maybe not the brightest idea. | 11:56.10 |
| | I'm not opposed to changing it to be more in line with what we do elsewhere (i.e. silently ignore errors) | 11:56.25 |
| Robin_Watts | pdf_drop_obj copes with NULL obj's. | 11:56.28 |
| tor8 | Robin_Watts: yeah, it didn't use to before we added exceptions | 11:56.43 |
| | I believe the reason for keep/drop not taking null was me trying to catch cleanup errors in a rather roundabout way | 11:57.17 |
| Robin_Watts | Right. It's important that drop_obj should, I feel, because it makes cleanup code MUCH simpler. | 11:57.18 |
| tor8 | indeed. and now we have memento. | 11:57.27 |
| Robin_Watts | I could have believed that the assert was my fault :) | 11:57.35 |
| tor8 | so go ahead and take away the assert :) | 11:57.38 |
| Robin_Watts | OK, ta. | 11:57.43 |
| | marcosw: None of the warnings links from the dashboard are working any more. | 11:58.29 |
| | marcosw: Let me know if I need to rejig the links or something. | 11:58.42 |
| kens | seems to be a problem with overnight tests too | 12:05.02 |
| | I keep getting 'no svn commits' even when there are some | 12:05.12 |
| sebras | Robin_Watts: pong. *reading logs* | 12:08.30 |
| | Robin_Watts: apparently already sorted. | 12:10.06 |
| Robin_Watts | sebras: Yeah, was just checking there wasn't a cunning plan that I was unaware of/had forgotten. | 12:10.36 |
| | Stupid PDF. When you concatenate content streams you have to add whitespace between them so the lexer doesn't get confused. | 13:00.27 |
| | What sort of stupid spec is this. | 13:00.34 |
| Robin_Watts | goes to sulk over lunch | 13:00.44 |
| hexmode | can anyone help us fix colors in pdf thumbnailing on Wikimedia Commons https://bugzilla.wikimedia.org/36580 | 13:55.44 |
| Robin_Watts | hexmode: What are you using to do thumbnailing ? | 13:57.31 |
| hexmode | Robin_Watts: gs | 13:57.47 |
| Robin_Watts | hexmode: What version of gs ? | 13:58.03 |
| | Versions of gs prior to 9.00 will not have handled color profiles correctly, which means you may see slight colour shifts. | 13:59.11 |
| hexmode | Robin_Watts: I'll double check but the cluster runs Ubuntu Lucid by default: http://packages.ubuntu.com/lucid/ghostscript | 13:59.12 |
| | ah, that is prior to 9.00 | 13:59.26 |
| | :) | 13:59.28 |
| | I'll add that to the bug | 13:59.37 |
| | and ask ops to upgrade | 13:59.45 |
| Robin_Watts | BUT... I'd consider using mupdf rather than gs. | 13:59.56 |
| | MuPDF does not handle color profiles either, but for PDF files with text in, the antialiasing given is MUCH nicer (and faster). | 14:00.28 |
| | gs is by far the better choice when running for print output. | 14:01.54 |
| | mupdf is optimised for screen output, so may be a better bet for what you need. | 14:02.16 |
| hexmode | I wasn't aware of MuPDF | 14:03.05 |
| Robin_Watts | Also, it would be good to see the exact command used by the wikimedia cluster, because the options used can have a large effect. | 14:03.12 |
| | muPDF is from the same company that maintains gs, and is released under the same license. | 14:03.41 |
| | That looks a lot like you're rendering to JPEG - the ringing artifacts etc. | 14:04.37 |
| chrisl | It is a jpeg. | 14:09.11 |
| | hexmode: if you are stuck with the GS 8.x (I think in Lucid) you can try using the -dUseCIEColor command line option. | 14:11.18 |
| hexmode | chrisl: that's probably the best shot at this point. tyvm | 14:12.50 |
| chrisl | hexmode: the "heavily compressed" effect is, as Robin_Watts mentioned, because it's jpeg compressed - the solution is: don't use jpeg..... | 14:13.27 |
| hexmode | chrisl: yeah, don't know why they didn't use png | 14:13.59 |
| chrisl | png would be my choice, yes | 14:14.09 |
| hexmode | Robin_Watts: chrisl_away: I'm going to paste the conversation here to the ticket. | 14:22.22 |
| | Robin_Watts: would MuPDF help with non-standard sized PDFs: https://bugzilla.wikimedia.org/33722 | 14:31.09 |
| Robin_Watts | hexmode: Possibly. | 14:39.09 |
| hexmode | maybe gs 9.x, also :) | 14:39.46 |
| Robin_Watts | MuPDF (or mudraw, rather) has the capability to render into a given area, and only use a subarea of that as appropriate for the aspect ratio. | 14:42.14 |
| | or mupdfinfo will give you mediaboxes, so you can make an informed choice of what size to render into. | 14:43.00 |
| hexmode | Robin_Watts: looks like saper (in #mediawiki) is doing some stuff with it, too. | 14:43.11 |
| Robin_Watts | Well, we'd love to hear what he's doing. We're always open to ideas for potential improvements. | 14:44.23 |
| saper | gs 9.05 looks much better - colors are right and no visible JPEG compression artifacts | 14:59.05 |
| | Robin_Watts: I think I could write a small PS routine around the file to clip the image to what we need? | 14:59.59 |
| tor8 | Robin_Watts: sebras: http://mupdf.com/doc/source/mupdf.h (nevermind the color scheme, that's very much a work in progress) | 15:00.45 |
| Robin_Watts | saper: Possibly. Can you state exactly what you want ? | 15:00.49 |
| | tor8: If I follow a link to, say, "pdf_new_null", I am guaranteed that the first line I want to see (the return value) is off the screen. | 15:01.51 |
| tor8 | Robin_Watts: right... | 15:02.12 |
| | I know the decision to do old-style formatting with return values on their own line was going to bite me eventually :) | 15:02.33 |
| Robin_Watts | I have no idea if that's fixable or not, but I thought I'd mention it. It's not a showstopper, but... | 15:02.39 |
| tor8 | s/know/knew/ | 15:02.40 |
| saper | Robin_Watts: there is a small postprocessing step after gs which is using imagemagick convert (-depth 8 -width <somepixels>) - clipping in PS is easy, depth should be possible too... | 15:02.42 |
| Robin_Watts | saper: depth? | 15:03.11 |
| chrisl | bits per sample | 15:03.18 |
| tor8 | Robin_Watts: we can fuzz the line number anchors easily enough | 15:03.21 |
| saper | I wonder if I can ask gs to antialias text? | 15:03.23 |
| Robin_Watts | If you're producing jpeg, then what do you think -depth is going to do ? | 15:03.37 |
| chrisl | saper: -dTextAlphaBits | 15:03.42 |
| | saper: er, -dTextAlphaBits=2 or -dTextAlphaBits=4 | 15:04.11 |
| Robin_Watts | saper: as chrisl, says: -dTextAlphaBits=4 will cause gs to use antialiasing. You can get antialiasing on line art too, using -dGraphicsAlphaBits. | 15:04.35 |
| | tor8: but I like it. | 15:05.29 |
| | (Though not the colors :) ) | 15:05.33 |
| chrisl | saper: the problem you might have is that the GS PDF interpreter normally does a setpagedevice on the PDF bounding box in force (media box or crop box, I think). I don't know if you can override it | 15:05.34 |
| tor8 | no, I'm not too fond of the colors either. but the basic idea I think is neat. | 15:05.48 |
| | just need a bit better control over which identifiers get tagged | 15:06.05 |
| | and to exclude strings from being tagged, but that's not hugely important | 15:06.22 |
| saper | chrisl: I think I can, I think I played with this stuff before | 15:07.02 |
| chrisl | saper: if the worst comes to it, I think there is a way to override what the PDF interpreter does, but it is a bit hacky. | 15:07.57 |
| saper | chrisl: worst case I think I can apply scaling factor to a whole page? | 15:08.40 |
| Robin_Watts | saper: Sorry, I still don't understand what you think -depth is going to do. | 15:09.44 |
| chrisl | saper: IIRC, the setpagedevice will reset the scaling, so no, that wouldn't work. | 15:10.12 |
| saper | Robin_Watts: I think it reduces JPEG color from 24-bit to 8 bit or something | 15:11.16 |
| | (I just figured out that pipeline so I am as new to it as you are) | 15:11.43 |
| Robin_Watts | I don't believe it's a sensible option for jpegs. | 15:12.03 |
| saper | I don't believe either. The file is the same. | 15:12.35 |
| Robin_Watts | jpegs can be greyscale (in which they use 1 plane), or yuv or rgb (in which case they use 3) or some other screwy ones you never see. | 15:12.38 |
| | There is no concept of 'number of bits' per plane in jpeg really. Just the degree of quantisation. | 15:13.07 |
| chrisl | IIRC, ImageMagick will just ignore options that don't apply to the "current" format | 15:13.14 |
| Robin_Watts | All the libs I've ever seen use 8 bits per plane. | 15:13.17 |
| saper | yep | 15:13.18 |
| | so we can ignore that | 15:13.28 |
| Robin_Watts | Right, so it's just a question of clipping/scaling. | 15:13.33 |
| | Which can be avoided by asking gs to render to the right depth in the first place. | 15:13.51 |
| saper | chrisl: -dTextAlphaBits do not improve quality at all; upgrading gs did :) | 15:13.54 |
| Robin_Watts | s/depth/size/ sorry. | 15:14.00 |
| saper | I guess we'll just skip that -depth thing | 15:14.19 |
| Robin_Watts | saper: If you want better text quality, then use mupdf. | 15:14.34 |
| chrisl | saper: it might be because there's transparency. | 15:14.48 |
| Robin_Watts | chrisl: Or it may be that gs is rendering large, and imagemagick is scaling it down, and so they are getting antialiasing that way. | 15:15.17 |
| | BUT... outputting pdfs to jpegs is a bad idea, IMHO. | 15:15.47 |
| | jpeg compression does horrible things to sharp edges (such as you get in text). | 15:16.06 |
| | It will drastically reduce readability. | 15:16.15 |
| chrisl | Robin_Watts: I meant I suspect GS might be not be anti-aliasing because of the transparency in the file | 15:16.16 |
| Robin_Watts | chrisl: Right, I understood. I was just saying that there are other explanations for the aa settings not changing the output significantly. | 15:17.08 |
| chrisl | Robin_Watts: Oh, okay - I still prefer not to anti-alias text, anyway | 15:18.05 |
| Robin_Watts | For thumbnailing, antialiased text looks WAY more readable, IMHO. | 15:18.38 |
| chrisl | For an actual thumbnail, most text should be completely illegible, whether aa'ed or not | 15:19.16 |
| | saper: to override the PDF page size with your own, you should be able to set your own page size on the command line, and use the "-dFIXEDMEDIA" option | 15:21.38 |
| Robin_Watts | OK, s/readable/aesthetically pleasing/ then. | 15:21.46 |
| saper | it's for pretty generic media repository, so I don't know what's in the PDF... I guess most files contain text, but don't have to be | 15:22.02 |
| | chrisl: will try right away | 15:22.12 |
| chrisl | saper: you'll still need a little PS snippet to move the origin so that the correct part of the page gets rendered | 15:23.02 |
| saper | chrisl: I think I need it scaled | 15:23.22 |
| chrisl | saper: don't "scale", change the resolution | 15:23.51 |
| saper | postscript is such a nice language, pity it is not used more | 15:26.31 |
| chrisl | It's rare for Postscript to be described as "nice"! | 15:27.09 |
| hexmode | saper: new ps code is written probably millons of times a day | 15:27.23 |
| saper | hexmode: by automatons : | 15:27.35 |
| hexmode | granted | 15:27.40 |
| saper | I once delivered a 30kb PS program that produced 800 pages to the printshop | 15:28.20 |
| chrisl | I wouldn't really count the output of drivers and applications that as "new" Postscript..... | 15:28.41 |
| saper | chrisl: I have some Forth and a bit of functional background, so switch to PostScript concepts was easy... | 15:29.39 |
| hexmode | chrisl: saper just said "used more often" .... ;P | 15:30.08 |
| chrisl | saper: I think Postscript is a nice language, too, it's a shame so many producers take such awful liberties with it, though..... | 15:31.20 |
| saper | it gets re-invented all the time | 15:32.07 |
| | (see cairo) | 15:32.11 |
| | the only thing I really miss is "just there" Unicode support | 15:32.30 |
| chrisl | I don't know what the latest cairo output is like, but the stuff I've seen is just like our ps2write output: Postscript code to parse PDF style streams. | 15:33.26 |
| saper | oh by the way I have a different question | 15:34.26 |
| | I was looking at some ways to preserve PDF file annotations << ... /FS ... /Subtype /FileAttachment >> when doing pdf->pdf in gs | 15:37.28 |
| | pdf_main.ps defines /annottypes to handle various annotations, so I suppose I would need to add support for /FileAttachment there. I have no idea though how to copy a stream from input pdf file into output | 15:40.02 |
| chrisl | saper: you probably need to attract kens's attention for these questions....... | 15:41.47 |
| saper | I am afraid I am missing some part of the "big picture" to understand this. What I want to do is to be able to "gs -sDEVICE=pdfwrite one.pdf second.pdf" and still keep /FileAttachments there | 15:42.13 |
| chrisl | saper: since I think we (currently) ignore FileAttachment annotations, there may not be a built-in way to do it (there may not be *any* way to do it, as things stand) | 15:43.42 |
| saper | no there is no built-in way | 15:44.11 |
| | I have patched /annotypes to copy all other items from the dictionary and it even works | 15:44.38 |
| | but the stream is the problem, since I kind of... don't know how to navigate the input file... | 15:45.08 |
| | I see that gs even keeps old stream numbers (from the original input file) but it skips that attachment stream (which contains xml in my case) | 15:45.56 |
| | which is reasonable given nothing references it | 15:46.10 |
| chrisl | saper: even if you could navigate the input, I doubt there would be a way to push it through to pdfwrite. | 15:46.22 |
| | saper: given that you are starting with a PDF, why "re-fry" it? | 15:48.24 |
| saper | tried using /copy_embedded_file but didn't get very far with it | 15:48.28 |
| | chrisl: I'm merging them for example... | 15:48.53 |
| | do I understand it correctly that pdf_*.ps family of scripts converts the PDF stream into some kind of set of PostScript structures so that pdfwrite *might* pick up some PDF-specific staff and re-insert them into the output? | 15:51.00 |
| | s,staff,stuff, | 15:51.16 |
| chrisl | saper: the Ghostscript PDF interpreter is implemented in Postscript, if that's what you mean. | 15:52.07 |
| Robin_Watts | tor8: ping - bug 693029 - is that another thing where the tag needs setting ? | 15:53.09 |
| saper | that's what I mean byt pdf_*.ps files | 15:53.18 |
| chrisl | saper: right, so I don't really know how that "communicates" with pdfwrite for anything other than page marking operations. | 15:54.31 |
| Robin_Watts | saper: The gs pdf interpreter is a postscript program that reads through PDF files, and renders them by calling postscript operators (including some ghostscript specific extensions to postscript). | 15:54.47 |
| | If there is extra information in the PDF file that you want to be passed through to the final PDFs it's not clear that that will happen. | 15:55.31 |
| | Normally the pdf interpreter only reads and passes on the stuff that's essential to the printed output. | 15:55.52 |
| | It's possible that some other things may be handled, but Ken/Alex are the people to ask about that - I suspect that in general the answer is no. | 15:56.19 |
| kens | Its Alex's pigeon | 15:56.29 |
| saper | I think .writepdfmarks is the magic procedure | 15:56.33 |
| kens | very little is handled | 15:56.34 |
| | outlines and some annotations, mainly links I thikn | 15:56.51 |
| saper | % Test whether the current output device handles pdfmark. | 15:57.06 |
| Robin_Watts | kens: Fair enough. I figured you might know from being the pdfwrite guy. | 15:57.14 |
| kens | for general pdfmarks, you ned to look at gdevpdfm.c which has a list | 15:57.20 |
| Robin_Watts | 5pm already. crumbs. | 15:57.59 |
| chrisl | kens: it supports annotations - I'd assume it would just dump out the contents of the pdfmark parameters? | 15:59.27 |
| kens | pdfwrite supports pdfmark, the PDF interpreter uses it to handle *some* PDF content | 15:59.57 |
| | but not very much | 16:00.16 |
| chrisl | Yeh, I was just thinking if the worst came to it, a two step process could be used: pdf_info.ps gives a template for getting (meta)data from a PDF, and then an annotation pdfmark to push the info through to pdfwrite | 16:01.53 |
| kens | better too add to interpreter | 16:02.11 |
| saper | kens: thank you, this is what I was looking for... so I need to secure passthrough on the input side (in pdf_*.ps code) and proper annotation output in gdevpdfm.c | 16:02.35 |
| chrisl | saper: I suspect it's just the input side you have to worry about | 16:06.50 |
| saper | well not sure, I need to copy reference to a stream | 16:07.06 |
| kens | sapre sorry, my attention was diverted. | 16:07.06 |
| | THe code you want should be added to the PDF itnerpreter I believe, it an enhancement request. | 16:07.35 |
| saper | kens: it's IRC, it's free support channel | 16:07.37 |
| kens | I menat you can open one :-) | 16:07.51 |
| saper | kens: I did some preliminary code on the input side, I only can't "copy" a stream into the dictionary, since it's not serializable | 16:08.18 |
| kens | Alex would know how I don't :0-( | 16:08.31 |
| saper | there is a similar one already for PDF forms | 16:08.32 |
| | there is even a bounty for it :) | 16:08.41 |
| kens | form one is a bit different ethat's nine | 16:08.55 |
| chrisl | saper: you might be able to get the stream into the dictionary by using either a subfiledecode or a reusablestreamdecode filter | 16:09.39 |
| saper | chrisl: looks promising! | 16:15.03 |
| kens | I think the PDF interepreter has a means for this already, but I am not the expert. | 16:15.15 |
| | which is why I would suggets alexcher | 16:15.29 |
| chrisl | kens: I fixed the FAPI problem with the MM font - I'm surprised the code worked for any MM fonts, but it clearly did (coincidentally, I feel). | 16:20.06 |
| kens | wow | 16:20.16 |
| | I'll have to take a look at teh code.... | 16:20.25 |
| chrisl | The code for writing out the $Blend was ignoring name objects | 16:20.47 |
| kens | Oh I see. that looks like a silly oversight | 16:20.49 |
| chrisl | Yeh, I'm not sure why the "boiler plate" procedure is in there, so I didn't want to just rip it out, yet | 16:21.31 |
| kens | I'd gues you're right, its because the code didn't work/wasn't present to handle the original. | 16:22.02 |
| | I hope it wasn't me that added that :-( | 16:22.17 |
| chrisl | I didn't check - but without a PS interpreter the actual procedure will never be used...... | 16:22.48 |
| kens | I think that's always true isn't it ? You need a PS interpreter for $Blend ? | 16:23.16 |
| | Which is why they always *are* boilerplate, because you can't guarantee a real PS itnerpreter. | 16:23.33 |
| | Same as the fixed /Subrs and stuff | 16:23.45 |
| chrisl | Sort of - I think Freetype uses the *presence* of $Blend for something, but not the content | 16:24.01 |
| kens | I think its presence means that FreeType uses the 'default' one that Adobe fonts have. | 16:24.25 |
| | Rather thhan the embedded one :-) | 16:24.32 |
| | Like the fixed Subrs, if you use them they have a defined value these days | 16:24.46 |
| | I hink $Blend is the same. It seems like a good idea to use PS in there, until you realise that not all fonts run on PS interpreters.... | 16:25.13 |
| chrisl | I *think* it uses the presence of the $Blend as one of the indicators that's a MM font, along with a couple of other things | 16:25.23 |
| kens | OK I'm off, goodnight all | 16:47.41 |
| Robin_Watts | tor8: Bug 693028 - we get an error while reading the page content stream (can't read any of it), so we don't write anything. | 16:52.38 |
| | The bug reporter would clearly rather we output an empty page, rather than not outputting anything. | 16:53.03 |
| | Do you have an opinion ? | 16:53.09 |
| | I'm tempted to leave mudraw producing no output, but to make mupdf cope better. | 16:54.01 |
| sebras | Robin_Watts: what is the object mudraw is trying to parse? | 16:54.55 |
| Robin_Watts | sebras: The page content stream is non existent. | 16:55.18 |
| tor3 | Robin_Watts: bug 693029 is because I haven't uploaded linux binaries | 16:55.48 |
| Robin_Watts | Ah. Are you intending to ? | 16:56.07 |
| tor3 | I'm not particularly fond of linux binaries; and they have been downloaded very rarely in the past | 16:56.40 |
| Robin_Watts | So... is there a link somewhere that lead him to believe they would be there? | 16:57.00 |
| tor3 | yeah... on the main home page >.< | 16:57.27 |
| Robin_Watts | So.. remove the link, and everyone is happy :) | 16:57.41 |
| tor3 | so, remove the link or compile some binaries? | 16:57.42 |
| Robin_Watts | remove the link (or tweak it and the text to point at the .tar.gz) | 16:58.02 |
| tor3 | anyone on linux should be capable of compiling their own software, or get it from their package manager :) | 16:58.09 |
| Robin_Watts | I agree. | 16:58.17 |
| sebras | Robin_Watts tor3: especially since mupdf nowadays is part of ubuntu/debian which is did not use to be.... | 16:58.19 |
| | Robin_Watts: that russian pdf was a tough download... | 16:58.49 |
| Robin_Watts | mmm | 17:01.01 |
| sebras | Robin_Watts: luckily I'm in .se so my pipe is faster than yours... >;-) | 17:02.50 |
| Robin_Watts | I visited my parents in law yesterday. His broadband is running at 0.22Mbps. | 17:03.22 |
| tor3 | cue the my pipe is fatter than yours jokes... okay maybe not | 17:03.25 |
| Robin_Watts | I booked an engineer to come see him on wednesday :) | 17:03.33 |
| sebras | smart move. :) | 17:03.43 |
| Robin_Watts | tor3: I had questions about bug 692028 just before you logged in as tor3. | 17:05.47 |
| | I have changes to pdfapp here that seem reasonable; if the fz_load_page fails, then it's a fatal error. | 17:09.34 |
| | If the fz_run_page or the fz_load_links fails, it just displays the best it can with a warning alert. | 17:09.55 |
| tor3 | hm, expected object number 0? | 17:10.06 |
| Robin_Watts | Bad error message. | 17:11.49 |
| | tor8, sebras: I've just pushed 2 commits to my repo on casper. | 17:19.57 |
| tor3 | Robin_Watts, yeah. and the file is full of zeroes in the middle. | 17:20.11 |
| Robin_Watts | The first changes mupdf to read from content streams on the fly (for pages, xobjects, patterns, but not for type3 fonts). | 17:20.35 |
| | This passes a cluster test with 1 progresssion (now we get a (blank) page out where we didn't before). | 17:21.02 |
| | The second fixes bug 692028. | 17:21.16 |
| | If no one spots any problems/raises any objections within 24 hours, I'll push them to master. | 17:21.56 |
| | If you want more time, just say. | 17:22.02 |
| sebras | Robin_Watts: actually I thinkg that might be a good idea for _all_ patches, so we avoid breaking HEAD... ;) | 17:23.49 |
| Robin_Watts | sebras: I test everything on the cluster before pushing. And yet still I break stuff :( | 17:24.33 |
| sebras | I only do harmless patches myself. ;) | 17:24.58 |
| Robin_Watts | If you're not digging up at least one bit of foundation in a patch, then what's the point? :) | 17:25.23 |
| sebras | :) | 17:26.09 |
| Robin_Watts | Besides, we have you to fix our stupid mistakes. Speaking of which I'm looking at your git repo now... | 17:28.47 |
| | the first patch seems very sensible. | 17:28.54 |
| | I can believe the second one is useful too - can mupdfshow usefully show you things about objects even when it can't decrypt them? | 17:29.45 |
| sebras | Robin_Watts: at least the trailer. | 17:31.44 |
| tor3 | Robin_Watts, all but stream contents and strings. | 17:31.46 |
| | so not much, but still better than nothing :) | 17:31.58 |
| Robin_Watts | ok. | 17:32.01 |
| Robin_Watts | pushes those 2 then - thanks. | 17:34.03 |
| sebras | Robin_Watts: oh.. I didn't read your message from 17:28 until now. :) | 17:35.24 |
| tor3 | Robin_Watts, your last patch, pdf_parse.c error messages. "%d %d ?"? | 17:36.18 |
| Robin_Watts | Yes. | 17:36.29 |
| | tor3: It means "I've read %d %d, but then I got something unexpected." | 17:36.54 |
| tor3 | and we usually just say "%d 0 R". I keep wondering if we can completely get rid of generation numbers or not... | 17:36.55 |
| | ah, you mean that way! | 17:37.05 |
| kammerer | Hi all, on rendering some pdf scale_row_from_temp function from draw_simple_device.c crash my application, but same function from draw_scale.c works fine. Is there any hardware resriction to use draw_simple_device version? | 17:37.21 |
| Robin_Watts | kammerer: Urm... draw_simple_scale.c and draw_scale.c ? | 17:37.53 |
| sebras | Robin_Watts: but.. PDF_TOK_OBJ isn't R, it's obj... | 17:37.54 |
| Robin_Watts | sebras: right. | 17:38.13 |
| | It's attempting to parse an image "10 0 obj" etc | 17:38.44 |
| | s/image/object/ | 17:38.58 |
| tor3 | our error messages usually say (%d 0 R) to mention an object by number | 17:39.12 |
| Robin_Watts | I can barely cope with 1 conversation at a time, 2 is clearly too much :) | 17:39.15 |
| | Right, but previously we were reporting (%d %d R) where %d and %d had never been read! | 17:39.42 |
| sebras | Robin_Watts: also me and tor3 (and tor8?) agree on who should be spamming you. ;) | 17:39.54 |
| tor3 | yeah, and that's all bad. | 17:40.06 |
| kammerer | Robin_Watts: yes | 17:40.22 |
| Robin_Watts | tor3: If you would prefer a different error incantation, then feel free to take my patch, and commit a fixed one. | 17:40.42 |
| | That's probably the easiest way. | 17:40.50 |
| | kammerer: draw_scale and draw_simple_scale should do exactly the same thing - except one uses ints and one uses bytes to hold intermediate values. | 17:41.18 |
| | If one crashes, then it's pure luck that the other one doesn't. | 17:41.31 |
| sebras | also there should be only on fz_load_links in pdfapp_loadpage... | 17:41.34 |
| tor3 | Robin_Watts, nah, they're fine. just looked a bit odd at first glance. | 17:41.43 |
| Robin_Watts | so we should understand what's causing the crash. | 17:41.53 |
| tor3 | but that patch may need some more work | 17:42.02 |
| Robin_Watts | sebras: oops. fixed now. | 17:42.35 |
| kammerer | Robin_Watts: is there any simple way..something like traces in asm code? | 17:43.01 |
| Robin_Watts | kammerer: Just a tick. | 17:43.12 |
| | Is this a repeatable crash ? | 17:43.21 |
| | kammerer: At the top of draw_simple_scale.c put: #define DEBUG_SCALING | 17:44.11 |
| | then run the code, putting stderr to a file. | 17:44.45 |
| | THen when it crashes, mail me a copy of that file. | 17:44.55 |
| kammerer | Robin_Watts: ok, thx | 17:45.54 |
| tor3 | something I've wanted to do with broken pages is replace them with a page containing the error message | 17:46.22 |
| | but that's a bit of a tall order right now | 17:46.31 |
| Robin_Watts | tor3: Yeah, we need a layout engine for that. | 17:46.42 |
| tor3 | any reason we shouldn't just warn and make blank pages for all broken pages? | 17:46.51 |
| | regardless of how or where they are broken | 17:47.06 |
| Robin_Watts | tor3: no. | 17:48.40 |
| | except we may not have a page->bbox ? | 17:49.07 |
| | I guess we can fake one. | 17:49.17 |
| | Updated patch online. | 18:07.24 |
| | kammerer: File received. | 18:51.54 |
| mvrhel_laptop | lunch time | 19:26.01 |
| | Forward 1 day (to 2012/05/08)>>> | |
IRC Logs