| | <<<Back 1 day (to 2014/01/02) | 2014/01/03 |
| Robin_Watts | henrys: Well, we're on pass 16 now, the final output. When this completes I should be able to import it into a fresh git repo, and then we'll see what a mess it's made of it :) | 00:30.33 |
| Guest28565 | Eh..Hi? | 07:04.21 |
| | Anybody? | 07:04.39 |
| | I'm here to inquire about mupdf. I've heard that mupdf has 400 thousand lines of C code. I'm curious about how long it took to code mupdf, how many people joined in the coding process. Does anyone know? | 07:08.24 |
| | O,.o | 07:30.43 |
| Robin_Watts | Guest28565: It's ongoing. | 08:54.56 |
| | Guest28565: For questions like that, you might want to look at ohloh. | 08:55.16 |
| Guest28565 | Well, thanks. I'll check it out later | 09:36.26 |
| zeniko | Robin_Watts: Half a dozen further patches for you to consider on zeniko/mupdf - time permitting | 11:21.43 |
| tor8 | Guest28565: 400kloc is an exaggeration. we're sitting comfortably at somewhat less than 100kloc. | 11:43.14 |
| Robin_Watts | zeniko: will look in just a mo. | 11:46.17 |
| | tor8: so, did you/sebras discuss rebind? | 11:46.25 |
| Guest28565 | Oh, thanks for your information. Actually I heard the 400kloc from my friend. | 11:47.58 |
| kens | COUle be 400k with all the 3rd party libraries ? Or even more.... | 11:48.28 |
| Robin_Watts | http://www.ohloh.net/p/MuPDF | 11:49.01 |
| | Over 100K now supposedly. | 11:49.19 |
| Guest28565 | But even 100k is formidable number. | 11:49.37 |
| kens | I see, and it includes the Java and stuff | 11:49.43 |
| Guest28565 | This project starts from Sep. 2004, with 24k lines. | 11:52.14 |
| | ed | 11:52.54 |
| kens | I see GS has 4 million loc.... | 11:53.12 |
| Guest28565 | What is GS? | 11:53.48 |
| kens | Ghostscript | 11:53.53 |
| Guest28565 | Wow | 11:55.27 |
| tor8 | Robin_Watts: we didn't! :( | 11:56.01 |
| Robin_Watts | tor8: I'm kinda blocked on this stuff now. | 11:56.18 |
| | Can we go with rebind for now, and we can unpick it later if required? | 11:56.37 |
| tor8 | but since this is holding you up, I think we should let the rebinding go in for now seeing as they're the least invasive change and easily reverted | 11:56.41 |
| Robin_Watts | Perfect, thanks. | 11:56.50 |
| | So all the commits bar the last one on robin/master are good to go as far as I am concerned. | 11:57.11 |
| | I tweaked a couple of them based on your comments. | 11:57.27 |
| kens | needs chrisl to come back from vacation :-( | 11:57.47 |
| Robin_Watts | zeniko: What's the logic behind the changes from: | 12:00.37 |
| | - fz_matrix mat = {pixmap->w, 0.0, 0.0, pixmap->h, x + pixmap->x, y + pixmap->y}; | 12:00.47 |
| | + fz_matrix mat; | 12:00.49 |
| | + mat.a = pixmap->w; mat.b = mat.c = 0; mat.d = pixmap->h; | 12:00.51 |
| | + mat.e = x + pixmap->x; mat.f = y + pixmap->y; | 12:00.53 |
| tor8 | Robin_Watts: how about letting the xref marking work with multiple levels (like the postscript save/restore memory thing) | 12:03.45 |
| Robin_Watts | tor8: So instead of being a flag it'd be some sort of counter? | 12:04.13 |
| | or you'd specify a flag bit to mark with, and then a flag bit to clear to or something? | 12:04.39 |
| kens | Hmm seems Google now demands a phone number to create a new GMail account. Guess I'll go find someone else..... | 12:05.19 |
| Robin_Watts | kens: I won't blame google for that :) | 12:06.15 |
| kens | I'm not giving them my phone number | 12:06.28 |
| tor8 | and I would probably expose this to the fz_document api rather than abusing the device hints for something unrelated to devices... | 12:07.02 |
| | and leave it to the user to do the save/restore memory around the run-page calls | 12:07.03 |
| | (or only at the pdf_document level, and call it from the fz_document wrappers) | 12:07.04 |
| | Robin_Watts: I'm happy with all but the last patch to go in, that one I want to have a cleaner interface (though the concept is brilliant) | 12:07.05 |
| Robin_Watts | tor8: I'm all for cleaner :) | 12:07.26 |
| zeniko | Robin_Watts: The current fz_matrix initialization is non-standard according to MSVC (causes warning C4204 using /W4) | 12:08.20 |
| Guest28565 | Hope I will not bother you. I'm just curious about this project. | 12:08.50 |
| | What is the initial motivation of this project? | 12:08.52 |
| Robin_Watts | Guest28565: I want a maserati. | 12:09.03 |
| tor8 | Robin_Watts: I was thinking a simple counter / water depth level like thing | 12:09.19 |
| Guest28565 | lol | 12:09.23 |
| tor8 | anything new that goes in gets the current level, and then you can clear everything above a given level when you "pop" | 12:09.46 |
| Robin_Watts | tor8: OK, we've currently only got 8 bits to record the level, so we'd better not 'leak' levels :) | 12:10.14 |
| | Can you give me a case where that would be useful ? | 12:10.23 |
| Guest28565 | Robin, are you the one who initiated this project? | 12:10.39 |
| Robin_Watts | Guest28565: No, it's Tor's baby. | 12:10.48 |
| tor8 | so you can: bump the level, load the page, bump the level, render the page, pop, bump, do something else to the page, pop, pop | 12:10.59 |
| Robin_Watts | So the Maserati is a continuing motivation, not the initial one :) | 12:11.01 |
| zeniko | Robin_Watts: As for the bug 691691 patch, I'd rather wait with that until it's clear that it actually does what I was hoping for (no change being better than an unnecessary one IMO) | 12:11.21 |
| tor8 | I guess having multiple levels is probably not super-useful but it's a trivial addition | 12:11.23 |
| | zeniko: your load system font patch looks good, but I would like to rename load_similar_cjk_font to load_system_cjk_font | 12:12.01 |
| Robin_Watts | tor8: The worry I have is that people will misuse it, and it'll wrap badly etc. | 12:12.08 |
| | But I'm prepared to be convinced. Do you want to take it and try for a version your happy with? | 12:12.31 |
| zeniko | tor8: Sure, anything else? | 12:12.32 |
| tor8 | Robin_Watts: I'm fine with us hiding it (or using it behind the scenes) for pdf, but not by abusing the device hints please | 12:12.37 |
| | zeniko: that's all I can find to complain about :) | 12:13.33 |
| | zeniko: though I would have expected you to pass the bold/serif/script or other fontdescriptor flags to find a substitute font, but I guess you're just looking for exact matches here | 12:14.21 |
| Robin_Watts | zeniko: OK, I like all those patches (except for the pdf_parse_file_spec one, which I'm still struggling with mentally) | 12:14.26 |
| Guest28565 | Do you know any pdf reader that can synchronize your pdfs with cloud? | 12:14.42 |
| tor8 | zeniko: re the matrix initializer, does MSVC support fz_matrix m = (fz_matrix){1, 0, 0, 1, 0, 0}; type syntax then? | 12:16.22 |
| zeniko | It supports both fz_matrix m = { 1, 0, 0, 1, 0, 0 }; and fz_matrix m = { w, 0, 0, h, 0, 0 };, but complains about the latter being non-standard | 12:17.20 |
| tor8 | Guest28565: I wrote a mupdf prototype a few years earlier (I think 2002) but there is nothing common with the current codebase which started in 2004 | 12:17.37 |
| Guest28565 | Cool. | 12:18.13 |
| | You want a maserati too..? | 12:19.16 |
| tor8 | Guest28565: and the motivation back then was acrobat reader being extremely slow, buggy and terrible at rendering text on solaris | 12:19.43 |
| | on the university machines where I'd try reading papers in PDF | 12:20.11 |
| | zeniko: oh, so it doesn't like non-constant initialisers? | 12:20.49 |
| Robin_Watts | It claims that they are 'non-standard'. | 12:21.06 |
| | http://msdn.microsoft.com/en-us/library/6b73z23c.aspx | 12:21.16 |
| tor8 | Robin_Watts: odd. oh, right, they never heard of C99 ;) | 12:21.56 |
| | though I thought prefixing a {} initialiser with a typecast was pre-c99, and c99 just let you elide the typecast | 12:22.41 |
| Guest28565 | It was adobe who invented pdf format and the acrobat reader, right? But you were saying adobe made a extremely slow pdf reader? | 12:23.19 |
| tor8 | Guest28565: you have no idea how bad their reader was (or is...). | 12:25.46 |
| Guest28565 | :] | 12:26.14 |
| tor8 | if you scrolled a page, colors in images would "forget" to convert from RGB to BGR for the screen on newly revealed parts | 12:26.47 |
| | type3 bitmap fonts were an illegible gray mess | 12:27.19 |
| | and it took a good 10 seconds or more to just start up | 12:27.33 |
| Guest28565 | I didn't notice that. | 12:27.33 |
| | BTW, how to change my nickname.... | 12:27.50 |
| kens | http://www.technerd.net/nickserv.html | 12:29.00 |
| Guest28565 | ...kind of complicated | 12:32.29 |
| kens | Not that much, just register your nickname, then set up your chat client to login for you when you join the channel | 12:33.18 |
| Guest28565 | Ok, I'll follow up | 12:34.06 |
| Robin_Watts | zeniko: OK, I've cherry-picked your commits, and rebased them. I had to resolve some conflicts (the rebind stuff added new doc level functions) | 12:36.08 |
| | and I've added the jxr file into the win32 project. | 12:36.19 |
| | so robin/master has the new versions on. | 12:36.32 |
| | I'll run a quick cluster test now. | 12:36.37 |
| | actually, I'll let the cluster catch up, then run a test after lunch. | 12:37.12 |
| | If that passes, and you don't say otherwise, I'll push them. | 12:37.22 |
| zeniko | Thanks, looks like we had the same idea. | 12:40.24 |
| | In the merged C4054 patch, there's some unexpected whitespace in document.h | 12:40.27 |
| | tor8: I've updated the fz_load_system_font patch as requested | 12:41.09 |
| | Robin_Watts: about the fz_stream rebinding: why does the stream's rebind function return a stream instead of accepting a context and doing the rebinding itself? | 12:41.49 |
| Guest28565 | ..... | 12:44.42 |
| Robin_Watts | zeniko: It avoids needless recursion. | 12:44.59 |
| | stack overflows etc. | 12:45.08 |
| Guest28565 | How should I specify my nickname in the command REGISTER? | 12:46.14 |
| Robin_Watts | zeniko: I can't see the unexpected whitespace here: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=6d180d6507b2673fcef7ec6962d9f0277a7b5dec | 12:46.38 |
| | D'OH. | 12:46.47 |
| | yes I can, sorry. | 12:46.51 |
| | Updated versions online now. | 12:47.47 |
| Guest28565 | I have to log out and change my nickname and relogin? | 12:51.47 |
| MoonKnight | I'm back. Guest28565 | 12:56.04 |
| | What is the latest problem you are fixing? | 12:59.36 |
| | Mupdf already has 100k lines and still has tiny problems in it? | 13:00.24 |
| Robin_Watts | MuPDF has fewer lines than the PDF spec. | 13:01.39 |
| | The problem is largely that the spec is poor, and file producers are even poorer. | 13:01.56 |
| tor8 | Robin_Watts: if you think the PDF spec is poor, you haven't seen the javascript spec... oh my god what a terrible horrible ambiguous full of crap grammar that language has | 13:03.44 |
| | not to mention the completely impenetrable vague and incomplete language of the spec itself | 13:04.09 |
| MoonKnight | I think TrueTypeFont spec is among the poorest. | 13:07.41 |
| | Do you code the decompression algorithms yourselves? | 13:10.42 |
| sebras | Robin_Watts: good morning (UGT)! | 13:16.35 |
| Robin_Watts | sebras: Morning | 13:16.48 |
| zeniko | Robin_Watts: document rebinding has added a dependency of pdf code on document.c which now requires us to build cbz and image loading as well | 13:17.05 |
| Robin_Watts | zeniko: It has? | 13:17.32 |
| zeniko | pdf-device.c calls fz_rebind_document which is defined in document.c | 13:17.53 |
| | and pdf-device is required for pdf-appearance | 13:18.02 |
| sebras | tor8: I should never have closed that IRC-window... | 13:18.08 |
| Robin_Watts | So the new dependency is that pdf-device.c depends on document.c | 13:20.14 |
| zeniko | Yes, and document.c pulls in cbz and img | 13:20.49 |
| Robin_Watts | So you'd prefer that I had a pdf_rebind_document and I made pdf-device call that instead? | 13:21.47 |
| | or I called it direct. | 13:22.05 |
| | Calling it direct seems easiest. | 13:22.12 |
| sebras | oh, is google still the default go to place for downloading mupdf tarballs?! | 13:22.57 |
| | I though you had moved this to mupdf.com... | 13:23.06 |
| zeniko | Alternatively, split document.c into two: one file for handling fz_document and one file for loading (and only the latter pulls in pdf, xps, cbz and img) | 13:23.13 |
| Robin_Watts | I think that latter is nicer. tor8? any thoughts? | 13:23.58 |
| MoonKnight | Excuse me...Do you code the decompression algorithms yourselves? If true, where do this part of codes locate? | 13:30.46 |
| Robin_Watts | MoonKnight: Which decompression algorithms ? | 13:30.59 |
| kens | Which algorithms in particular ? | 13:31.02 |
| Robin_Watts | zeniko: I wonder if we should have FZ_DISABLE_XPS, FZ_DISABLE_PDF, FZ_DISABLE_IMG etc. | 13:31.29 |
| tor8 | Robin_Watts: yeah. the document.c part that pulls in pdf, xps, cbz, and img should probably be in a separate file | 13:32.14 |
| Robin_Watts | document-open.c ? | 13:32.24 |
| tor8 | Robin_Watts: that sounds fine. I've never really been happy with that particular circular dependency | 13:32.56 |
| | another thought I had was to let the user register which file types to allow fz_document to open | 13:33.14 |
| zeniko | Ideally, that file would live in source/tools so that fitz never depends on pdf, etc. | 13:33.16 |
| tor8 | but that's extra boilerplate that everyone would need | 13:33.22 |
| | but we could put that boilerplate in a function in document-open and make everyone call the convenience function | 13:33.39 |
| | fz_register_document_type(xps_document_funcs) | 13:33.50 |
| | or something like that | 13:34.01 |
| Robin_Watts | Have the doc types in the context. | 13:34.06 |
| | so you create a context, then register the doc handlers with the context (via a convenience function) then doc open. | 13:34.37 |
| tor8 | Robin_Watts: a list of doc types to try (a struct with suffix/mimetype/open-function) | 13:34.41 |
| | Robin_Watts: yeah. sounds like we're on the same page. | 13:34.55 |
| Robin_Watts | tor8: I'd prefer a sequence of register(&xxxx); | 13:35.08 |
| zeniko | Or you could provide convenience functions which support all document types and let everybody else (just us?) reimplement them ourselves | 13:35.10 |
| tor8 | Robin_Watts: fz_register_document(&xps_document_type) ? | 13:35.25 |
| Robin_Watts | Yes, | 13:35.31 |
| tor8 | and fz_register_common() as a convenience function | 13:35.32 |
| zeniko | note that we don't use fz_document at all | 13:35.42 |
| Robin_Watts | And the type would contain 'recogniser' functions that can respond to mimetypes etc. | 13:35.59 |
| tor8 | Robin_Watts: go for it :) | 13:36.10 |
| Robin_Watts | OK, will do that this afternoon. | 13:36.21 |
| | zeniko: Can you wait 24 hours for a fix? :) | 13:36.33 |
| | (just copy the contents of fz_rebind_document into pdf-device as a workaround for now. | 13:37.19 |
| zeniko | No worries, until you're ready I've done exactly as you originally proposed | 13:37.34 |
| | Robin_Watts: the fz_load_system_font change is also ready for landing | 13:40.31 |
| sebras | MoonKnight: PDF uses several algorithms, e.g. flate and lzw (http://goo.gl/xdSrnB and http://goo.gl/z0Akgo) as well as ones for specific image formats such as jpeg and jpeg2k. some of the algorithms have been coded by people here while others come from third-party libraries (such as libjpeg and openjpeg). your question is a bit too generic to give a good answer. | 13:40.38 |
| zeniko | and there are three more patches up for review | 13:40.39 |
| MoonKnight | Yeah, by decompression algorithms I just meant algorithms like LZWDecode and FlateDecode | 13:42.01 |
| paulgardiner | Robin_Watts: little android build fix: http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=commitdiff;h=2a1d51fe1459908625764dd3f1f367cb64a471be | 13:43.06 |
| MoonKnight | Sorry. I have been away from pdf specification for more than one year. | 13:43.59 |
| sebras | zeniko: hm.. I wonder if there aren't PDFs that have Unix/DOS relative paths that would work in either environment. | 13:44.48 |
| zeniko | tor8: Robin_Watts: I'm also currently sitting on a patch implementing support for transfer functions (bay adding a apply_transfer_function member to fz_device and keeping transfer functions in precalculated tables so that a fz_function isn't required) - interested? | 13:45.17 |
| MoonKnight | I have done some code which could modify the node "info". Really simple compared with mupdf. At that time I was stuck in the decode algorithms. Being unable to decompress the streams successfully, I cannot read the large part of pdf. | 13:46.35 |
| zeniko | sebras: I haven't had any reports to that regard | 13:46.42 |
| | also, wouldn't a more generic path be preferrable to one for a different file system? | 13:47.07 |
| MoonKnight | Thanks for your information, sebras. | 13:47.54 |
| zeniko | so the order would be DOS->F/UF->Unix for Windows and Unix->F/UF->DOS elsewhere (and I'd suppose that you'd never reach that last step anyway) | 13:49.48 |
| sebras | zeniko: but wouldn't we want F/UF to be the first option? | 13:51.37 |
| | zeniko: so F/UF->DOS->Unix or F/UF->Unix->DOS. | 13:51.55 |
| zeniko | no, DOS/Unix are supposed to take precedence over F/UF on the corresponding system | 13:53.38 |
| | PDF Reference 1.6 3.10.2: Consumer applications running on a particular platform should use the appropriate platform-specific entry ( DOS , Mac , or Unix ) if available. If the required platform-specific entry is not present and there is no file system entry ( FS ), the generic F entry should be used as a simple file specification. | 13:54.27 |
| sebras | zeniko: pdfref 1.7 contradicts this though and recommends F and UF. | 13:55.32 |
| | zeniko: at least this how I read it. | 13:57.01 |
| zeniko | sebras: yay for a stable specification! | 13:58.48 |
| sebras | zeniko: not my fault! :) | 14:01.59 |
| zeniko | sebras: given that the 1.6 specification has the far nicer layout/typography, I'd tend to go with that, though ;-) | 14:03.48 |
| sebras | zeniko: :) are you thinking of pdfref17 adapted to the iso-standard? | 14:11.38 |
| | zeniko: _that_ one is really ugly. luckily I still have the "original" pdfref17 here. | 14:12.09 |
| zeniko | sebras: yeah, that one - and I'm not that lucky (and thus still mostly use the 1.6 spec) | 14:14.12 |
| | Robin_Watts: I've just tested your fix for bug 691691 - and it doesn't help at all, I'm afraid | 14:15.03 |
| Robin_Watts | zeniko: Did you set the hint in the device? | 14:15.39 |
| zeniko | Before making any further guesses to what might help, I really should look into what all that memory is actually used for | 14:15.50 |
| | No, I've directly called pdf_mark_xref and pdf_clear_xref_to_mark | 14:16.40 |
| Robin_Watts | zeniko: Ah. No idea then :( | 14:17.44 |
| sebras | zeniko: it is still available: http://goo.gl/BTYlqh the other's are here http://www.adobe.com/devnet/pdf/pdf_reference_archive.html (and should you ever need 1.2, 1.1 or 1.0 let me know) | 14:20.09 |
| zeniko | sebras: Thanks for the first link! (the second is where I've got the 1.6 spec from, no need for any older ones) | 14:21.50 |
| sebras | zeninko: sometimes older specs may elaborate a bit more in case the current spec is not clear. I rember having delved far back a few times just to see what the intent was. | 14:25.44 |
| | oh and the non-iso 1.7 is at the top of the second link, but I though this was more convenient. | 14:26.39 |
| zeniko | sebras: ah, never noticed that | 14:27.22 |
| | Robin_Watts: if I run "mudraw -t pdf_reference_1-7.pdf", memory consumption goes from 25MB for the first few pages to over 100MB towards the end | 14:36.41 |
| MoonKnight | If it's possible, how can I join this work? Read code firstly? There are 100k loc out there... | 14:36.42 |
| Robin_Watts | zeniko: There are images at the end. | 14:37.16 |
| | those images are decompressed, and put into the store in case they are needed again. | 14:37.31 |
| | They will be evicted from the store if the store fills up. | 14:37.49 |
| | The store by default is something like 1<<24 bytes. | 14:38.03 |
| | Oh, -t. | 14:38.49 |
| zeniko | why are they decompressed - doesn't the text extraction device set FZ_IGNORE_IMAGE? | 14:39.12 |
| Robin_Watts | yeah, I missed the -t, sorry. | 14:39.28 |
| | Just trying some memento runs here. | 14:40.12 |
| zeniko | tor8: have you seen my question about transfer functions above? | 14:50.19 |
| Robin_Watts | zeniko: Transfer function support would be interesting yes. | 14:50.51 |
| | We have had a long term goal of adding color management into mupdf, probably by using lcms. | 14:51.14 |
| | and I think we (or at least I, certainly) had wondered if transfer functions might fall out of that nicely. | 14:51.29 |
| zeniko | I have so far failed to achieve the desired effect through new specialized colorspaces | 14:52.28 |
| | and had to settle for an additional fz_device call to be invoked at the end of a group/mask | 14:53.59 |
| | (since the transfer functions aren't supposed to be invoked during painting but only afterwards) | 14:54.39 |
| | not sure if color management would also fit at that point (or isn't that mostly required for images and then before they're actually painted?) | 14:55.20 |
| Robin_Watts | I'm also not sure. | 15:02.00 |
| sebras | MoonKnight: the easiest way would be for you to pick a bug in bugzilla (e.g. here http://bugs.ghostscript.com/buglist.cgi?product=MuPDF&component=mupdf&resolution=---) and try to fix it. | 15:04.14 |
| Robin_Watts | MoonKnight: By all means talk to us about which bug you pick first though, as we may be able to steer you away from some intractible ones etc. | 15:05.13 |
| tor8 | zeniko: well, if you have a solution to transfer functions that works now I'm sure we'd be happy to look at integrating it | 15:10.14 |
| henrys | http://xkcd.com/1312/ | 15:12.20 |
| Robin_Watts | Haskell seems pointless. If you want real academic uselessness you want to use orwell. If you want to actually code anything usable, caml (or SMLNJ). | 15:15.09 |
| sebras | henrys: :) but, but..haskell looks so nice! | 15:15.26 |
| | Robin_Watts: or erlang apparently. | 15:16.57 |
| henrys | In fairness I think python has been heavily influenced by haskell laziness - list comprehensions etc. and there is no question python is getting "used" | 15:22.31 |
| zeniko | tor8: http://git.ghostscript.com/?p=user/zeniko/mupdf.git;a=commitdiff;h=8cb36298703b6d4c6a5c20e1f55ede8260470acd | 15:26.27 |
| Robin_Watts | henrys: yeah, orwell had lazy (graph) evaluation as it's core idea. | 15:27.53 |
| | You can get lazy evaluation in SMLNJ too using continuations, but it's not as nice. | 15:28.22 |
| henrys | Robin_Watts: I've use ocaml but not sml/nj I assume they are similar | 15:34.47 |
| Robin_Watts | caml is smaller/cleaner than SMLNJ, I think. | 15:35.24 |
| | But it's been almost 20 years since I touched either, so :) | 15:35.51 |
| MoonKnight | ok, i'll try to find a bug first. | 15:39.01 |
| | Thanks to you all and your patience:] | 15:39.41 |
| Robin_Watts | MoonKnight: Or find a missing feature, and we can make an enhancement bug for it. | 15:40.14 |
| | Most developments are driven by some sort of need. | 15:40.24 |
| sebras | zeniko: TR should be ignored if TR2 is present, but there is no code do to that I think. | 15:40.30 |
| MoonKnight | Does mupdf support bookmark? | 15:40.44 |
| Robin_Watts | Not in the current windows/linux/macos viewer. The central lib does. | 15:41.21 |
| | But... working on the viewer rather than the core code has some issues. | 15:41.49 |
| | Firstly, anything you add will need to be done so it works on both windows and X11. | 15:42.17 |
| | and we are (eventually) going to replace the viewer with a better one at some point. | 15:42.34 |
| sebras | Robin_Watts: MoonKnight: well, actually the linux viewer does support "bookmarks" but they are promptly forgotten once you exit. ;) | 15:42.37 |
| zeniko | sebras: fixed | 15:46.07 |
| MoonKnight | And maseratis are at hand. | 15:47.28 |
| | Eh, what do you mean by "but they are promptly forgotten once you exit". | 15:48.10 |
| | sebras: Testing if this can reply somebody | 15:49.31 |
| Robin_Watts | And we have a git repo for the picsel code. | 15:55.58 |
| bencc | can gs embed or extract video from pdf? | 15:56.52 |
| Robin_Watts | no. | 15:57.28 |
| | or at least, not without you writing postscript. | 15:57.43 |
| bencc | are you familiar with other tools that support it? | 15:57.54 |
| Robin_Watts | and even then it wouldn't be a nice solution. | 15:57.57 |
| | If I had to do it, I'd use MuPDF. | 15:58.14 |
| | but even that would require coding. | 15:58.20 |
| | So the epage git repo weighs in at 1Gig. | 15:59.13 |
| | Which ain't bad. | 15:59.20 |
| bencc | epage? | 15:59.48 |
| tor8 | Robin_Watts: that's less heavy than I expected | 16:00.05 |
| | how many branches are in there? | 16:00.09 |
| Robin_Watts | bencc: Unrelated to your discussion. | 16:00.14 |
| | tor8: All of them :) | 16:00.27 |
| bencc | ok | 16:00.45 |
| tor8 | even the one you had to delete? ;) | 16:00.45 |
| bencc | : ) | 16:00.54 |
| Robin_Watts | 484. | 16:00.55 |
| bencc | Robin_Watts: what do you mean by writing phostscript to embed video? | 16:04.06 |
| Robin_Watts | The Ghostscript PDF handling is currently done as a postscript program. | 16:04.29 |
| | hence if you wrote more postscript you could leverage parts of that to do PDF manipulation. Maybe. | 16:04.56 |
| bencc | and it doesn't support file attachments? | 16:05.14 |
| Robin_Watts | I don't believe so. Certainly not trivially. | 16:05.38 |
| bencc | it seems that mupdf doesn't support it either | 16:06.00 |
| Robin_Watts | no as it stands, but it would be a lot easier to use MuPDF to write a tool to embed video than to start from gs. | 16:09.05 |
| kens | pdfwrite doesn't support the ATTACH pdfmark at the moment | 16:09.16 |
| | THere's an open enhancement request for it. | 16:09.30 |
| | But I'm not certain that's the same as embedding video anyway | 16:09.43 |
| Robin_Watts | tor8: Commit on robin/master for your consideration. | 16:52.10 |
| | henrys: So, now we have this git repo, what would you like done with it? | 17:32.25 |
| | Currently it's on peeved. | 17:32.30 |
| | I could copy it onto casper into a place where we can all get to it, but it's still private ? | 17:32.56 |
| henrys | Robin_Watts: yea should be on casper and private. | 17:33.27 |
| Robin_Watts | rsync running. Just as well ray isn't back to work yet, cos I'm sure this is killing the bandwidth out of his office. | 17:38.46 |
| | Has anyone heard how he is? | 17:38.56 |
| henrys | Robin_Watts: I haven't | 17:42.15 |
| Robin_Watts | tor8: For the logs, another review on robin/master (fixing the indetermism in broken_png_image.xps) | 18:25.14 |
| ray_laptop | Hi, Robin_Watts | 18:29.50 |
| | I saw the impressive performance improvements for bug 694585. | 18:30.07 |
| | Unfortunately, the bug doesn't have a command line description for (mudraw ?) that allows me to try it. Do you know what params I would need to use to duplicate your results. | 18:31.04 |
| henrys | ray_laptop: how are you doing? | 18:34.34 |
| Robin_Watts | ray_laptop: mudraw.exe -o out.ppm infile.pdf | 18:44.06 |
| | ray_laptop: or rather: mudraw.exe -o out.ppm And_He_Built_A_Crooked_House.pdf | 18:44.39 |
| | -d would probably make the improvements better in fact. | 18:44.56 |
| | As Henrys says, how are you feeling? | 18:45.22 |
| | I fear I may be eating up a lot of your office bandwidth at the moment - sorry. | 18:45.44 |
| | http://www.thisiscolossal.com/2014/01/one-step-closer-to-hover-boards-three-dimensional-mid-air-acoustic-manipulation/ | 18:56.56 |
| henrys | errands bbiaw | 19:02.26 |
| sebras | Robin_Watts: is it just me or has there been a resurgence of animated gifs?! | 19:58.22 |
| Robin_Watts | on the web? yeah. | 20:04.57 |
| ray_laptop | My wife just took my parents to the airport. There went my chauffeur :-( | 20:30.57 |
| | Robin_Watts: thanks for the info. Interestingly, Ghostscript does the ppmraw -r72 in 3.9 seconds and mudraw -d (base 1.3) takes 25.7 seconds | 20:40.07 |
| | Robin_Watts: so I guess the info on the two meshing approaches is not the way I remembered | 20:40.38 |
| | Robin_Watts: and gs with -dMaxBitmap=300m (to force page mode) takes 3.4 seconds. The default uses 11 bands in clist mode | 20:42.27 |
| | Robin_Watts: and on some of the features, GS is a bit closer to Acrobat 9 | 20:45.21 |
| Robin_Watts | ray_laptop: The slowness in this file is more to do with the fact that we use functions for the deviceN stuff. | 23:57.29 |
| | We could probably do better by using tables or something. | 23:57.51 |
| | Forward 1 day (to 2014/01/04)>>> | |
IRC Logs