| | <<<Back 1 day (to 2012/06/21) | 2012/06/22 |
| Robin_Watts | I don't object, but that probably ought to be run past tor8. | 00:10.04 |
| sebras | Robin_Watts: of course. | 00:30.46 |
| chrisl | kens: ping | 07:03.14 |
| kens | chrisl pong, sorry, was readin code | 07:04.49 |
| chrisl | No worries - I think I have an inkling about the actual problem with this vertical writing crap | 07:05.19 |
| kens | really ? I'm fascinated :-) | 07:05.31 |
| chrisl | I think pdfwrite is failing to correctly set the matrix for descendant fonts | 07:05.46 |
| kens | That's entierly possible, it hadn't occured ot me to look | 07:06.03 |
| | you think they should be something different to what's emitted ? | 07:06.21 |
| chrisl | No, this is when interpreting the file | 07:06.46 |
| kens | Ah, well its possible | 07:07.00 |
| chrisl | If you dump the current matrix in the CDevProc in one of our problem files, and compare the results from pdfwrite and ppmraw, you should see what I mean | 07:07.19 |
| kens | OK wait a moment | 07:07.40 |
| chrisl | For example, with documentsPS-cut2.ps ppmraw gives me: | 07:08.18 |
| | [0.0 -14.999999 -14.970499 -0.0 239.0 565.0] | 07:08.20 |
| | [14.970499 0.0 0.0 -14.999999 254.0 565.0] | 07:08.22 |
| | [0.0 -14.999999 -14.970499 -0.0 265.0 565.0] | 07:08.24 |
| | But pdfwrite gives me: | 07:08.42 |
| | [0.49999997 0.0 0.0 -0.49999997 0.0 3299.99976] | 07:08.44 |
| | Note: in ppmraw there is a rotation involved | 07:09.09 |
| kens | Well, I'm not at all sure why that would happen, the CTM isn't under pdfwrite's control. Hmm, or is it.... | 07:09.12 |
| chrisl | Yes it is, just a sec..... | 07:09.25 |
| | For the *rendering* code case, see base/gxchar.c show_state_setup() | 07:10.11 |
| kens | OK one sec | 07:10.19 |
| | Ah, I see its setting gs_setcharmatrix or gs_setcurrentmatrix | 07:11.12 |
| | Presumably this isn't called for a pdfwrite device | 07:12.17 |
| chrisl | Yep, and then in show_proceed() line ~1199, sorts out the char_tm into the ctm for the actual glyph rendering | 07:12.19 |
| | No, pdfwrite does (or fails to do, in this case) all this stuff for itself | 07:12.45 |
| kens | I'm not surprised, I would have expected the interprete to handle all of this | 07:13.08 |
| chrisl | So, the point is, I don't think we are ignoring vertical metrics, but pdfwrite isn't getting them rotated in the same way as the rendering world | 07:13.42 |
| kens | I'm not sure that explains the file with the difference, because the characters were still in the correct ori=entationbut maybe. | 07:14.41 |
| chrisl | The characters will be, because pdfwrite isn't rendering them, it's pulling the glyphs (and matrices) straight from the font | 07:15.24 |
| kens | OK so you think that the problem is the rotation isn't applied to the *widths* as a result of CDevProc ? | 07:16.18 |
| chrisl | Yes, exactly | 07:16.28 |
| kens | So we don't need to go through the complex stuff the rendering code does | 07:16.48 |
| | We just need to apply the correct matrix when scaling the widths | 07:16.58 |
| chrisl | Yes, you can probably do it that way - which would save a complication I stumbled across...... | 07:17.31 |
| kens | And also it need only apply tot he CDevProc result | 07:17.36 |
| chrisl | Yep | 07:17.42 |
| kens | Right, so that does make it easier, I can pull the matrix and apply it to the CDevProc results and tehn just proceeed | 07:18.05 |
| | Now all I need to do is work out *which* matrix :-) | 07:18.26 |
| chrisl | Or which combination of matrices..... | 07:18.51 |
| kens | Well all of that. | 07:18.57 |
| | Obviously this normally works correctly | 07:19.29 |
| chrisl | Normally, descendant fonts have a trivial matrix...... | 07:20.11 |
| kens | Yes, I take it this one doesn't | 07:20.23 |
| chrisl | As noted, there's a rotation..... | 07:20.45 |
| kens | BTW when you say 'problem files' which problem file are you referring to ? I have 2 different ones. | 07:20.54 |
| | Make that 3 because one fo them works that didn'[t before | 07:21.12 |
| chrisl | Your test3.ps and my documentsPS-cut2.ps | 07:21.19 |
| kens | That's 2 different files for me now :-) | 07:21.51 |
| | My test3 is different | 07:21.57 |
| | I presume you mean the customer file rather than the regression file | 07:22.11 |
| chrisl | Neither of the files above are in the regression suite | 07:22.48 |
| kens | Like I said, I re-used the test3.ps filename its now a cur down version of one fo the regression files. | 07:23.13 |
| | OK yours is the (C) file | 07:23.36 |
| chrisl | Yes | 07:23.50 |
| kens | I was thinking of a different file which has rotation in it | 07:24.16 |
| | Still, taking the verticla metrics from teh CDevProc as gospel is clearly wrong, one fo the regression files fails if that is done. | 07:25.07 |
| | Great, we don't have the text enumerator here in PDF land, its at a higher level | 07:26.10 |
| chrisl | Well, there is *nothing* in the rendering code that checks for the presence or otherwise of metrics *after* the CDevProc, nor checks the font type before using the CDevProc results | 07:26.57 |
| kens | Well, that's interesting. I'll have to see what happens with the other regression file later. | 07:27.26 |
| chrisl | The test file you sent me that happened to be called test3.ps also loses rotation in the descendant font using pdfwrite (in that case, the rotation doesn't change per glyph, but it still goes awry) | 07:29.38 |
| kens | COuld be. Debugging my way through the rendering code right now | 07:30.13 |
| | Trying to figure out what matrix I need and how to apply it.... | 07:30.26 |
| chrisl | I'm guess this was a situation that was missed or not considered when this code was updated to handle the CDevProc callout | 07:33.06 |
| kens | Yes, probably, as you say its rare. Though in this case it seems to be the parent font which is rotated, not the descendant | 07:33.36 |
| | Err no, it is the descendant | 07:34.06 |
| chrisl | Basically, if the descendant orientation doesn't match the parent, we'll likely get the wrong result for the PDF metrics | 07:34.53 |
| kens | Yes | 07:34.59 |
| | The code has no provision for rotation at all. It looks like it simply doesn't expect it | 07:35.21 |
| | It does deal with scaling | 07:35.32 |
| | If I look at the original font it does have the rotation in int | 07:36.29 |
| | The copied font dooes not.... | 07:36.48 |
| chrisl | The "original" font? | 07:36.49 |
| kens | In pdfwrite | 07:36.55 |
| | We make 2 copies | 07:37.00 |
| | In this case the copied font has a FontMatrix of 1 0 0 1 0 0 | 07:37.17 |
| | The original hgas 0 1 -1 0 0 0 | 07:37.37 |
| chrisl | Hmmm, I guess is might not matter, that may "fall out" in the wash when the composite font is emitted] | 07:38.05 |
| kens | Possibly, not sure yet. | 07:38.19 |
| | THere is some scaling comparison going on to scale the CDevProc result form the original font to the copied font | 07:38.44 |
| | But its *only* scaling as far as I can see | 07:38.53 |
| chrisl | There is at least one file I looked at which has the ctm rotated, so it *looks* like the parent font is rotated and the descendant font isn't, which confused me for a while | 07:39.30 |
| kens | Hum, that's *really* weird | 07:39.32 |
| | The original font has *2* FontMatrix entries | 07:39.50 |
| | FontMatrix and orig_FontMatrix | 07:39.57 |
| chrisl | Yeh, I though you added orig_FontMatrix? | 07:40.11 |
| kens | FontMatrix is 0 1 -1 0 0 0 | 07:40.14 |
| | orig_FontMatrix is 1 0 0 1 0 0 | 07:40.23 |
| chrisl | I don't think orig_FontMatrix is relevant here | 07:42.42 |
| kens | But its what we are using :-) | 07:42.53 |
| | We aren't using FontMatrix | 07:43.00 |
| chrisl | Oh, maybe that's the problem? | 07:43.33 |
| kens | I'm thinking it might well be | 07:43.42 |
| | Because we are applying it to the CDevProc result | 07:43.50 |
| chrisl | It's possible orig_FontMatrix needs to be used when falling back the "default" case | 07:44.21 |
| kens | I think we may need the orig when not applying CDevProc yes, but probably we should use the real FontMatrix for the CDevProc | 07:44.51 |
| | results | 07:44.57 |
| | Hacking this in the debugger is too painful, lets try some quick code | 07:46.14 |
| chrisl | Actually it was Igor that added the orig_FontMatrix - and miraculously he's given a bug and test file to reference! | 07:46.45 |
| kens | Astounding, I didn't think it was me.... | 07:46.58 |
| | which bug number ? | 07:47.10 |
| chrisl | For some reason, I though you'd added during the FAPI debacle - but you must have just tried using it..... | 07:47.32 |
| | Ghostscript Bug 686970 | 07:47.43 |
| kens | Thanks, let me go look.... | 07:47.51 |
| chrisl | Also: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ede8bba9d8b | 07:48.38 |
| kens | already there, bug report has SVN link | 07:49.03 |
| | The commit message is, well sparse.... | 07:49.36 |
| | Well I'm not at all sure what that actually fixes. | 07:51.14 |
| chrisl | At least it gives you another couple of test files to look at..... | 07:51.31 |
| kens | I'm going to apply the FotnMatrix instead of orig_FontMatrix to the result from CDevProc, and see what that does. | 07:51.35 |
| | I'm kind of alarmed by those fixed '1000.0' numbers as well. | 07:52.19 |
| chrisl | Yes, I didn't think that would work in the general case, especially for TTF outline fonts - but..... | 07:54.06 |
| kens | Exactly, it looks wrong to me.... | 07:54.31 |
| | But its worked OK so far. | 07:54.37 |
| | coffee, quick! | 07:55.28 |
| chrisl | agrees | 07:55.37 |
| kens | Hmm, interesting glyph_orig_matrix seems to cater for descendant fonts | 08:07.54 |
| | But only for type 1 fonts | 08:08.21 |
| | ie regular CIDFonts, not TrueType ones | 08:08.33 |
| | Ah, because attemptinh to use cidata.glyphdtaa on a TT font seg faults :-) | 08:10.33 |
| | Looks to me like this is missing the else clause from show_state_setup | 08:10.56 |
| | Which uses currentcharmatrix. I wonder if we should simply use the FotnMatrix. | 08:11.26 |
| chrisl | kens: note that you'll have to be careful because unlike the rendering code, pdfwrite doesn't gsave/grestore around the glyph "rendering"...... | 08:18.35 |
| kens | I think that's OK its only the widths I'm meddling with, and only the calculation of those | 08:19.00 |
| | Getting some truly weird results :-) | 08:19.46 |
| chrisl | Okay. Well, I tried a quick hack earlier, changing the ctm, and things exploded | 08:20.10 |
| kens | Well I'm getting inexplicable results, *some* glyphs are changing orientation, I've no idea why. | 08:20.49 |
| chrisl | Eh? How is that possible if it's only the calculation of the widths you've changed?!? | 08:21.38 |
| kens | Good question..... | 08:21.47 |
| | I did say 'inexplicable' | 08:21.53 |
| chrisl | "pdfwrite - the 'Outer Limits' of the software work" :-( | 08:22.54 |
| | (I couldn't say "Twilight Zone" as that's already taken by Truetype......) | 08:23.44 |
| kens | Hmm, I see a ppossible reason | 08:23.52 |
| | Err no I take that back | 08:24.08 |
| chrisl | Oh, for heaven's sake: I wonder why we have an 80 page file in our test suite | 08:25.21 |
| kens | To test lots of pages ? | 08:25.39 |
| chrisl | Well, 80 isn't really "lots", in this context - if it was 8000, I could see that..... | 08:26.16 |
| kens | Oh, looks like meddling with teh widths has modified the text matrix, that's 'surprising' | 08:27.33 |
| chrisl | Good news is that UFST now works in PS/PDF with the "New World FAPI" - and that's including downloaded fonts (UFST 6.x). And gets the "correct" output for all of comparefiles...... | 08:28.16 |
| kens | oooh... | 08:28.26 |
| chrisl | I'm rather pleased with that :-) | 08:28.46 |
| kens | I would think so too | 08:28.54 |
| chrisl | On to PCL, I suppose...... | 08:29.10 |
| kens | wonders why altering the widths rotates the text matrix | 08:29.20 |
| chrisl | thinks: because you're working in pdfwrite........ | 08:29.49 |
| kens | One day I'll be allowed out.... | 08:30.03 |
| chrisl | No' 'fraid not - you've been too clear and vocal about how horrid it is, now no one else will touch it! | 08:30.54 |
| kens | :-( | 08:31.08 |
| chrisl | Maybe when you've mostly de-Igor-ized it...... | 08:31.43 |
| kens | I suspect my will to live will expire before then | 08:32.03 |
| chrisl | Ah, I see Avadhut has once again been studying "How to make friends and influence people"...... | 08:33.08 |
| kens | What another email ? | 08:33.18 |
| | Oh yes, escalate instantly.... | 08:33.35 |
| chrisl | Yes - "why haven't you answered my last e-mail yet?" | 08:33.36 |
| | The answer is quite simple, though: those are contrib devices, and we can't ship contrib with the commercial distribution | 08:34.12 |
| kens | I thought it was probably something like that | 08:34.29 |
| | Though his mail suggests they were tehre before, were they using the GPL release ? :-) | 08:34.45 |
| | I see fomr the headers he can't even wait 24 hours before escalating. | 08:35.12 |
| chrisl | Very likely. They may, in fact, be entitled to use the GPL release, because I'm not sure they redistribute GS? | 08:35.32 |
| kens | I have absolutely no idea, and treasure my ignorance on teh subject :-) | 08:35.55 |
| chrisl | :-) Well, I'm replying to support - I *definitely* don't want him getting my e-mail address! | 08:36.25 |
| Robin_Watts | Morning paulgardiner | 09:27.16 |
| | You never need to CC me on bugs; we all get all the bugs anyway. | 09:27.32 |
| paulgardiner | Hi. Oh ok | 09:27.43 |
| | I seem unable to assign them to myself | 09:27.56 |
| Robin_Watts | I added a function to get past the fz_buffer_printf overflow with %s last night. | 09:28.01 |
| paulgardiner | Yes. Looks great | 09:28.13 |
| Robin_Watts | but, as I say in the report, we then hit problems elsewhere. I need to discuss that with tor8. | 09:28.32 |
| Robin_Watts | does the tor8 summoning dance... | 09:28.42 |
| paulgardiner | Your other commit confused me a bit in mujstest having escapte and unescape. Is that because mjs files use escaped text? | 09:29.06 |
| | I think you cast the wrong spell. | 09:30.06 |
| Robin_Watts | When I write text strings to an mjs file, I have to make sure that I write \n instead of character 13 etc. | 09:30.18 |
| paulgardiner | Robin_Watts: ah good. That's what I hoped was the reason | 09:30.35 |
| Robin_Watts | and when I read them back, I have to convert back. | 09:30.41 |
| | yeah, it's a separate issue. | 09:30.52 |
| | I'm going to dive into the shower then think about this lexing thing again - hopefully tor8 will reappear. | 09:31.31 |
| chrisl | I suspect "diving" into the show may be a mistake..... | 09:32.41 |
| | s/show/shower | 09:32.47 |
| paulgardiner | Sounds advice | 09:35.21 |
| | s/s// | 09:35.30 |
| chrisl | Seems like we're all having a bad spell...... ;-) | 09:36.08 |
| paulgardiner | 11/12 correct letters. That's pretty good for me. | 09:42.10 |
| UweS | Hi! | 09:47.19 |
| | Is a mupdf-developer around here? | 09:47.31 |
| kens | Hmm they will be back shortly | 09:47.48 |
| | What is your question ? | 09:47.53 |
| UweS | Actualy, I have some complaints ... ;-) There have been several changes in the version jump to 1.0 which are really strange and uncomfortable... | 09:49.33 |
| kens | Well, you want tor8, but he just disconnected. | 09:49.57 |
| | Feel free to voice complaints, but I cannot make any promises that anything will change | 09:50.16 |
| UweS | Hm. | 09:50.24 |
| kens | The changes would have been for good reasons | 09:50.33 |
| UweS | I hope so. Otherwise they make really no sense! | 09:51.06 |
| kens | Wihtout knowing what is causing you a problem, I can't relaly comment | 09:51.24 |
| Robin_Watts | UweS: So, what are your issues. | 09:51.40 |
| | Morning tor9 | 09:51.56 |
| tor9 | Hi. | 09:52.05 |
| kens | Oh, tor8 got bigger | 09:52.07 |
| paulgardiner | Great! I've been waiting for the new version. :-) | 09:52.28 |
| kens | Well UweS hte people you want to shout at are ehre now :-) | 09:52.44 |
| tor9 | :) smaller actually. Mobile irc. | 09:52.44 |
| Robin_Watts | ircing from a phone ? | 09:52.45 |
| tor9 | So pardon the slow typing | 09:53.19 |
| UweS | Why for example do I have to press 'H' and 'W' for fitting the pdf in the window. That is really strange. It would be much better to use small type letters | 09:53.29 |
| Robin_Watts | h and w are already used? | 09:53.46 |
| UweS | So that I dont have to press two keys the same time | 09:53.54 |
| | yes | 09:54.06 |
| tor9 | w is already in use to fit the window to the page | 09:54.23 |
| Robin_Watts | So, we've 'added' H and W. That can't possibly be any worse than pre 1.0 where those keys (and hence the fitting functionality) didn't exist at all before. | 09:55.10 |
| kens | had been expecting coding complaints rather than UI | 09:55.18 |
| Robin_Watts | too | 09:56.08 |
| UweS | but it does not work for me... :-/ | 09:56.10 |
| | Sorry, I'm not a developper, but i want to give you some constructive feedback from the "user side" | 09:56.45 |
| Robin_Watts | UweS: Can you give a coherent bug report? File to load, buttons to press, an exact clear explaination of what you expect to see and what you actually see? | 09:57.16 |
| UweS | btw: I'm using the 1.0 stable version of mupdf in the official gentoo tree | 09:57.34 |
| kens | I suspect by 'doesn't work' he means 'I don't like it' | 09:57.48 |
| | ? | 09:58.10 |
| UweS | Sorry, I was not clear - it really does not work | 09:58.28 |
| kens | Ah, was puzzled because you seemed to be saying that you didnt' like the key assignments | 09:58.48 |
| Robin_Watts | UweS, well, either you should retest using our sources, and give us a clear bug report, or you should give a clear bug report to the gentoo package maintainers, and they will report upstream to us. | 09:58.57 |
| UweS | Example: I compile a pdf with latex (A4 size) and use mupdf for viewing. pressing w does not fit the pdf in the mupdf window. I still have to scroll down to see the bottom of the page. | 09:59.54 |
| Robin_Watts | While we clearly want to produce the best software we can, we don't have time to investigate vague reports, or to check specific derived versions. | 09:59.55 |
| kens | UweS I'm not an expert, but I woudl expect 'w' to fit the width | 10:00.26 |
| | and 'h' to fit the height | 10:00.34 |
| Robin_Watts | kens: No. | 10:00.39 |
| kens | :-) | 10:00.48 |
| Robin_Watts | 'w' turns on shrinkwrap mode. h scrolls left. | 10:00.50 |
| kens | ah, OK | 10:00.57 |
| tor9 | Are you using a tiling window manager or a too small screen? | 10:00.59 |
| Robin_Watts | 'W' zooms to fit window width | 10:01.03 |
| | 'H' zooms to fit window height. | 10:01.14 |
| kens | Well, there you go, and H what you said | 10:01.19 |
| tor9 | hjkl to make vi users comfortable | 10:01.53 |
| kens | and everyone else uncomfortable :-) | 10:02.05 |
| | But I cna cope, I play nethack | 10:02.15 |
| UweS | I know. But wouldn't it be easier if I just have to press one button, not two? (shift and 'h'). | 10:02.19 |
| kens | UweS so are you sayign that you don't like the key assigment, or that using the proper key doesn't work ? | 10:02.38 |
| UweS | It was possible one time with 'z' but this is not possible any more | 10:02.44 |
| tor9 | including me, hjkl doesnt work too well in vi either if you use dvorak | 10:03.00 |
| UweS | kens: 'H' works, but I think this is just an uncomfortable shortcut. | 10:03.37 |
| kens | UweS, so back to what I was saying, when you say 'doesn't work' you mean @I don't like it' | 10:03.58 |
| | If you use the 'correct' key, then the software works as expected ? | 10:04.21 |
| tor9 | Robin_Watts did you have a programming question, or why the summoning spell? | 10:04.42 |
| Robin_Watts | tor9: I do. | 10:04.49 |
| | I ran into a problem last night when I fixed a SEGV with one of the patches on my casper repo. | 10:05.20 |
| | We used to buffer overflow when writing more than 256 char strings. | 10:05.32 |
| UweS | kens: :-/ Sorry. My fault. I was just sticking to German... | 10:05.46 |
| Robin_Watts | I fixed that, and now we hit problems while lexing back those same > 256 char strings. | 10:05.50 |
| kens | UweS Ich kann auch ein bisschen Deutsch sprechen | 10:06.24 |
| UweS | kens: Super! :-) | 10:06.40 |
| Robin_Watts | The pdflexbuf things have a scratch space at the end of the structure. | 10:06.46 |
| | IN the main lexing loop those are 65536 in size. | 10:06.57 |
| tor9 | Writing? Oh, pdfclean? | 10:07.02 |
| | Hm, escaped chars at the 256 byte border? | 10:07.04 |
| Robin_Watts | but in various other places they are only 256. | 10:07.04 |
| kens | The key assignments are really up to tor8 and co, but they are never going to satisfy everyone | 10:07.12 |
| | tor8 looks like you need to reconsider flexible key bindings in the viewer :-) | 10:07.30 |
| Robin_Watts | tor9: No, when paulgardiner synthesises an appearance stream, he outputs strings as: | 10:07.49 |
| | "(%s) Tj" | 10:07.55 |
| | using fz_buffer_printf. | 10:08.08 |
| tor9 | Robin_Watts yes, of course... D'oh! | 10:08.15 |
| Robin_Watts | yeah, it's an easy fix (and I correctly escape strings now too) | 10:08.32 |
| | but when we read those strings back in, we overflow the scratch space. | 10:08.56 |
| kens | back in a moment, more ocffee needed | 10:09.09 |
| UweS | Another problem with mupdf 1.0 is that the mousewheel couldn't be used to jump between different pdf-pages. Why is that. I thinkg, with earlier pdf-versions it was possible? | 10:09.12 |
| tor9 | kens, indeed. Ugh, config files... :( | 10:09.15 |
| Robin_Watts | so I think we need to move to a system where the scratch space can be dynamic. | 10:09.19 |
| tor9 | Robin_Watts, right. | 10:10.06 |
| paulgardiner | Robin_Watts: for multiline text I now split the sentence into words, which perhaps I should for single-line too. Of course that doesn't help if we have >256-char words | 10:10.42 |
| Robin_Watts | paulgardiner: Yeah, having such long strings is unusual (which is why we haven't hit this before), but we should cope. | 10:11.27 |
| paulgardiner | I'm just wondering why mupdf hadn't run into this problem before, and it could be because of the splitting into words | 10:11.28 |
| | snap | 10:11.38 |
| | >256-char words could be harmlessly split too | 10:12.20 |
| tor9 | paulgardiner, in the usual case we use the big 64k lexbuf | 10:12.52 |
| Robin_Watts | How do we know 64K is enough? | 10:13.32 |
| paulgardiner | oh! Not sure why I used 256 without alarm bells ringing | 10:13.37 |
| sebras | tor9: have you bought yourself a new computer? tor_9_!? | 10:14.11 |
| tor9 | Robin_Watts, 64k is pdf spec limit | 10:15.16 |
| | It's odd if we dont check for overflow and crash instead | 10:15.49 |
| Robin_Watts | It's an implementation limit, not a spec limit. | 10:16.25 |
| | We do check for overflow. | 10:16.29 |
| | but we get errors as the parsing fails. | 10:16.46 |
| | so we don't SEGV any more, but we don't get the expected results. | 10:17.10 |
| UweS | If you want to make mupdf a little bit better to use, please change the behaviour of the space key: | 10:18.00 |
| | When a pdf-dokument is fitted to its width and I have to press 'space', mupdf should scroll down! Only, when space is pressed again, go to the next page. | 10:18.00 |
| | Is it clear, what I mean? | 10:18.30 |
| paulgardiner | A fix that would at least mean the forms code wasn't adding any further limits would be to use a 64k buffer and split words out correctly in all cases. Plus split at 64k boundaries if necessary | 10:20.02 |
| UweS | It is so cumbersome that the 'space' key does not scroll the page down and after that it changes the page. This is in particular cumbersome if you are working on a laptop with a narrow screen | 10:20.31 |
| Robin_Watts | paulgardiner: Yes. Let me solve for the 256 limit case first though :) | 10:21.21 |
| | UweS: MuPDF is primarily a library that handles core PDF tasks. | 10:22.07 |
| sebras | UweS: a GTK-based viewer is being worked on, so I would not expect any significant changes to be done to the x11 viewer. | 10:22.12 |
| UweS | If anyone of you ever used the good old xpdf you would know what I mean. ;-) Thanks so far. | 10:22.13 |
| Robin_Watts | We have a simple viewer that sits on top of that. | 10:22.19 |
| kens | Anyone a fan of 'The Avergae White Band' ? Or even remember them ? | 10:22.27 |
| Robin_Watts | As sebras says, we have a new GTK based viewer coming, so we are unlikely to make any changes to the existing viewer. | 10:22.55 |
| | but feel free to submit a patch. | 10:23.03 |
| UweS | Ah, ok. | 10:23.12 |
| | Nice to hear. | 10:23.18 |
| paulgardiner | Somehow a 64k buffer seems ok for the initial parseing, but it seems a big allocation to make regularly just for pulling info out of a default appearance stream and the like | 10:23.23 |
| Robin_Watts | If you can give us a nice patch to do what you want that doesn't make it hugely more complex. | 10:23.35 |
| | paulgardiner: No, I'm going to change to a system where we initially allocate 256 bytes, and can grow it as required while parsing. | 10:24.01 |
| paulgardiner | Robin_Watts: oh ok. That's good | 10:24.18 |
| UweS | But actually I don't understand, why you are programming a gtk viewer. mupdf is perfekt. Just its behaviour is sometimes strange... | 10:24.35 |
| paulgardiner | I'll fix the splitting into words at some stage. I do it for multiline already | 10:24.44 |
| Robin_Watts | UweS: Form filling. | 10:25.37 |
| sebras | UweS: and the search box. | 10:25.54 |
| paulgardiner | kens: I think I liked them back in their day if I'm remembering correctly. I have this recollection of their really not sounding like a white band | 10:26.00 |
| Robin_Watts | The UI changes to support form filling are easiest done (cross platform) by moving to GTK. | 10:26.08 |
| kens | soul and disco paulgardiner | 10:26.16 |
| | Just been sent a link by Roger Ball: | 10:26.37 |
| | http://www.youtube.com/watch?v=JD-jEuczpZ4 | 10:26.37 |
| | and: | 10:26.48 |
| | http://www.youtube.com/watch?v=474pXbXgc6U | 10:26.48 |
| paulgardiner | Oh yeah. I remember that track. | 10:27.07 |
| Robin_Watts | has image of paulgardiner in a disco shirt, split to the navel. aargh. How can I claw my minds eye out? | 10:27.12 |
| kens | plenty of alcohol to assist memory erasure | 10:27.29 |
| paulgardiner | Robin_Watts: Hey. I wanted that image no more than you did. | 10:28.30 |
| | I would have been 14 | 10:29.29 |
| kens | In 1991 ? | 10:29.56 |
| paulgardiner | kens: No :-) Original release | 10:30.36 |
| kens | ah, I thought it unlikely someone that young would even know who I was talking about | 10:31.00 |
| UweS | Again I'm really sorry for asking this: But _why_ are you doing this? Evince for example already can fill out forms and has a search function. In my point of view (Note: I'm a user, not a programmer!) I would use mupdf just because it is extremely fast and very simple. The form filling and also the search function is already available in other gtk pdf-viewer programs. | 10:33.06 |
| kens | UweS MuPDF is commercial as well as open source | 10:33.39 |
| | Commercial customers need this capability | 10:33.55 |
| | Also, why would we not ? Just because someone else does ti already | 10:34.09 |
| UweS | Don't get me wrong, I really like what you are doing. But please don't forget the usability of the simple viewer | 10:34.12 |
| | kens: This is not what I ment. Ok. I didn't thought about the comercial issues. Sorry. | 10:35.24 |
| | So, have a nice day and weekend. By! :-) | 10:36.48 |
| kens | Bye UweS | 10:36.57 |
| UweS | bye ;-) | 10:37.01 |
| chrisl | Hmm, great, Oracle have dropped support for "legacy" SPARC hardware in Solaris 11....... | 11:08.44 |
| Robin_Watts | Following on from what we were talking about the other day: http://www.theregister.co.uk/2012/06/22/reg_standards_vid/ | 11:17.00 |
| kens | yes, watched it earlier :-) | 11:26.35 |
| chrisl | The most interesting part for me (having lived there for a year) was finding out why Basingstoke so closely resembles a nuclear wasteland - it *is* a nuclear wasteland! | 11:33.51 |
| Robin_Watts | OK. cluster test running for the reworked parsing. | 12:33.37 |
| | lunchtime. | 12:33.42 |
| scott-san | Regarding MuPDF, I have a potential customer that is asking~"do we have a stable version that can be implemented as part of an HTML 5 app? He's interested in an XPS web viewer for iPad. Comments? | 12:42.31 |
| kens | scott-san : I'd have thought MuPDF 1.0 woudl be stable enough to experiment with, but obviously I'm not the expert | 12:46.43 |
| scott-san | Hi Ken, This person is wanting to license MuPDF and probably is not interested in experimenting. Just wants to know if it's ready to go. This is the first question of this kind that I've received ~ regarding XPS-HTML5. | 12:48.47 |
| kens | scott-san : sorry I misread your question, but I still think 1.0 is as stable as anything. | 12:49.21 |
| | I know the version number is 1.0 but that doesn't really reflect its maturity | 12:49.44 |
| scott-san | Thanks. Here's exactly the way this guy poses his question: "Thanks for the response. Before we start filling all this out. We had a simple query with regard to your xps viewer. Do you have a stable version that can be implemented as part of an HTML5 app or is this still only an iOS app at this stage. | 12:51.18 |
| kens | Well MuPDF itself is cross-platorm, and they won't (obviously) be using the viewer, so yes its stable, and no its not just an IOS app (given it runs on WIndows, Mac and Linux) | 12:52.32 |
| | I'd be happier if tor or Robin hgive you an answer though | 12:52.52 |
| scott-san | OK, thanks Ken. I'll leave this up until they eventually come on. Thanks for your help. Have a nice weekend. | 12:53.32 |
| kens | you too scott | 12:54.37 |
| | scott-san : it just occured to me that your potential customer may be looking for something that runs in JavaScript or something similar. That is, something which is executed by the HTML5 browser, rahter than being written in C and compiled for each platform | 13:05.34 |
| scott-san | This I don't know. I'll forward his query to Robin and see if he can open a dialog with this guy and get to the bottom of it. Thanks. | 13:07.32 |
| kens | NP | 13:07.49 |
| Robin_Watts | morning scott-san | 13:24.34 |
| | It sounds to me like his question is no so much about stability, as it is about whether our app can be run as part of an HTM5 app. | 13:26.02 |
| | HTM5 app. | 13:26.06 |
| | HTML5 app, even. | 13:26.12 |
| | Unfortunately, "can be implemented as part of an HTML5 app" is a pretty meaningless question without more details. | 13:26.41 |
| scott-san | Hi Robin. Had an interesting query from a guy regarding MuPDF and HTML 5. I just sent you his query via email. If I could trouble you to respond, it would be helpful. Thanks. | 13:26.44 |
| Robin_Watts | I will read the email and reply. | 13:26.57 |
| | The short answer is probably no. We do not have an out of the box solution that can be used from HTML5. | 13:27.18 |
| scott-san | Thanks Robin and you too Ken. Hope you guys have a great and sunny English weekend! | 13:27.36 |
| Robin_Watts | haha! | 13:27.54 |
| | you too. | 13:28.02 |
| scott-san | Oh hell, no problem here. I believe we're going to get our first triple digits this weekend. Summer is definately here in North Texas. | 13:28.47 |
| chrisl | It's just started raining here - again..... :-( | 13:32.21 |
| Robin_Watts | scott-san: reply sent. | 13:43.28 |
| | Scott: Possible support contact? http://bugs.ghostscript.com/show_bug.cgi?id=693148 | 13:44.18 |
| scott-san | Thanks for the info Robin and the email reply. | 13:51.02 |
| chrisl | I'm off to take a neighbour to the hospital (I seem to do that surprisingly often!) - not sure when I'll be back..... | 13:58.27 |
| scott-san | How do I get this guy's email address from Bugzilla?? | 14:00.49 |
| Robin_Watts | Look at the CC field, and it says "Carlos" | 14:03.52 |
| | Click on that and you should get a mailto: window pop up with his address on it ? | 14:04.14 |
| kens | Or just hover mouse over the name | 14:08.15 |
| | got to go, g'night all have a good weekend | 14:51.15 |
| scott-san | Adios guys and thanks for all the help | 14:56.08 |
| Robin_Watts | night scott-san | 14:58.18 |
| scott-san | are you still on Robin? | 14:59.08 |
| Robin_Watts | I am. | 14:59.14 |
| scott-san | Well, I've opened up the bugs.ghostscript URL and hovered over and clicked on everthing there and don't see or come up with an email address. What am I doing wrong? | 15:00.04 |
| Robin_Watts | Ok, top right side of the page, you should see: | 15:00.38 |
| | "Reported: 2012-06-22 13:01 UTC by Carlos" | 15:00.52 |
| | Carlos should be in Blue ? | 15:01.07 |
| scott-san | Hold on while I try it | 15:01.28 |
| | I see that but I cannot hover over it or click on it. | 15:02.22 |
| Robin_Watts | What browser are you using? | 15:02.39 |
| scott-san | Mozilla | 15:02.48 |
| jen_ | http://pastie.org/4132764 -->need some help. | 15:03.25 |
| Robin_Watts | scott-san: Ah. If you're not logged into bugzilla, you can't get his email address. | 15:03.43 |
| | Do you have a bugzilla login? | 15:03.48 |
| scott-san | Well hell, I don't think so. All I did was double click on the URL above that you sent. | 15:04.23 |
| Robin_Watts | (without logging in "Carlos" will just be in black) | 15:04.35 |
| scott-san | You are correct sir! | 15:04.44 |
| Robin_Watts | Sorry, I thought henrys set you up with a bugzilla log in a while ago for exactly this reason. Let me check... | 15:04.58 |
| | ok, I can't find where to hunt for existing bugzilla accounts, so let's assume you haven't got one, and set one up for you. | 15:08.42 |
| | (I mean, I could just tell you his email address, but it'd probably be better if you could see them for yourself in future, right?) | 15:09.14 |
| scott-san | OK. Just let me know what to do, I'm all yours. | 15:09.30 |
| Robin_Watts | http://bugs.ghostscript.com/createaccount.cgi <- Go there | 15:09.42 |
| | Enter your preferred email address. | 15:09.54 |
| | click the button, and then wait for an email. | 15:10.09 |
| chrisl | jen_: as before, not a Ghostscript error, you need to ask where they know (a lot more) about python | 15:10.43 |
| jen_ | hi chrisl I guess I'm confused about the USEUNICODE option...sorry. | 15:11.40 |
| scott-san | OK Robin that's all done and I've received the email and created a password. What is the URL. bugs.ghostscript.com?? | 15:12.30 |
| Robin_Watts | If you click back on: http://bugs.ghostscript.com/show_bug.cgi?id=693148 | 15:13.24 |
| | then in the top light blue bar there should be a "Log in" link ? | 15:13.46 |
| chrisl | jen_: the USEUNICODE stuff is a new feature that there's been some debate about - hence it being disabled by default. But our Unicode code doesn't produce that error message | 15:13.51 |
| scott-san | Thanks Robin. Got it all and the email address. Have a good weekend. | 15:17.04 |
| Robin_Watts | scott-san: Fab. Now we can assign bugs to you :) | 15:17.23 |
| | (Maybe we should assign bugs to you if we think they need a support contract before we'll look at them?) | 15:18.07 |
| scott-san | This has always been a thought. Clearly, once you show them some form of support they are less likely to hear from me. The problem is that I've been told that on many ocassions it is something that you want to fix as it is pertinent to the development of GS. | 15:20.14 |
| | Less likely to WANT to hear from me. | 15:20.30 |
| Robin_Watts | Yes. Lots of times we get bugs in and we want to fix them. Other times we get bugs in, and we REALLY don't want to have to touch 'em with a bargepole :) | 15:20.59 |
| | sebras, paulgardiner: Either of you about ? | 15:21.52 |
| paulgardiner | I'm here | 15:22.02 |
| | ish | 15:22.14 |
| Robin_Watts | paulgardiner: Can you spare a few minutes to look over a change for me? | 15:22.19 |
| paulgardiner | Sure | 15:22.27 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=7fe60543d8dbe090406a1ee536cdcb9a91fa4d1e | 15:22.46 |
| paulgardiner | I have a couple of commits on casper too if you have a moment actually, but not important. | 15:22.53 |
| Robin_Watts | paulgardiner: Cool. | 15:23.08 |
| | I've just cluster tested my stuff and it comes back with 2 files changed, but I can't reproduce the differences - I think it's down to a different version of thirdparty being used between manual and automatica cluster tests. I've just corrected that so the next commit should test it. | 15:24.11 |
| paulgardiner | pdf_xref.c has init with no fin. Is that ok? | 15:30.19 |
| Robin_Watts | no, not ok. nice catch. | 15:31.29 |
| paulgardiner | pdf_lex used to return vals from an enumerated type, but now returns a length, yet calls to pdf_lex don't look to have changed much | 15:35.45 |
| | Ah no. Ignore that | 15:36.15 |
| Robin_Watts | lex_string and lex_hexstring used to return a length - they now return the enumerated thing (and hence admit of tail call recursion by the compiler) | 15:38.40 |
| paulgardiner | yeah | 15:38.50 |
| | You memcpy newsize in pdf_lexbuf_grow. Is that right? | 15:40.00 |
| | I'd expect lb->size | 15:40.28 |
| Robin_Watts | ooh, right again, thanks. | 15:41.29 |
| paulgardiner | Might be safer to make condition on freeing scratch be scratch != NULL, but maybe not. | 15:42.19 |
| | No. | 15:42.32 |
| | Forget that | 15:42.35 |
| | Shouldn't read the code backwards :-) | 15:42.49 |
| | Changing buffers with += seems a bit odd, but I may be missing why that's best. | 15:46.02 |
| Robin_Watts | paulgardiner: Because at some point we may want to grow the buffer before s is at the end. | 15:46.26 |
| | so we want to update s to allow for any movement in the basic buffer position. | 15:46.57 |
| | And the easiest way I could see to do that was returning a ptrdiff_t | 15:47.15 |
| paulgardiner | Oh yes. I was missing that you were letting s continue it's iterating. That's sneaky | 15:47.23 |
| | i = (s - lb->scratch); frow(); s = lb->scratch + i; would have been the non-sneaky approach I guess | 15:48.54 |
| | s/frow/grow/ | 15:49.03 |
| Robin_Watts | yes. | 15:49.10 |
| | which I find more confusing than s += ... | 15:49.23 |
| | Your changes look fine. | 15:51.13 |
| | I've just pushed an update to my casper repo with both your and my changes on. | 15:51.33 |
| | If you're happy, I'll push the lot to golden. | 15:51.48 |
| paulgardiner | Hang on a mo. Still looking | 15:52.04 |
| Robin_Watts | Sure. | 15:52.13 |
| paulgardiner | Looks ok AFAIKS | 15:54.09 |
| Robin_Watts | Thanks. | 15:54.25 |
| paulgardiner | np | 15:54.51 |
| Robin_Watts | So let's run the mjs generation again and see what falls out :) | 15:54.55 |
| chrisl | henrys: I can't find any contrib source files that aren't covered by GPL, so I don't see any problem removing few AFPL dual license cases, and updating everything to GPL3 - I can contact the authors whose details are available if we think it wise, but I don't think we have a legal obligation (GPL3 being *more* restrictive than earlier ones) | 16:20.42 |
| Gigs- | Do you all know of a way to view very high resolution bitmaps in linux? (Too big to fit into memory uncompressed) | 16:26.38 |
| | looking for a utility, I know I could write something | 16:26.50 |
| chrisl | Gigs-: I don't know if things have changed, but I ended up writing my own when I needed it a few years back - very dumb, took a tiff and split into multiple tiled tiffs. I now longer have it, unfortunately. | 16:29.31 |
| Gigs- | too bad that's exactly what I would need | 16:29.50 |
| | thanks anyway | 16:29.54 |
| chrisl | Unfortunately, it was work done for a previous employer, so....... | 16:30.28 |
| | If you're not in a hurry, you could something like imagemagick to produce small cropped images from a large original | 16:33.00 |
| henrys | chrisl:I noticed that dual license for the bubble jet has his own sourceforge site. if the code is the same can we just delete it? One less device to worry about. | 16:34.36 |
| chrisl | henrys: we could, yes. It's not a "proper" sourceforge project, though, as I looked at contacting him through it, but can't...... | 16:35.35 |
| | Gigs-: might be some useful information here: http://stackoverflow.com/questions/10542246/imagemagick-crop-huge-image | 16:36.00 |
| | Gigs-: in particular the VIPS project claims to be aimed at exactly what we're talking about: http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS | 16:37.27 |
| henrys | the epson740 stuff has no license. | 16:38.41 |
| | and the dviprlib.c and other files in japanese/ is aladdin - not gpl. | 16:39.51 |
| chrisl | henrys: doesn't matter, that's our copyright | 16:41.19 |
| henrys | so your going to change it to gpl? | 16:42.27 |
| chrisl | Yes. What I should have said was the only ones that aren't explicitly GPL are copyright Aladdin, so we can change them if we want | 16:43.02 |
| henrys | oh right. | 16:43.15 |
| chrisl | I'll try to get in touch with the guy about the epson740 one, but given he apparently wrote it for RedHat 5.2, I doubt he'll be contactable - we can probably just pull that one out. | 16:44.57 |
| | henrys: mind you, I'm no lawyer, but the epson740 stuff doesn't look copyrightable t me anyway....... | 16:46.23 |
| henrys | I don't know if that true but it's close enough. If I use the apache license does that mean the apache software foundation can change my license to something different, I don't think so. | 16:46.53 |
| | I was just leave epson740 alone. | 16:47.23 |
| | s/was/would | 16:47.29 |
| chrisl | henrys: as I said, I can certainly try to contact all the relevant authors about changing to GPL3, there's only ten or eleven....... | 16:49.17 |
| henrys | I'd say contact them, delete the devices, and pray they don't "call back" | 16:50.12 |
| chrisl | Okay, I'll do that on Monday. | 16:50.40 |
| henrys | sounds good trying to kill 2 birds ... here | 16:51.02 |
| chrisl | henrys: the reason I said I don't think the epson740 thing is copyrightable is because it's just a list of printers and capabilities, and a trivial script to build a ghostscript command line...... | 16:51.53 |
| henrys | right okay. | 16:55.33 |
| | 10 customer bugs - bah | 17:00.03 |
| Robin_Watts | marcosw: ping | 17:01.50 |
| Gigs- | chrisl: thanks | 17:06.50 |
| chrisl | Gigs-: do you think the VIPS tools might help? | 17:07.08 |
| Gigs- | looks like it | 17:12.52 |
| | lunch time | 17:12.54 |
| chrisl | Gigs-: that's good - I'll be interested to know how you get on....... with the large images, not so much with your lunch! ;-) | 17:14.36 |
| Gigs- | chrisl_away: that nip2 program that comes with vips is very basic but it works | 18:21.23 |
| | kind of annoying UI, like zooming moves you back to 0,0 | 18:21.39 |
| | then you have to figure out where you need to scroll to | 18:21.53 |
| | 92700x75600 8 bit tiff opened | 18:23.29 |
| | it's an FM screened output (I dont' know why it's 8 bit it could be 1 bit) | 18:23.44 |
| | FM dots are tiny | 18:23.52 |
| | oh wait ctrl-scrollwheel zooms without losing your spot | 19:06.56 |
| scott-san | Have a question from a potential customer: #2 Collation has been an issue, we haven't been able to make ghostscript run a collated print with multiple copies using the "mswinpr2" device. Is there a trick to making that work? | 20:49.09 |
| mvrhel | scott-san: make sure to add in someones name when you ask something | 20:49.34 |
| | i.e. henrys | 20:49.39 |
| | then their computer will ping | 20:49.46 |
| | and they will know someone is looking for them | 20:49.56 |
| scott-san | Aah. New to all this you know. :-) | 20:50.14 |
| mvrhel | no worries | 20:50.22 |
| | I just don't want you to get frustrated if no one answers | 20:50.36 |
| | henrys: do you know anything about this? | 20:50.43 |
| | ray would be the person to ask about this probably | 20:50.59 |
| | and he does not seem to be around | 20:51.04 |
| scott-san | I'm on with Ray now, so signing off. Thanks | 20:51.23 |
| mvrhel | it is possible that henrys is out for a run | 20:51.26 |
| | ok bye | 20:51.29 |
| | scott-san signs off quicker than kens | 20:51.45 |
| henrys | oops sorry I was away from my computer. | 21:22.08 |
| | Forward 1 day (to 2012/06/23)>>> | |
IRC Logs