| | <<<Back 1 day (to 2016/05/29) | 20160530 |
| tempus_fol | Hello, thank you for your prompt answers and fixes in bugs #696797 and #696799; I've tried to understand #696797 and I'm currently reaching out a dev at veraPDF. The latest git version works fine, I've just to add more often "-dPDFACompatibilityPolicy=1" or it won't produce an output but that was pretty much expected. About #696797, I've noticed right now that it can be easily reproduced converting any PDFA/1-a produced by | 07:56.11 |
| | LibreOffice to PDFA/2-b... I'll wait for a reply from veraPDF. | 07:56.13 |
| kens | A fair number of producers produce 'inefficient' output. As I recall the OPOM which was set in that file had no actual effect. | 07:57.07 |
| | Err wait, wrong file :) | 07:57.17 |
| | Ah yeah. Well I'm prepared to believe there is a problem with that file, but I can't tell, from the report, what VeraPDF thinks the problem is. | 07:57.59 |
| | Essentially the 'font' is composed of a number of objects. At the top is the type 0 font | 07:58.17 |
| | This has an Encoding, and a number of descendant (child) fonts | 07:58.35 |
| | The Encoding is a CMap, which has 'CIDSystemInfo' and the CIDFont (the descendant) also has 'CIDSystemInfo'. | 07:59.34 |
| | The requirement is that these should be compatible. | 07:59.46 |
| | In the case of the file we produce, they aren't just compatible, they are the *same* object :-) | 08:00.05 |
| | If the VeraPDF developer wants to chat I'd be happy to discuss it here, or via email if that's prefereable | 08:00.48 |
| tempus_fol | insofar I've opened a issue on their github tracker ( https://github.com/veraPDF/veraPDF-library/issues/558 ) and exchanged a mail; your explanation seems pretty clear, if necessary I'll reference your offer to chat directly too :) | 08:16.46 |
| kens | Thanks for the link | 08:16.59 |
| tempus_fol | kens: the issue has been closed, it was indeed a veraPDF's mistake - the latest veraPDF snapshots don't complain any more | 10:13.38 |
| kens | OK that's great, thanks for letting me know! | 10:13.58 |
| Robin_Watts | On the offchance anyone is interested: https://www.amazon.co.uk/dp/B00M8ABHVQ/ref=gbps_img_s-3_5227_739f275b?smid=A3P5ROKL5A1OLE&pf_rd_p=899825227&pf_rd_s=slot-3&pf_rd_t=701&pf_rd_i=gb_main&pf_rd_m=A3P5ROKL5A1OLE&pf_rd_r=R38748EDZVY7N4T78KBZ | 10:47.01 |
| jigs | hello ther | 12:13.10 |
| Robin_Watts | jigs: Hi. If you have a question, don't wait for people to acknowledge you, just ask it :) | 12:15.58 |
| jigs | fine | 12:18.12 |
| | i have integrate MUpdf in my android application | 12:18.26 |
| Robin_Watts | jigs: OK. Is the Android Application going to released under the GNU AGPL ? | 12:18.50 |
| jigs | its android applicattion | 12:19.11 |
| | and ri8now in it is in developing mode | 12:19.30 |
| Robin_Watts | OK, but when it's complete will it be released under the GNU AGPL ? | 12:19.47 |
| jigs | my issue is that | 12:19.49 |
| Robin_Watts | Or is it going to be a non GNU AGPL release? | 12:20.03 |
| jigs | i'm not sure about it sir | 12:20.35 |
| | may be its non GNU | 12:20.43 |
| Robin_Watts | So for it to be non GNU, you'd need to take a commercial license for MuPDF. And that will cost you money, | 12:21.09 |
| | I like to point this out to people early on in the process so it doesn't come as a nasty shock to them. | 12:21.37 |
| jigs | a hm ..sure . i 'll make sure this thing | 12:21.40 |
| | but I guess open source is available | 12:22.24 |
| | is it compulsory to purchase licance? | 12:22.37 |
| Robin_Watts | jigs: MuPDF is available under 2 licenses. | 12:22.49 |
| | The GNU AGPL and the Artifex Commercial License. | 12:23.00 |
| | If you can abide by the terms of the GNU AGPL, then you can use it for free. | 12:23.17 |
| jigs | a hm . let me clear this thing with senior developer | 12:23.37 |
| Robin_Watts | If not, then you MUST take the Artifex Commercial License. | 12:23.37 |
| | If you aren't prepared to accept one of the licenses, then you cannot use MuPDF. | 12:24.05 |
| jigs | not an issue in that case . | 12:24.14 |
| | apart from this can you prove me some of the technical stuff | 12:24.26 |
| | *provide | 12:24.41 |
| Robin_Watts | So, you're saying that your app *will* be released under the GNU AGPL ? | 12:24.41 |
| jigs | yes , if it is mandatory thing then purchasing license is not an issue | 12:25.59 |
| | what i want !, i have some technical query | 12:26.16 |
| | get back to you in 10 min sir | 12:26.29 |
| Robin_Watts | OK. You might want to get your purchasing guys to start looking into that now. | 12:26.41 |
| | The license doesn't need to start until you're ready to ship, but you don't want to find out that you've budgeted $X for the license, and done all the development work, and then find out that the price is $10*X. | 12:27.42 |
| | As to technical questions, sure, ask away. | 12:28.04 |
| | The free version of MuPDF comes with no support. | 12:28.23 |
| | The commercial version can come with support or not depending on what is written into the license (it affects the price). | 12:28.48 |
| | Having said that, we do try to help people on here as best we can. | 12:29.05 |
| jigs | sorry for the inconvenience #Robin , actually little bday celebration here :) | 12:50.22 |
| | let come to the issue | 12:50.30 |
| Robin_Watts | No problem. | 12:50.34 |
| jigs | I want to add image at predefined pages | 12:51.03 |
| | let say i have 10 pages of pdf | 12:51.15 |
| | and 2nd and 5th page are blank ,then i want to add image on that 2nd and 5th page | 12:51.58 |
| Robin_Watts | To be clear, is this you wanting to open a PDF, add an image, and then saving the PDF out again? | 12:52.04 |
| | Or is this you wanting to open a PDF, and display that PDF with added images? | 12:52.23 |
| | i.e. inserting adverts into spaces already allowed for ? | 12:52.32 |
| jigs | not want saving pdf again | 12:52.33 |
| | i already saved my pdf coming from server | 12:52.58 |
| Robin_Watts | Neither of those things can be done with the current Android app without making some changes. | 12:53.18 |
| jigs | now just want to add specific images and display it in predefined page of that pdf | 12:53.26 |
| Robin_Watts | Just adding some specific images is not too big a job though. | 12:53.42 |
| jigs | ya exactly . | 12:53.42 |
| | is there any specific method available in library for that | 12:54.18 |
| Robin_Watts | MuPDF is a core C library to load/render/manipulate PDF (and other format) files. | 12:54.19 |
| | And then we have some tools (such as the android viewer) that are thin wrappers around this library. | 12:54.44 |
| | The Core C library can easily do what you want. | 12:54.57 |
| jigs | a hm | 12:55.14 |
| Robin_Watts | but you'll need to make changes within the android viewer levels to do what you want. | 12:55.27 |
| jigs | any reference link for dealing with that native C code stuff | 12:55.46 |
| Robin_Watts | The android viewer is a mixture of C and java code. | 12:55.52 |
| | The C code is mostly to allow the java code to call down to the C library. | 12:56.55 |
| jigs | I just google on it and found "In pdf-annot-edit.c there are functions such as pdf_set_markup_annot_quadpoints and pdf_set_ink_annot_list. " | 12:57.04 |
| Robin_Watts | jigs: You don't want annotations. | 12:57.17 |
| jigs | so you mean annotation is not needed in my case | 12:57.44 |
| Robin_Watts | jigs: Yes. If I was you, I wouldn't be using an annotation. | 12:58.00 |
| | OK, so... the way MuPDF works at the C library... | 12:58.49 |
| | you open a document. | 12:58.55 |
| | you get a page from that document. | 12:59.01 |
| jigs | don't know exactly #annotation role here , that is why little bit confused | 12:59.16 |
| | can you provide me reference link sir | 12:59.27 |
| kens | Annotations are documented in the PDF Reference | 12:59.49 |
| Robin_Watts | You make a 'pixmap', and you open a 'draw device' and you 'run' the page to the draw device. | 12:59.54 |
| | You don't want annotations. | 13:00.08 |
| kens | I agree FWIW, annotations are not helpful here | 13:00.43 |
| Robin_Watts | jigs: I'm trying to give you an overview of the process. Just listen to my description, and I'll try and explain a way to work. | 13:01.04 |
| jigs | yup sure | 13:01.17 |
| Robin_Watts | The core part of muPDF is the device interface. | 13:01.48 |
| jigs | a hm | 13:02.03 |
| Robin_Watts | Each call to the device interface says "I have this graphical object, here". | 13:02.05 |
| | So you'll get calls to say "put this image here", "put this text here", "draw this path here" etc. | 13:02.25 |
| jigs | a hm | 13:02.43 |
| Robin_Watts | So when we 'run' a page, all we do is feed each object on the page in turn to the draw device. | 13:02.58 |
| jigs | a hm | 13:03.24 |
| Robin_Watts | What I would propose is that we change the code so that every page has both the page contents from the PDF, plus optionally, an extra image. | 13:03.55 |
| jigs | yup exactly | 13:04.29 |
| Robin_Watts | OK. So the way the android app works is that we use a 'display_list' device. | 13:04.54 |
| jigs | a hm | 13:05.23 |
| Robin_Watts | When we first flip to a page, we make a new display list (empty to start with). We then make a display list device that just puts every object it's called with into that list. | 13:05.58 |
| | And we then run the page contents to that device. | 13:06.05 |
| jigs | ok | 13:06.27 |
| | then | 13:06.30 |
| Robin_Watts | Then we close the device, and we're left with a display list that we can render again and again whenever the page is panned or zoomed. | 13:06.34 |
| jigs | ok | 13:07.01 |
| Robin_Watts | So what we want to do is to just call that display list device with an extra 'put an image here' call before we close it. | 13:07.02 |
| | So if you look at platform/android/viewer/jni/mupdf.c | 13:07.24 |
| | and look at MuPDFCore_drawPage at line 759 | 13:08.45 |
| jigs | just a min sir | 13:08.56 |
| Robin_Watts | (I'm assuming you're looking at up to date code) | 13:08.58 |
| jigs | where did i get platform/android/viewer/jni/mupdf.c | 13:09.15 |
| | this path | 13:09.19 |
| | ? | 13:10.00 |
| Robin_Watts | jigs: What version of MuPDF are you looking at ? | 13:10.22 |
| jigs | where can i find the version sir ?actually source was downloaded before 2 days ago | 13:11.31 |
| | and i already integrate library project in my application | 13:11.49 |
| Robin_Watts | jigs: Where did you download it from? | 13:12.30 |
| | On older versions of the source the path may be: platform/android/jni/mupdf.c | 13:12.53 |
| | include/mupdf/fitz/version.h will have the version in | 13:14.10 |
| jigs | let me verify it | 13:15.09 |
| | not getting any path like include/ etc sir | 13:19.00 |
| Robin_Watts | jigs: Well, I don't know what to say. I can't guess what strange version of our source you have. | 13:20.41 |
| jigs | a hm , sorry for that | 13:21.55 |
| | thanks for clear things | 13:22.10 |
| | can you just clear few more things sir | 13:22.35 |
| | how can i call this display list as you descrbe above | 13:23.00 |
| Robin_Watts | I was going to show you in the source, but if you don't have it, I can't. | 13:23.37 |
| kens | I'm guessing this is this Stack Overflow question ? : | 13:24.09 |
| | http://stackoverflow.com/questions/37525197/image-adding-like-overlay-on-specific-pdf-page-mupdf-android | 13:24.09 |
| jigs | this was my post #kens | 13:26.45 |
| | :) | 13:26.55 |
| | i used this https://codeload.github.com/geek5nan/AndroidMuPDFDemo/zip/master | 13:28.12 |
| | #Robin | 13:28.19 |
| kens | I'd suggest it would be much better to get the code from either our latest release or out Git repository | 13:28.50 |
| | That way you will be definitely using our code and you can discuss things with the developers | 13:29.24 |
| jigs | #kens , please see ablove | 13:29.41 |
| kens | See what ? | 13:29.53 |
| jigs | i attach link whatt i m used | 13:30.00 |
| | https://codeload.github.com/geek5nan/AndroidMuPDFDemo/zip/master | 13:30.06 |
| Robin_Watts | jigs: Yeah, he's not shipping out source. | 13:30.07 |
| | That's illegal. | 13:30.09 |
| kens | And I said 'it would be better to use our code' | 13:30.13 |
| Robin_Watts | I'm not helping with that. | 13:30.15 |
| kens | Yes we should probably see about getting that removed (nicely if possible) | 13:30.57 |
| jigs | i'm not aware of this sir , just 2 days before i started working om that | 13:31.33 |
| kens | Probably best you stop using it. | 13:31.43 |
| jigs | oks | 13:31.51 |
| | can you provide me your code stuff or links where i can found source | 13:32.14 |
| Robin_Watts | mupdf.com | 13:32.34 |
| kens | You can start athttp://www.mupdf.com | 13:32.36 |
| Robin_Watts | goes for lunch. | 13:32.42 |
| jigs | :) | 13:32.59 |
| | enjoy ur lunch | 13:33.10 |
| aleray | hi, I have a pdf with individual pages comming from different software | 13:43.19 |
| | The page sizes are all a little bit different. Some pages avec a cropbox defined, some other not | 13:43.46 |
| | I would like to crop all the pages so the output is of a common size | 13:44.12 |
| | do you knoy how I can do this? | 13:44.22 |
| kens | Not easily. Ghostscript and the pdfwrite device will normally preserve a /CropBox if present in the original. You would need to modiofy the PDF interpreter so that it did not preserve the CropBox and then add a /PAGES pdfmark to put the CropBox you do want into the final file | 13:46.11 |
| | The preservation of CropBox is done in pdfshowpage_finish in /ghostpdl/Resource/Init/pdf_main.ps | 13:47.38 |
| tor8 | aleray: http://pastebin.com/raw/xbrDc7t1 save that as 'resize.js' and run 'mutool run resize.js input.pdf' | 13:49.25 |
| | of course, you'll want to change the cropbox/mediabox to the actual size you want | 13:49.49 |
| | but that should get you started | 13:49.53 |
| | aleray: you need to download and build mupdf first though | 13:51.08 |
| aleray | tor8, thanks | 13:51.13 |
| | I try that | 13:51.17 |
| tor8 | git clone --recursive git://git.ghostscript.com/mupdf.git | 13:51.43 |
| aleray | it is on my distribution | 13:53.01 |
| tor8 | mutool run is very new, so your distribution may not have the functionality yet | 13:53.32 |
| | but you can try | 13:53.39 |
| aleray | archlinux | 13:55.23 |
| | I try | 13:55.25 |
| tor8 | if you get a ReferenceError: 'PDFDocument' is not defined, change the line to "var pdf = new mupdf.PDFDocument(argv[1]);" | 13:58.06 |
| aleray | tor8, how can I get the size of the current page? | 14:00.20 |
| tor8 | page.MediaBox has the current size | 14:00.31 |
| | it's an array with four elements | 14:00.44 |
| aleray | ok thanks | 14:00.53 |
| tor8 | [lower-left-x, lower-left-y, upper-right-x, upper-right-y] | 14:00.58 |
| | 0,0 is the lower left, +x is right and +y is up | 14:01.19 |
| aleray | tor8, ok thanks | 14:08.37 |
| | it worked | 14:08.40 |
| | that's really nice | 14:08.45 |
| tor8 | aleray: glad I could be of help. | 14:10.24 |
| aleray | tor8, I think I'm going to fall in love with mupdf | 14:13.07 |
| | tor8, is there a way with mutool to set the presentation of the pdf? It is in single pages but I'd like it in spread from te second page | 14:26.03 |
| tor8 | do you mean how acrobat displays it by default? | 14:30.26 |
| aleray | yes | 14:30.34 |
| | tor8, | 14:30.37 |
| Robin_Watts | aleray: Are you talking about editing the PDF so that it appears with pages 2/3 as page 2, pages 4/5 as page 4 etc? | 14:31.30 |
| | or are you talking about changing the behaviour of the MuPDF viewer? | 14:31.43 |
| aleray | Robin_Watts, I'm wondering if I can set the presentation mode insctructions in the pdf, for any pdf viewer | 14:33.01 |
| Robin_Watts | aleray: Ah, right. I bet mutool run can do that, but that's tor's baby. | 14:34.04 |
| tor8 | aleray: chapter 8.1 of the pdf reference has a section on "Viewer Preferences" | 14:34.19 |
| | but I don't see a reference to anything that could be the "side by side" view | 14:35.23 |
| aleray | tor8, ok | 14:35.43 |
| tor8 | ah, in the root object there's a PageLayout setting | 14:35.52 |
| | so, pdf.getTrailer().Root.PageLayout = "TwoColumnLeft" | 14:36.51 |
| | chapter 3.6.1 table 3.25 in the pdf reference | 14:37.16 |
| | hm, that should probably be "TwoColumnRight" for your example | 14:38.28 |
| aleray | perfect | 14:42.44 |
| Robin_Watts | tor8: OK, so updated versions of my commits online. | 15:16.35 |
| | If you build without G/RGB/CMYK on it will force N. | 15:16.51 |
| | If you build with N and none of the others, it will correctly render everything G/RGB and CMYK, just not as fast. | 15:17.31 |
| | (I've tested G and RGB, just testing CMYK now). | 15:17.57 |
| | CMYK passed too. | 15:18.40 |
| tor8 | Robin_Watts: what about when G is 1 and RGB and CMYK are 0 | 15:19.49 |
| Robin_Watts | tor8: That'll render G correctly, and nothing else. | 15:20.28 |
| | If you want G and (slow) others, use G + N | 15:20.35 |
| tor8 | do we want to allow configurations where certain configs don't work? | 15:21.14 |
| Robin_Watts | definitely. | 15:21.44 |
| | If I'm building for a monochrome printer, why include RGB and CMYK configs ? | 15:22.06 |
| tor8 | if building for an RGB printer, we still need G (to render soft mask groups) | 15:23.02 |
| Robin_Watts | tor8: Those plotters aren't covered by the 'G' ones :) | 15:23.22 |
| tor8 | and alpha-only rendering, for the other kind of soft masks | 15:23.30 |
| Robin_Watts | Figuring out which ones to exclude was a significant part of my weekend :) | 15:23.44 |
| | I can safely choose only RGB and cluster -filter=ppmraw.200.0 with no diffs. | 15:24.22 |
| | similarly with CMYK and -filter=pkmraw.200.0 | 15:24.33 |
| | and G and -filter=pgmraw.200.0 | 15:24.43 |
| | and only N and any of them. | 15:24.54 |
| tor8 | fz_draw_begin_mask always expects to be able to draw with destination gray-noalpha or nocolor-alpha | 15:27.05 |
| | we may not have all possible draw operations in soft masks in the cluster | 15:27.43 |
| Robin_Watts | tor8: If we are missing any I'll add them. | 15:28.14 |
| | but I find it unlikely that we're missing many in the cluster. | 15:28.28 |
| tor8 | having a matrix of alll the plotter function permutations could be helpful | 15:29.19 |
| Robin_Watts | Of all the ones used? or of all the ones we have? | 15:29.50 |
| tor8 | which ones we have, and which ones are included in the various ifdefs | 15:30.13 |
| | btw, a bunch of unused function warnings in draw-paint.c | 15:30.25 |
| Robin_Watts | For all the ones used, you build with all the plotters enabled, and enable TRACK_USAGE and then search in the cluster. | 15:30.29 |
| tor8 | 'template_solid_color_N_general' 'template_span_N_with_alpha_general' 'template_span_N_general' | 15:30.36 |
| Robin_Watts | Those are supposed to be inlines... | 15:30.47 |
| | They are inlines. So the compiler has no business telling me they are unused. | 15:32.18 |
| tor8 | thing is, right now if we miss a case we'll hit an assert if we miss any functions that draw to a gray pixmap if G is 0 but that function is invoked from a softmask | 15:32.20 |
| | Robin_Watts: I agree. I think the compiler may make a distinction between .h and .c files for that warning :( | 15:32.38 |
| | and in a release build that'll just crash with a segfault | 15:32.49 |
| Robin_Watts | tor8: No. In a release build it'll just miss stuff out. | 15:33.02 |
| tor8 | oh, there's an if (fn == NULL) test after | 15:33.27 |
| | still, that's probably even worse... | 15:33.31 |
| | then you won't even know it failed | 15:33.46 |
| Robin_Watts | The alternative is to build N in for all caes. | 15:34.36 |
| | The alternative is to build N in for all cases. | 15:34.38 |
| | And people have the freedom to do that if they want. | 15:34.47 |
| tor8 | there must be some overlap between which functions are used by G and RGB and CMYK? | 15:34.49 |
| Robin_Watts | tor8: Only the ones that are ALWAYS built in. | 15:35.23 |
| | (i.e. the ones needed for softmasks etc) | 15:35.32 |
| | The templates that G/RGB/CMYK use are shared. The instances of them are not. | 15:35.59 |
| tor8 | Robin_Watts: I'm looking at fz_paint_glyph_alpha | 15:38.51 |
| | fz_paint_glyph_alpha_1_da is in the G set, fz_paint_glyph_alpha_1 is in the always set | 15:39.15 |
| Robin_Watts | Right. That uses a #include for the template rather than a static inline. | 15:39.29 |
| tor8 | and there's a goto fallback which then depends on the N set being defined to actually do anything | 15:39.30 |
| Robin_Watts | There is a goto fallback that depends on the N set being defined if the G set is not, and the G set is called. | 15:40.07 |
| tor8 | personally, I'd be more comfortable making the G set part of ALWAYS and having defines to drop the RGB and CMYK variants | 15:40.14 |
| | and leave N optional for specialized printers, as it is now | 15:40.38 |
| Robin_Watts | tor8: But for screen use, the G may be useless. | 15:40.56 |
| tor8 | parts of G may be useless; but most of it will be needed for PDF soft masks | 15:41.16 |
| Robin_Watts | Exactly as much of it that is not included in the 'G' set is needed :) | 15:41.38 |
| tor8 | so the 'G' set is G+destination-alpha and the always set is G+no-alpha? | 15:42.38 |
| | then I'm with you | 15:42.41 |
| | and indeed, that's what it looks like for fz_paint_glyph | 15:43.30 |
| | and the split nature of the G category also explains the somewhat awkward goto fallback cases | 15:43.49 |
| Robin_Watts | yeah. | 15:43.58 |
| tor8 | if the other plotters follow the same scheme, LGTM | 15:44.17 |
| Robin_Watts | I *could* rearrange the logic so that the G case is just before the N case and we do fallthrough to the default, but I think that would be less readable. | 15:44.24 |
| tor8 | yes, this is fine | 15:44.36 |
| | it's the ifdef !G bracketing that's awkward | 15:44.47 |
| Robin_Watts | Without the ifdef !G around the fallback: we'll get "unused label" warnings. | 15:45.10 |
| tor8 | yeah, I understand why it's there | 15:45.19 |
| | I've got a few followups on tor/master | 15:45.28 |
| Robin_Watts | So can I push this lot, or do they need to be folded in? | 15:46.04 |
| tor8 | up to you | 15:46.22 |
| | I'd keep the commits as is, to follow the changes | 15:46.43 |
| Robin_Watts | We should #if FZ_ENABLE_CBZ as well in the document writer. | 15:48.04 |
| | and in muconvert. | 15:48.13 |
| | Hmm. Possibly we should have a FZ_ENABLE_PDFOUT that defaults to FZ_ENABLE_PDF ? | 15:48.57 |
| | cos you might want to read SVG and write PDF or something? | 15:49.09 |
| | I'd like an FZ_ENABLE_JS too. | 15:50.17 |
| | Cos we don't want JS in a printer. | 15:50.22 |
| | But I agree that keeping these separate is best, so I will push mine now. OK ? | 15:50.56 |
| tor8 | the only reason for FZ_ENABLE_PDF in muconvert and mudraw is because the pdf-write device depends on the pdf parser | 15:51.01 |
| | JS is only pulled in if murun.c is included, so for a printer that wouldn't be an issue | 15:51.42 |
| | though the pdf js bindings would probably be nice to have guarded by a FZ_ENABLE_JS | 15:51.55 |
| | go ahead | 15:52.08 |
| Robin_Watts | I would arrange that mutool didn't include murun if FZ_ENABLE_JS was defined. | 15:52.29 |
| tor8 | Robin_Watts: yes, much like we now exclude pdfclean if FZ_ENABLE_PDF is 0 | 15:52.56 |
| Robin_Watts | I vaguely like the idea of FZ_ENABLE_XXX_OUT. | 15:53.08 |
| | cos that would cut mudraw down. | 15:53.16 |
| tor8 | the output code is tiny in comparison to everything else though | 15:53.27 |
| Robin_Watts | to #artifex. | 15:53.47 |
| | Forward 1 day (to 2016/05/31)>>> | |
IRC Logs