| | <<<Back 1 day (to 2013/08/22) | 2013/08/23 |
| ray_laptop | kens: For the logs. I threw a few things at your patch and it looks OK. Fine with me to get it in | 06:35.30 |
| | morning, chrisl | 06:36.22 |
| | chrisl: I'm trying to wrap up the --saved-pages= stuff (again). I added the 'pad' page to printing even pages when the number of pages is odd and tested most options | 06:37.42 |
| | going to bed now. Back in my morning (maybe not until after I get my son to tennis, at about 9:30 PDT) | 06:39.21 |
| kens | chrisl I've just commited the *latest* fix for VM allocation mode and hideous kludgy safer mode stuff | 07:44.41 |
| | I have no idea what we do now. | 07:44.49 |
| chrisl | Well, I suppose we *could* do yet another release..... | 07:46.19 |
| kens | The report about gv suggested that pdf2dsc is (rather horrifyingly) used by other applications as well (on Linux I guess) | 07:47.08 |
| chrisl | Quite possibly - whoever wrote that should be shot..... | 07:47.45 |
| kens | the bug is 694534 for the pdf2dsc thing | 07:48.06 |
| chrisl | Worries are: what about the other scripts/utils in lib? And (based on what Ray said) what other random non-standard operators are documented? | 07:49.25 |
| kens | Hopefully none that I;'ve changed :-( | 07:49.44 |
| | I'm happy with a few of the scripts and PostScirpt files, I did whizz through them yesterday looking for problems | 07:50.24 |
| | pdf2dsc is by far the ugliest | 07:50.34 |
| | I have put a comment in the bug that ti would be nice if someone would test it | 07:51.20 |
| chrisl | FWIW, I now know why I didn't the problem when I tested gv..... it has a setting that you can specified the "gs" executable to be used. But the "Scan PDF" section ignores that, and uses it's own gs command line :-( | 07:51.38 |
| kens | Well I don't think we can try every possible feature of other applications, I didn't use GSView very much when I tested the fix on that either. | 07:52.17 |
| chrisl | I don't use GSView nor gv unless require to reproduce a problem - I really dislike them both! | 07:52.59 |
| kens | I am a little bemused that we used a '.' as part of the name for a function we intended to be public, I had rather thoguht these indicated internal names. | 07:53.08 |
| | By the way, I'm inclined to remove teh 'pf2...' scripts from lib (pf2afm, pfbtopfa and pftogsf). I'd like to remove ps2ascii but I happen to know GSView uses that one | 07:55.02 |
| | I have absolutely no idea what most of the script in lib actually do, what does font2c do for example ? | 07:55.44 |
| | Oh, writes out a Type 0 or 1 file as C code. | 07:56.15 |
| chrisl | IIRC, font2c converts a PS font into a "C" representation - I'd guess it's just a byte array of the file content? | 07:56.40 |
| kens | It looks more complicated than that | 07:57.01 |
| chrisl | kens: could ps2ascii be rejigged to use the txtwrite device? | 07:57.08 |
| kens | chrisl maybe I'd have to look at ps2ascii. | 07:57.37 |
| | WHich is a 46k PS file | 07:57.56 |
| | Looks like it would need extensive changes to txtwrite, a new format output would be needed | 07:58.46 |
| chrisl | Oh :-( | 07:59.16 |
| kens | I just had another rummage through the batch files and they 'look' OK, but who knows really | 08:00.55 |
| chrisl | Lord, this .setsafe and .runandhide stuff is horrific :-( | 08:03.50 |
| kens | I agree completely :-( | 08:04.02 |
| | It wouldn't be *so* bad except that its complicated by the DPS requirements, and teh WordPerfect hackery to have currentpagedevice always return a local dict | 08:04.44 |
| chrisl | Well, I stand by what I said before: the WordPerfect thing should never have been "fixed"..... | 08:06.19 |
| kens | Yeah, sadly that's a bit late now :-( | 08:06.34 |
| chrisl | No so sure, WordPerfect *must* have fixed it, otherwise too many other PS interpreters would have errored out on it | 08:07.55 |
| kens | Maybe they just started using the WIndows PostScript driver :-) | 08:08.42 |
| chrisl | That's possible.... | 08:09.17 |
| | I think we just leave it - make sure Till sees the fix, other distributions can pull in the patch, as required. | 08:09.52 |
| kens | OK I have no sense of how important this really is. Given how far behind most distributions other than Ubuntu seem to be, I suspect its not important.... | 08:10.39 |
| chrisl | kens: Well, I feel it would be important, but given that all the distributions pull in random patches when it suits them, I'm inclined to say "Live by the sword...." etc | 08:13.59 |
| kens | Well I see Till just changed his name, maybe he's here ? | 08:14.20 |
| chrisl | Likely, yes | 08:14.47 |
| kens | thinks chrisl just doesn't want to do another release :-D | 08:16.12 |
| chrisl | kens would be correct in that! But also, we'd miss the Ubuntu deadline, so it would ship with 9.09 + patch anyway..... | 08:17.45 |
| | kens: FWIW, I'm actually getting quite quick at doing releases, after the past few weeks..... | 08:18.26 |
| kens | That's a bad sign.... | 08:18.36 |
| | Even worse, I'm starting to understand the startup PostScript | 08:18.53 |
| kens | needs coffee now, suffering a shortage | 08:19.22 |
| chrisl | Don't worry, by next week you'll forget it again | 08:19.31 |
| Robin_Watts | pipitas: Did you email me that file? I don't recall seeing anything | 08:35.26 |
| kens | chrisl how possible do you think it would be to have a custom deifnefont that checked if the device wanted 'uniqueness' in fotns, and if so performed an MD5 hash of the font, putting the hash in the font name ? I'm sort of thinking out loud here.... | 08:49.52 |
| | Curious, it seems definefont is already a PostScript routine | 08:52.56 |
| chrisl | kens: It would be fairly easy, I reckon, for PDF. Not really viable for Postscript. | 08:53.47 |
| kens | Hmm, we don't use teh /definefont in gs_fonts.ps ? | 08:54.17 |
| | I guess we'd need makefont as well | 08:54.45 |
| chrisl | Yeh, but how would we reliably MD5 it from a PS file? Given the random ways that a font dictionary can be created? | 08:55.30 |
| kens | Isn't the wholel font in the dict by the time we call definefont ? Including the CHarString ? | 08:55.48 |
| | Of course that doens't help with incrementally defined fonts :-( | 08:56.00 |
| chrisl | If we want to MD5 the content of the dictionary we'd probably have to implement it in C code - save faffing around with permissions | 08:56.44 |
| kens | Yeah I was thinking that would be the way to go, a custom operator | 08:57.03 |
| | I wasn't planning to MD5 it in PostScript :-) | 08:57.15 |
| chrisl | No, but I thought we had a Postscript accessible MD5 available - maybe not..... | 08:57.48 |
| kens | I think I'll give this a try. incrementally defined fonts will still defeat us I think sadly, but it should work fine for PDF, or PS derived from PDF, and that will get us at least 80% there | 08:58.17 |
| chrisl | There'll be some fiddly bits handling the different font types | 08:58.26 |
| kens | ANyone downloading incrementally defined fonts whose name includes a PDF subset prefix, and using the same font name is going to be out of luck. | 08:59.01 |
| chrisl | You probably also want to limit the amount of data you checksum - thinking of a multi-megabyte CID font...... | 09:01.28 |
| kens | I was only going to do it if the font name included a subset prefix, which hpoefully should limit the size | 09:01.55 |
| chrisl | Yeh, that makes sense. | 09:02.30 |
| Robin_Watts | tor7: Font cache changes all test out, and come back as faster on the pi at least. | 09:12.29 |
| | I'm popping out for an hour or so if you want to give the final commit a once over (essentially the same as yesterdays, but with a static inline for move_to_front). | 09:13.03 |
| tor7 | Robin_Watts: glyph cache commit LGTM | 09:18.37 |
| Robin_Watts | tor7: Thanks | 11:01.51 |
| kens | Oh wow, a 44Mb PDF file :-( | 11:04.01 |
| chrisl_r61 | kens: and does it crash? | 11:04.37 |
| kens | ABout to try it | 11:04.43 |
| | takes acrobat quite a while to draw it | 11:04.56 |
| | Its certainly going to produce a large output file | 11:06.30 |
| | THe media is 50x50 inches | 11:07.27 |
| | lookike a 1.9 Gb output file | 11:08.12 |
| | I wonder if its just overflowing a 32-bit integer in tiff | 11:08.33 |
| chrisl_r61 | That seems rather likely | 11:08.39 |
| | Is it just one page? | 11:08.54 |
| kens | yes | 11:08.58 |
| | one *very* large page | 11:09.06 |
| | Didn't we add support for bigtiff ? | 11:09.28 |
| chrisl_r61 | Yes | 11:09.48 |
| kens | Hmm gs exited after 210Mb | 11:09.52 |
| chrisl_r61 | With an error? | 11:10.56 |
| kens | I was using the GUI and it just vanished while I wasn't looking. I'm retrying with teh command line | 11:11.20 |
| | I'm not sure what applications I have tht might be able to open such a file anyway | 11:12.14 |
| | Yes it exited silently, no error, no crash | 11:12.27 |
| | I'll try it under the debugger | 11:12.40 |
| chrisl_r61 | I'm fairly sure I had it return a proper PS error if the TIFF size overflowed | 11:15.22 |
| kens | OK I get a crash in the debugger. Its in memmove() from top_up_cbuf() from clist_playback_band() so I reckon that makes it Ray's | 11:15.31 |
| | chrisl its worse than I thought with these fonts, they are actually CIDFonts and although the descendants have subset prefixes on their names, the BaseFont (ie the actual FontName) of teh CIDFont doesn't. | 11:41.54 |
| chrisl_r61 | kens: that's a little icky, but shouldn't be too hard to deal with, I don't *think*..... | 11:42.54 |
| kens | I'm not certain, at the moment the fonts which are being defcined don't have prefixes on the names, I'm not sure why yet, its been too long since I messed around in the font code. | 11:43.54 |
| | And I think I need to know that teh CIDFont has descendants which are subsets, and generate a subset prefix for the CIDFont as well, otherwise I will still think its the same font in pdfwrite | 11:44.46 |
| chrisl_r61 | kens: well, if it gets too nasty, you can pass it to me | 11:45.11 |
| kens | I might ask you to identify where I can check for subsets and generate a new name if required. | 11:45.46 |
| | Or I may just give it up as a bad job | 11:46.00 |
| tor7 | Robin_Watts: did you get time to look at the ligature bug fix? | 12:14.24 |
| Robin_Watts | tor7: I did not. I will do so straight after lunch, sorry. | 12:14.57 |
| | actually, let me look now. | 12:15.27 |
| | Is there a guaranteed maximum length to aglcode? | 12:17.23 |
| | oh. it's an int, ignore me. | 12:17.49 |
| tor7 | it's the unicode value of the glyph, taken from the glyph list | 12:18.01 |
| | might still want to bump buf[] just in case | 12:18.50 |
| | if that was your concern? | 12:19.12 |
| Robin_Watts | uni%04X + null should be fine in all cases in a 10 char buffer. | 12:19.35 |
| tor7 | 8 bytes in the nominal case, with 2 to spare should we ever bump any of the unicode values in the agl past 0xFFFF | 12:20.02 |
| Robin_Watts | %04 can never be more than 4 bytes though. | 12:20.25 |
| | %04X can never be more than 4 bytes though. | 12:20.32 |
| tor7 | the aglcode comes from a table of unsigned short, so that should be safe | 12:20.39 |
| | it can, it just guarantees a minimum width of 4 | 12:20.46 |
| Robin_Watts | Well, it looks fine to me. go ahead and push. | 12:21.34 |
| tor7 | Robin_Watts: thanks. | 12:23.19 |
| vtorri | tor7: hey | 12:26.46 |
| tor7 | hi | 12:26.50 |
| ghostbot | que tal, tor7 | 12:26.50 |
| vtorri | tor7: i have a question about loading / freeing a page with mupdf | 12:27.14 |
| | i call fz_load_page() | 12:27.45 |
| | then | 12:27.48 |
| | fz_free_page | 12:28.10 |
| | but valgrind is showing some memory which is not released | 12:28.26 |
| | is it normal ? | 12:28.31 |
| | or did I do something wrong ? | 12:28.36 |
| tor7 | you have probably forgotten something or other. mudraw runs without leaks. | 12:29.42 |
| vtorri | ok | 12:29.53 |
| | something wrong in my code, thanks | 12:30.02 |
| tor7 | which function/struct has leaked? | 12:30.09 |
| | valgrind --leak-check=full | 12:30.27 |
| vtorri | 2s, i give you the valgrind report | 12:30.33 |
| | tor7: http://codepad.org/wwd5K6v7 | 12:31.56 |
| tor7 | vtorri: which version of mupdf are you running? | 12:34.08 |
| vtorri | 1.2 | 12:36.24 |
| | i'm going to use 1.3 soon | 12:36.34 |
| | which makes me think : has mupdf build system changed a lot compared to 1.2, or only additions ? | 12:37.09 |
| | iirc, you told me that 1.3 supports some image formats | 12:37.25 |
| tor7 | 1.3 build system is mostly the same, but all of the source files have moved around. we reorganised the directory layout to be more logical, and split the gargantuan header file into modular pieces. | 12:38.30 |
| vtorri | ok | 12:39.02 |
| | tor7: no API break ? | 12:39.29 |
| tor7 | only minor | 12:39.37 |
| | I don't remember if we changed the fz_matrix and fz_rect passing conventions before or after 1.2 | 12:40.05 |
| vtorri | ok | 12:40.21 |
| | thank you | 12:40.31 |
| | about my problem, it's certainly something obvious... | 12:40.47 |
| tor7 | the valgrind traceback indicates that you're not calling fz_free_page at all | 12:41.07 |
| vtorri | i call it, i verified that | 12:41.40 |
| tor7 | are you calling it with the same pointer that leaked? | 12:41.51 |
| vtorri | yes | 12:41.55 |
| | i also verified that | 12:42.01 |
| tor7 | well, in that case, you're saying valgrind lies | 12:42.13 |
| vtorri | hmm, i should check that the document is not closed before... | 12:42.17 |
| | i have to put some printf around... | 12:42.37 |
| | bingo | 13:03.41 |
| | it was that | 13:03.46 |
| | i had to track the order of the calls in my mess :p | 13:03.56 |
| | tor7: mupdf 1.3 allows the download of pdf from internet progressivey, right ? | 13:04.42 |
| | progressively* | 13:04.52 |
| Robin_Watts | vtorri: yes. | 13:09.39 |
| chrisl | kens: are you (and your phone) free? | 13:09.50 |
| kens | ytes | 13:09.55 |
| Robin_Watts | See docs/progressive.txt | 13:09.57 |
| vtorri | Robin_Watts: thank you | 13:12.55 |
| Robin_Watts | tor7: Interesting list of 24 differences with the uniXXXX change. Presumably all progressions? | 13:14.16 |
| tor7 | sane or bmpcmp? | 13:34.46 |
| Robin_Watts | just noticed it in the cluster report. | 13:36.23 |
| | To see a bmpcmp you'd need to revert the commit and clusterpush/bmpcmp that. | 13:36.52 |
| tor7 | Robin_Watts: how many files do you have in your sane/test suite? | 13:39.30 |
| Robin_Watts | tor7: can't remember. I mostly just clusterpush. | 13:39.44 |
| tor7 | I got zero diffs with my files, but I suspect you may have more. | 13:39.47 |
| Robin_Watts | mupdf cluster has 14000 or so. | 13:40.04 |
| | and it only takes 5 minutes or so to run :) | 13:40.20 |
| | well, sorry, that's 14000 tests. Probably 3500 files. | 13:40.38 |
| | I believe mupdf on the cluster tests all the sane files now. | 13:41.04 |
| | If it doesn't, we can make it do so. | 13:41.13 |
| ray_laptop | kens: excellent log message for the .setsafe fix. It is nice having the full explanation in one place (IMHO) | 14:45.09 |
| kens | it was so convoluted there was no choice.... | 14:45.24 |
| ray_laptop | agrees about the degree of convolutions | 14:45.50 |
| | for the next release, we _could_ remove the .runandhide (from the docs and the code) and see if anyone gripes. For a customer we could just give them a patch. For a free user, well ... | 14:47.38 |
| kens | chrisl (for the lgos) I see someone is compaining gthat | 14:57.29 |
| Robin_Watts | mvrhel_laptop: Hi. The mupdf timings I sent this morning are probably the final times. | 14:58.27 |
| kens | setting -dUseCIEColor is causing an invalidaccess in savedinitialgstate. This looks horribly like the VM stuff again, though I'm not clear on why. Somehow something must be getting a local VM dictionary at the first setpagedevice | 14:58.34 |
| Robin_Watts | but the font cache is larger than when you measured, so peak memory use may be up to 3Meg more than before. | 14:58.59 |
| | (I am working on code now to hold glyphs compressed, which will hopefully reduce memory use and boost speed, but I don't see me finishing that today) | 14:59.42 |
| kens | Oh I don't believe it, setting -dUseCIEColor does indeed cause an error in the DPS stuff. | 15:03.01 |
| kens | runs away screaming | 15:03.08 |
| | Yes yet again we call setpagedevice in gs_init.ps before we do initgraphics. | 15:05.01 |
| | By the way from the Register (and BBC news) : | 15:08.08 |
| | http://www.theregister.co.uk/2013/08/23/steve_ballmer_to_retire/ | 15:08.08 |
| | and MS sahres are up 9% :-) | 15:08.26 |
| mvrhel_laptop | Robin_Watts: ok thanks | 15:10.02 |
| | kens: I am going to work on your problem that I was to look at a while ago, on the plane | 15:10.46 |
| kens | thanks mvrhel_laptop | 15:10.53 |
| mvrhel_laptop | in addition to getting my polarity work done for Robin_Watts | 15:11.05 |
| kens | I've just been thrown back to VM allocation and startup so there's no rush :-(( | 15:11.18 |
| mvrhel_laptop | fun | 15:33.22 |
| kens | No I'm tearing my hair out, I thought I had finally fixed all this. | 15:33.41 |
| | THis time I;ve grepp'ed the PostScript files for setpagdevice just in case any more nasties are quiertly buried in there waiting to explode | 15:34.21 |
| chrisl | kens: that one sounds likely to affect customers - we might <sob> need to look at another release..... :-( | 15:37.19 |
| kens | chrisl I'm afraid so, yes. -dUseCIEColor is used a lot with pdfwrite at the moment :-( | 15:37.47 |
| | As usual, I have a fix, and absolutely no confidence left at all. | 15:38.05 |
| chrisl | Well, I'm not doing anything about it until Monday..... | 15:38.57 |
| kens | I think I'm going to lie down in a darkened room and hope it was all a bad dream | 15:39.21 |
| chrisl | No you don't! That was my plan! | 15:39.43 |
| | I find it extremely worrying that so much stuff apparently depends implicitly on an aspect of our Postscript which was just broken...... | 15:42.26 |
| kens | This is just another case where we call setpagdevice during startup, and we *must* have a global dictionary or the DPS intiialisation fails | 15:43.04 |
| | I have to be off, goodnight all. chrisl I am just running a quick cluster test with my *latest* fix, all other tests (duplicating the descriptions in commit ae930279, plus the ones Ray suggested last night) are OK. I'll look at the results when I get back. | 16:24.59 |
| sebras | todays git command: git commit --amend --no-edit | 18:23.21 |
| Robin_Watts | sebras: Did you see my wibblings about your commits? | 18:26.00 |
| sebras | Robin_Watts: no..? | 18:34.46 |
| Robin_Watts | They all look good, except for a couple of them, where the commit messages give no clue as to why the change is required. | 18:35.11 |
| sebras | ok. | 18:35.21 |
| | I'll have a look through the logs when I get home. | 18:35.31 |
| Robin_Watts | In particular: Cancel page timeout when searching in x11 viewer. | 18:36.00 |
| | and: Set page number timeout outside of x11 main. | 18:36.19 |
| sebras | I think some of them might just be code-reordering. | 18:36.39 |
| Robin_Watts | A couple of lines in the commit message about *why* the changes are required would help my tiny brain a lot. | 18:36.50 |
| sebras | to make the next commit be smaller. :) | 18:37.40 |
| | but I'll have a look at them and update the commit message later. | 18:37.52 |
| Robin_Watts | If it's just for neatness, then great - say "Code rearranged for aesthetic reasons." or something. It'll save me trying to understand why we made the change when I look back in the history. | 18:37.53 |
| | Thanks. | 18:37.55 |
| sebras | ok. | 18:38.08 |
| Robin_Watts | Some of the commits like "Add support for showing messages..." are clearly stepping stones, and I can understand that. | 18:38.30 |
| | ok, I have a first cut at RLEd font glyphs working locally. | 19:11.03 |
| | tor7: I've pushed the work so far to robin/master if you're interested. | 19:13.03 |
| | It still needs to be tidied, and I want to make it so that we convert direct to fz_glyphs from freetype bitmaps rather than going via fz_pixmaps as we do now. | 19:13.38 |
| | SEGVs and diffs in the cluster though. :( | 19:15.21 |
| kens | chrisl for the logs, my current (last, pleeease...) patch is OK with all the cases raised so far, asnd passes the cluster (no surprise because it always did). TOmorrow I want to have a better look at all teh places we call setpagedevice, to *try* and make sure there are no other hidden surprises. | 19:37.59 |
| Robin_Watts | OK, no errors, just some blending differences. | 22:59.51 |
| | Well, no SEGVs, definitely still some errors though. but decent progress. | 23:00.52 |
| | bedtime though. | 23:00.54 |
| | Forward 1 day (to 2013/08/24)>>> | |
IRC Logs