| | <<<Back 1 day (to 2012/08/29) | 2012/08/30 |
| kens | Robin_Watts : ping | 13:49.45 |
| Robin_Watts | pong | 13:58.23 |
| kens | Robin what app and switch do I need to get MuPDF to emit a linearised PDF ? | 13:58.57 |
| Robin_Watts | mubusy clean -l in.pdf out.pdf | 13:59.16 |
| kens | Hmm, I don't have a mubusy | 13:59.26 |
| Robin_Watts | That's lowercase L. | 13:59.30 |
| | What platform ? | 13:59.37 |
| kens | Windows | 13:59.43 |
| Robin_Watts | Then you should have a mubusy, | 13:59.55 |
| kens | A .exe ? | 14:00.03 |
| Robin_Watts | yes. | 14:00.23 |
| | win32/debug/mubusy.exe | 14:00.33 |
| kens | I have pdfclean, pdfdraw, pdfextract, pdfshow and xpsdraw | 14:00.33 |
| Robin_Watts | How old is your codebase ? | 14:00.46 |
| kens | Not that old, I have a mubusy sub folder | 14:00.55 |
| Robin_Watts | We haven't shipped those for over a year. | 14:01.00 |
| kens | could be old ones left over | 14:01.23 |
| | I do have a mubusy sub fodler, with object files, but no executable in there | 14:01.45 |
| | Yes, those .exe are nearly 12 months old | 14:02.09 |
| | I'l open the solution | 14:02.29 |
| Robin_Watts | Are you doing 'build solution' or 'build mudraw' ? | 14:03.12 |
| kens | I think I did build solution | 14:03.24 |
| | Building mubusy gives me a load of errors | 14:03.33 |
| Robin_Watts | such as ? | 14:03.42 |
| kens | missing source files | 14:03.48 |
| | Looks like thirdparty is not there | 14:04.09 |
| | Possibly not in the correct place | 14:04.46 |
| | Project is using ..\thirdparty | 14:05.12 |
| | Ah, wrong version of jpeg | 14:05.27 |
| | Must be out of date | 14:05.31 |
| | Yes, they are all too old | 14:06.02 |
| | WHere are you keeping the thirdparty sources ? | 14:06.12 |
| Robin_Watts | mupdf.com/download | 14:06.59 |
| kens | OK I'll go fetch | 14:07.07 |
| | thanks | 14:07.10 |
| Robin_Watts | np. | 14:07.16 |
| kens | That's a lot happier, thanks | 14:10.29 |
| paulgardiner | Robin_Watts, tor8: a few commits on paulg/forms if you have a moment. | 14:31.46 |
| Robin_Watts | ok. | 14:32.23 |
| paulgardiner | ta | 14:32.29 |
| kens | Hmm Robin_Watts looking at the output from mubusy when linearised.... | 14:39.16 |
| | I see that teh Info, Root, Metadata and pages tree are included before the first page object | 14:39.46 |
| | I thought that the first page object preceded those | 14:40.08 |
| | (maybe my source is out of date) | 14:40.18 |
| | Or perhaps I'm wrong, since Acrobat X likes your file :-) | 14:41.09 |
| | OK the Info dict definitely shouldn't be there (p 1031 of the 1.7 reference) | 14:43.54 |
| Robin_Watts | kens: I think that technically the catalog stuff should all come later. | 14:44.02 |
| kens | The Catalog should be there, its specififed as such | 14:44.17 |
| Robin_Watts | but Acrobat liked it, so I stopped worrying. | 14:44.21 |
| kens | THe Info dict shouldn't | 14:44.23 |
| Robin_Watts | The pages tree etc, I meant. | 14:44.34 |
| | sorry. | 14:44.46 |
| kens | Oh yes, teh pges tree is supposed to be elsewhere | 14:44.47 |
| Robin_Watts | but the pages tree is very small, so if Acrobat wasn't going to complain, I wasn't going to worry about it. | 14:45.14 |
| kens | Typical, Acrobat is bleating about something in my file buyt I can't figure out what, but doesn't actually enforce the simple stuff like where these objects should be ;-) | 14:45.20 |
| | I wonder if I messed up and put the Catalog in the wrong place. | 14:45.46 |
| | No, my Catalog is correct. | 14:46.02 |
| | Back to my first theory, my Hint stream is wrong. | 14:46.14 |
| chrisl | Robin_Watts: do you happen to know if using c99 features in lcms2 was a conscious decision on Marti's part, or something that has crept in unintentionally? | 14:47.10 |
| Robin_Watts | I don't think Acrobat actually looks at the hint stream. | 14:47.10 |
| | such as ? | 14:47.17 |
| chrisl | sqrtf() | 14:47.25 |
| kens | Robin_Watts : then I'm puzzled what irts complaining about :-( | 14:47.30 |
| Robin_Watts | kens: I feel your pain | 14:47.49 |
| | chrisl: Pass. | 14:47.58 |
| chrisl | Okay, no worries.... | 14:48.08 |
| kens | I wonder if Acrobat expects some stuff to be before the first page, that the sepc says should be later. | 14:48.28 |
| | I guess I need to fire up Distiller | 14:48.36 |
| | No, the Acrobat ordering matches mine. Now I'm really confused. | 14:51.17 |
| | Huh, Distiller puts the hint stream before the document catalog, which is *not* what the spec says | 14:52.55 |
| | Part 5 (hint stream) Can precede or follow part 6 (first page) but part 4 (document catalog) is supposed to precede iot. | 14:53.50 |
| | Nice to see Adobe sticking to their crap standard so well | 14:54.03 |
| | Hmm, I wonder... I've forgotten to include an /ID in my trailer dict.... | 14:55.15 |
| | No, its supposed to be optional | 14:56.42 |
| | chrisl this mail from 'Darshan' about the installer, I think we can do a silent install ? | 15:00.37 |
| chrisl | kens: yes, we can - I'll need to look up how, though. Although I *think* the uninstaller doesn't work silently | 15:01.33 |
| kens | OK do you want to reply to him or shall I ? | 15:01.52 |
| chrisl | I guess I will - btw, the answer is in the FAQ..... | 15:02.31 |
| kens | :-) | 15:02.38 |
| chrisl | Erm, he hasn't actually asked a question.... | 15:03.52 |
| kens | I thought his original mail asked if a silent install was possible | 15:04.16 |
| chrisl | There are two "points" in the mail, but no actual questions | 15:04.42 |
| kens | OK so he didn't directly ask, but it is implied. | 15:04.42 |
| | "Is there an to install in the silent mode or can you provide us a "MergeModule". " | 15:04.58 |
| | So he missed of the question mark :-) | 15:05.05 |
| chrisl | Well, what does "Supported Environment" imply? | 15:05.10 |
| kens | Beats me | 15:05.16 |
| Robin_Watts | I reckon Scotts email missed the mark too. | 15:05.21 |
| kens | You could reply that 'supported environment' is 'GPL version is supplied without support' and ask what e means | 15:06.26 |
| | I also have no idea what a 'MergeModule' is, but suspect it may be related to the Microsoft Installer, whcih we dont' use. | 15:07.03 |
| | Indeed: | 15:07.47 |
| | "Merge modules provide a standard method by which developers deliver shared Windows Installer components and setup logic to their applications." | 15:07.47 |
| Robin_Watts | I read his email as "I want to make our software install all in one hit, and hide the fact we are using gs from our customers as it will only confuse them". | 15:07.56 |
| kens | Yes, possibly | 15:08.06 |
| | Or at least ask questions they don't want to have to have them answer | 15:08.26 |
| Robin_Watts | which raises red flags about valid GPL usage (but doesn't necessarily preclude it). | 15:08.28 |
| kens | We certainly won't want to supply a MSI 'MergeModule' | 15:09.35 |
| chrisl | Well, giving the benefit of the doubt, I think he did say if we satisfy their requirements, they'll be in touch about licensing | 15:10.12 |
| kens | Yes, agreed. | 15:10.34 |
| | OK Acrobat clearly doesn't look at the hint stream at all. | 15:11.57 |
| | I just replaced a Flate encoded stream with all '0' and it did not complain | 15:12.11 |
| | And indeed even claimed the file was 'optimised for fast web view' | 15:12.33 |
| Robin_Watts | indeed. | 15:16.50 |
| kens | scratches head | 15:17.01 |
| | No idea what I'm doing wrong.... | 15:17.10 |
| Robin_Watts | kens: Put the file online somewhere, and I'll have a look ? | 15:18.20 |
| kens | I guess I'd better check the xref offsets | 15:18.21 |
| | Robin_Watts : I'mm mail it, its really small | 15:18.30 |
| Robin_Watts | mail is bad M'kay. | 15:18.45 |
| kens | OK well I can put it on casper I guess. | 15:18.58 |
| Robin_Watts | Less chance of corruption/spam filtering etc that way, I reckon. | 15:19.14 |
| kens | takes me longer though, that's all | 15:19.26 |
| Robin_Watts | pscp file.pdf gs: ? | 15:19.41 |
| kens | what is pscp ? | 15:19.56 |
| Robin_Watts | pscp is puttys scp client. | 15:20.07 |
| kens | never knew it had one | 15:20.20 |
| Robin_Watts | gs is my putty saved session for casper. | 15:20.45 |
| kens | OK in casper home/ken | 15:21.28 |
| | out.pdf | 15:21.31 |
| Robin_Watts | so: pscp file.pdf gs:whatever copies files to casper, and pscp gs:file.pdf blah.pdf copies them back. | 15:21.32 |
| kens | I normally use winscp | 15:21.49 |
| | TOo many copies of Visual Studio running, hard to find the one I want :-( | 15:22.54 |
| Robin_Watts | Your 'E' offset takes you to object 15. | 15:32.52 |
| kens | Yes ? | 15:33.01 |
| Robin_Watts | Mine takes me to object 1. | 15:33.06 |
| kens | Its hte end of the first page | 15:33.10 |
| | Object 15 is hte thint stream, and follows page 1 in my file | 15:33.23 |
| Robin_Watts | OK, yes. | 15:33.30 |
| | Was just looking for differences. | 15:33.34 |
| kens | Please keep trying ! | 15:33.42 |
| | A fresh pair of eyes migh tsee what I'm missing.... | 15:33.53 |
| | By co-incidence I'd jusrt been chcking that value | 15:34.09 |
| Robin_Watts | My T value points 1 byte further on. | 15:34.40 |
| kens | Yeah I think I'd just figured that one out | 15:34.53 |
| Robin_Watts | Yours is right according to the spec, but doesn't match Acrobat. | 15:34.55 |
| kens | I *think* the spec says its supposed to point at the white space preceding the first entry | 15:35.08 |
| | Let me try with that changed | 15:35.21 |
| | No Acrobat still doesn't like it | 15:35.53 |
| | Looks like Acrobat is happy with the /T value either way | 15:38.10 |
| | In fact corrupting it makes no difference either | 15:38.33 |
| | I just changed the values in every entry in the Linearisation dict, and Acrobat didn't bat an eyelid | 15:39.09 |
| | SO we can obviously ignore all of those | 15:39.17 |
| | Also annoyingly, the non-linearised version of this file opens fine in Acrobat. So its 'something' I'm doing in teh linearisation process, but its not the hint stream or the linearisation dictionary (because we can see Acrobat ignores those) | 15:44.46 |
| Robin_Watts | The linearised file doesn't load in acrobat ? | 15:45.05 |
| kens | It loads | 15:45.10 |
| | Acrobat flahses a tiny little dialog | 15:45.18 |
| Robin_Watts | Ah. | 15:45.23 |
| kens | and when I close the dfile it offers to 'save the changes' | 15:45.28 |
| Robin_Watts | Well, then it will never say "Optimised for web viewing" | 15:45.35 |
| | Sorry, I was looking that, rather than anything else. | 15:45.52 |
| kens | No, art the moment I'm more concerned by the fact that it wants to rewrite teh file | 15:45.54 |
| | I'm assuming thre is something in the file structure Acrobat doesn't like | 15:46.20 |
| Robin_Watts | mudraw doesn't blink at it. | 15:46.30 |
| kens | Since I couldn't see anything else, I was assuming it was the hint table (previously I wasn't writing one properly) | 15:46.47 |
| | But it obviously isn't that | 15:47.00 |
| | SO I'm at a loss | 15:47.07 |
| | Note that Acrobat 7 opens it without complaint also.... | 15:47.20 |
| Robin_Watts | Is /Prev is wrong in the top trailer ? | 15:48.37 |
| | s/is// | 15:48.43 |
| kens | I checked it, but it could be | 15:48.47 |
| | Let me check again | 15:48.57 |
| Robin_Watts | no, sorry, my bad. | 15:49.33 |
| kens | No problem, worth checking | 15:49.45 |
| | Seems OK to me | 15:49.49 |
| Robin_Watts | If I load the file and save it back out of emacs, it changes. Gah. I hate editors. | 15:50.39 |
| kens | Me too. THe VS editor keeps opening files in text mode, even though I've selected the binary editor.... | 15:51.05 |
| ray_laptop | who came up with the 'mubusy' name for an app ? | 15:55.02 |
| Robin_Watts | ray_laptop: Me. | 15:55.17 |
| mvrhel | what app is that? | 15:55.29 |
| Robin_Watts | It's all the 'mu' apps in one. It's a 'busybox' build as it were. | 15:55.32 |
| ray_laptop | sorry, Robin_Watts, but I think it is really lame | 15:55.35 |
| mvrhel | that might need a bit of work... | 15:56.18 |
| ray_laptop | mutools or mutoolbox or something would have been more well understood | 15:56.22 |
| Robin_Watts | It was a request from a user. When we transitioned to using it as the main thing then it should probably have been renamed mutool, yes. | 15:56.37 |
| ray_laptop | or mupdf-tools but 'busy' ??? | 15:56.42 |
| Robin_Watts | It made perfect sense when it was the special 'busybox' build. | 15:57.02 |
| | but as the one and only tool, it should have been renamed. | 15:57.26 |
| ray_laptop | since it hasn't been around for long, can we change it going forward. | 15:57.36 |
| Robin_Watts | ray_laptop: I would have no objection to such a renaming. | 15:58.06 |
| | The trick is to link muclean (or pdfclean) to mubusy etc, then you can just call that. | 15:58.52 |
| ray_laptop | Robin_Watts: I hope you don't take offense. I didn't even know what it was until I noticed the discussion with kens in the logs today | 15:59.08 |
| | Robin_Watts: ln (or ln -s) is OK on linux | 15:59.29 |
| Robin_Watts | indeed. That's the point of busybox builds. | 16:00.07 |
| kens | Well, tried changing the EOL on the xref entries form \r\n to " \n", no dfifference | 16:00.25 |
| ray_laptop | Robin_Watts: busybox is not something I have ever encountered | 16:05.47 |
| kens | Robin_Watts : changed to ensure consistent line endings thoughout the file, no change. Blanled the linearisation dict, no change, so it *must* be a structural problem with the PDF. | 16:07.08 |
| Robin_Watts | If you're building tools and you want to make them fit into a very small space, you often find that the c library functions (or the common functions between exes) are a significant part of the size of the total size of the binaries on disc. | 16:07.42 |
| | So you roll all the files together, and get the tools to start up through a main that checks argv[0] for what name it was invoked under. | 16:08.16 |
| | If it was 'ls' then you call the ls routines, if it was 'cat' then you call the cat routines, etc. | 16:08.34 |
| | People used to use it to get very small unix distros etc. | 16:09.09 |
| | It's a technique still used in embedded systems. | 16:09.19 |
| | Were it not for the size of the CMAPs/Fonts etc, we could get mupdf and all its tools on a floppy :) | 16:09.43 |
| ray_laptop | Robin_Watts: well in case what is mubusy ever grows into more than a single tool, mutools is probably better than mutool. Plus 'tool' has an an unfortunate usage in US slang as in 'you are such a TOOL' | 16:09.44 |
| Robin_Watts | I'm happy with whatever - tor8 is the guy you need to convince. | 16:10.18 |
| | mubusy contains pdfclean, pdfinfo, pdfshow, pdfextract etc. | 16:10.54 |
| ray_laptop | mutools or mupdftools are my votes (unless someone else has an inspiration). | 16:11.32 |
| | Robin_Watts: so, on windows if you want to have pdfclean, pdfinfo, pdfshow, pefextract you need 4 copies of the .exe :-( | 16:12.15 |
| Robin_Watts | ray_laptop: Yes. Or you call: mubusy clean .... | 16:12.40 |
| | we check argv[1] too :) | 16:12.47 |
| chrisl | Surely the time for this discussion was like 8 months and two releases ago? | 16:12.51 |
| Robin_Watts | I was quite happy having them all as separate exes and just having mubusy for the specialist people that wanted it. | 16:14.09 |
| ray_laptop | chrisl: since I was using pdfclean and pdfinfo (old but useful versions) I didn't notice it surface, sorry. | 16:15.27 |
| chrisl | ray_laptop: it was discussed at some length before the change was made..... | 16:16.16 |
| ray_laptop | and if we are stuck with it, fine, but if you want to get an outside opinion, ask Scott or Miles which they prefer 'mubusy' or 'mupdftools' | 16:16.24 |
| | chrisl: really -- I'll check the IRC logs and see what I said back then. | 16:16.59 |
| chrisl | It can't be "mupdftools" be cause it handles other formats, too, "mutool" isn't too great, either | 16:17.42 |
| ray_laptop | frankly, even 'mu' is problematic enough for Scott to try to explain what it means | 16:18.02 |
| chrisl | Well, lack of education isn't really our fault ;-) | 16:18.24 |
| ray_laptop | mutool I agree (see above) mutools | 16:18.27 |
| chrisl | FWIW, I don't really see the problem of the separate executables, but since my involvement is so limited, I didn't feel like pushing my opinion | 16:19.34 |
| ray_laptop | mutoolbox is another, if you want to keep the association with 'busybox' Frankly, 'busybox' is a lame name, too. | 16:19.34 |
| chrisl | busybox is *extremely* well known in the embedded Linux world | 16:20.08 |
| Robin_Watts | busybox is a particular linux implementation targetted at embedded devices. | 16:20.08 |
| ray_laptop | chrisl: I MUCH prefer separate executables as well. You need them on windows anyway | 16:20.15 |
| Robin_Watts | ray_laptop: No, you don't. | 16:20.33 |
| kens | We don't need separate executables | 16:20.36 |
| | just one and give it teh rigth first argument | 16:20.52 |
| ray_laptop | Robin_Watts: I looked at the explanation on Wikipedia of busybox. | 16:21.24 |
| chrisl | Don't recent WinFS versions have something like a "real" symlink? | 16:21.40 |
| Robin_Watts | "junction", but only for directories. | 16:22.37 |
| chrisl | Oh, well, it could done with shortcuts, then | 16:23.04 |
| kens | COUld use batch files if it bothers people ebough <shudder> | 16:23.57 |
| chrisl | I would have thought shortcuts would be slightly less horrid | 16:24.30 |
| kens | Yeah but those are .lnk files aren't they? Are they directly executable from teh command line ? | 16:25.04 |
| chrisl | The "Target" field can be a complete command line, with options for the exe | 16:25.42 |
| ray_laptop | kens: AFAIK the command line doesn't work with .lnk shortcuts. .bat is needed | 16:25.53 |
| kens | Yes, but can you type 'mupdfclean.lnk' at teh command line ? | 16:26.01 |
| chrisl | Hm, I guess not - that's pretty darned poor :-( | 16:26.30 |
| kens | That' was what worried me | 16:26.38 |
| | Given that we more or less have to call 'whatever it is' from teh command line | 16:26.55 |
| chrisl | channels marcosw...... | 16:27.18 |
| | I know let's drop windows support :-) | 16:27.27 |
| kens | I have to go, I'll pound my head against Acrobat some more tomorrow | 16:29.59 |
| chrisl | Okay, so I now have GS building without needing the jbig2dec configure script - I just need to recheck Linux/PPC, MacOSX/PPC, MacOSX/x86 and MacOSX/x64..... | 16:32.17 |
| Robin_Watts | chrisl: I can't help feeling you're doing this all wrong. | 16:33.10 |
| | Surely the right time for this is the last week in january? :) | 16:33.21 |
| chrisl | No, that's far too early - the day after the release candidate would be best, I reckon...... | 16:34.05 |
| Robin_Watts | mvrhel: Have you been following the mails between Marti and myself? | 16:34.55 |
| mvrhel | Robin_Watts: I sent a reply to you and Marti this morning | 16:35.10 |
| Robin_Watts | Sorry, so you did. | 16:35.33 |
| | Right. | 16:35.57 |
| | I suspect Marti will argue that by keeping the ability to changeBuffersFormat, we reduce the opportunities for lcms2 to do pipeline optimisation. | 16:36.31 |
| | I don't have a clear enough view of the whole system to know whether pipeline optimisation can ever gain us anything, and if it can, whether it pays off the cost of having more links around. | 16:37.08 |
| mvrhel | Robin_Watts: yes. that is a trade off that is not exactly clear to me either | 16:39.04 |
| Robin_Watts | Ok. I suddenly don't feel so thick :) | 16:39.24 |
| henrys | alexcher:I assume you saw the luratech response will you still be able to fix the bug. If not we'll get support. | 16:39.47 |
| mvrhel | ray_laptop: were you able to get stuff set up with what I sent you regarding the clist. I have been poking at it a bit more this morning | 16:42.33 |
| | In the last potentially successful copy planes command the last plane is compressed | 16:43.36 |
| ray_laptop | marcosw: I closed bug 693310 as a duplicate of 689805, but I don't understand how -dMaxBitmap would make any difference with the 'display' device | 16:49.51 |
| marcosw | me neither. did you try it? | 16:50.21 |
| ray_laptop | mvrhel: no, I am still trying to resolve the memory leak I have with transparency for cust 532 | 16:50.40 |
| mvrhel | ray_laptop: ok. I am stepping now through the reader | 16:51.02 |
| | I can see all the data and the next command in the buffer | 16:51.15 |
| ray_laptop | marcosw: Oh, the comment 1 is the customer's words, not yours ??? | 16:51.24 |
| mvrhel | stepping through now to see how it is consumed | 16:51.26 |
| marcosw | the -dMaxBitmap=30000000 mention in comment #1 is mine, the rest is from the customer. | 16:52.17 |
| mvrhel | ray_laptop: ok I see that the third plane had the wrong number of bytes read | 16:54.33 |
| | compared to what was writtten | 16:54.42 |
| | one byte off | 16:54.55 |
| ray_laptop | marcosw: how can -dMaxBitmap=30000000 do ANYTHING to the 'display' device ??? | 16:57.50 |
| marcosw | I don't know. Did you try it? | 16:58.05 |
| ray_laptop | marcosw: no. did you ? | 16:58.20 |
| marcosw | yes. | 16:58.26 |
| ray_laptop | marcosw: on windows ? | 16:58.40 |
| marcosw | yes. windows 7 home premium. | 16:58.50 |
| ray_laptop | marcosw: OK. I'll download the file and try it, but ... | 16:59.23 |
| marcosw | I'll attach a screen shot to the bug report. | 16:59.35 |
| ray_laptop | marcosw: either way I get "Error: /VMerror in --.begintransparencygroup--" | 17:01.44 |
| | marcosw: which is what I expect. I used: gswin32c -r300 -sDEVICE=display -dMaxBitmap=30000000 -sPAPERSIZE=letter c:/temp/Bug693310.pdf | 17:02.19 |
| | the VMerror is EXACTLY what I expect. | 17:02.51 |
| | marcosw: I am able to run with up to -r293 and that peaks out at about 1.8Gb RAM (from task manager) | 17:05.47 |
| marcosw | right. now I'm getting the expected results as well. I wonder why it worked earlier⦠| 17:06.11 |
| ray_laptop | marcosw: thanks for making sure I'm not crazy. Maybe you didn't have the -r300 or something | 17:07.10 |
| Robin_Watts | So we need a clist display device? | 17:08.35 |
| ray_laptop | Robin_Watts: yes, also for x11, ps2write and pdfwrite (when going to PDF < 1.4) and other 'vector' devices. | 17:10.05 |
| | that's what bug 689805 mentions. | 17:10.24 |
| | I have the concept mapped out, but have only started on a branch to do that. | 17:10.52 |
| | Robin_Watts: I want to wrap up cust 532 and the pdf14 clist optimization first (since cust 532 is moving to 9.06 and it doesn't have the pdf14 clist optimization that I did for them) | 17:11.49 |
| Robin_Watts | ray_laptop: cool. | 17:12.14 |
| ray_laptop | Robin_Watts: it will mean that the display device won't be able to update until the page is finished, but that happens anyway when the PDF has transparency. | 17:13.10 |
| alexcher | henrys: Yes, I've seen Luratech response. I'm working on the problem. | 17:17.31 |
| sags | @chrisl (for the logs) "Don't recent WinFS versions have something like a "real" symlink?" : Yes, on NTFS filesystems. Vista has mklink to create symbolic links. Much older are NTFS hardlinks "fsutil hardlink create new_filename existing_filename" ("new" and "existing" must be on the same volume). | 18:55.16 |
| ray_laptop | quit | 19:06.12 |
| rayjj | Robin_Watts: I looked in the logs and saw: [2012-05-10 04:27:58] <tor8> and I guess rename mubusy to mupdftool? | 21:42.16 |
| | and it looks like this is the first time we shipped the apps as mubusy (according to the logs). I still would like to consider mupdftools (or mutools if you want to not exclude xps) | 21:43.32 |
| | also, btw, the mupdf.com "manual" and "doc" links don't mention mubusy (so let's not start now) ;-) | 21:45.11 |
| | Forward 1 day (to 2012/08/31)>>> | |
IRC Logs