| | <<<Back 1 day (to 2018/04/29) | 20180430 |
| moolc | tor8: heh.. nice timing.. just finished writing an e-mail to the author of that LWN terminals article | 07:15.37 |
| tor8 | moolc: I wonder how much of the difference between xterm/mlterm and the others like st is down to using old X fonts vs Xft | 07:16.25 |
| moolc | A LOT | 07:18.14 |
| | i can tell you from experience running them on my old macminippc few years back | 07:18.35 |
| tor8 | yeah. I know that Xft is dog slow. I just wonder how much of the latency can be blamed on it... | 07:19.00 |
| moolc | tor8: not only is it slow, it's also quite buggy.. printing color emoji stuff in a terminal can (and does) lead to segfaults (with xterm, st but not rxvt-unicode) here | 07:20.10 |
| | tor8: mupdf's freetype is compiled without support for .dfont right? | 07:28.00 |
| tor8 | #undef FT_CONFIG_OPTION_MAC_FONTS in scripts/freetype/slimftoptions.h yes | 07:36.21 |
| moolc | cool, thanks | 07:41.16 |
| avih | tor8: not very pretty (even if the original is slick..) but works https://pastebin.mozilla.org/9084276 . Can this be a [base for a] PR? | 09:57.21 |
| | (quick sort for mujs) | 09:57.43 |
| sebras | tor8: "Add some comments.", "Support multipage pnm images.", "Handle multi-page image formats in muimg document driver.", "Add pdf_dict_get_int, etc." and "Use pdf_dict_get_int, etc." LGTM | 13:39.19 |
| | tor8: "Improve error handling in murun shell and update MuJS submodule." looks reasonable to me. I believe that the new stacktrace_js code will be called when someone calls Error.toString() | 13:42.38 |
| tor8 | sebras: yes, the new stacktrace_js replaces the default Error.toString method | 13:43.24 |
| sebras | ok. | 13:43.39 |
| | and in eval_print() I take it that the calls previously didn't handle errors gracefully. | 13:44.36 |
| tor8 | correct. there were cases where js_tostring would throw taht we didn't handle well. | 13:45.06 |
| sebras | tor8: in "Remove old and stale 'webos' and 'pnacl' cross-compile configurations." I'm a bit curious how you determined what targets are stale..? i.e. how do you know that the beaglebone and tizen crosscompiles work? | 13:45.23 |
| | guessing? | 13:45.45 |
| tor8 | such as trying to do toString on an object with no .toString method (like ones created with Object.create(null)) | 13:45.53 |
| | or ones where the toString method throws an exception itself | 13:46.17 |
| | sebras: that's the commit I'm more unsure about | 13:46.28 |
| | pnacl was pronounced dead a couple of years ago | 13:46.49 |
| | I haven't heard anything about webos in the past 7 years since the 'webos' section was added | 13:47.08 |
| sebras | right, I'm not surprised you remove them, I'm surprised you _keep_ a few! :) | 13:47.20 |
| tor8 | tizen and beagleboard are robin's pet projects, so I figured he could pipe up about those | 13:47.22 |
| sebras | oh! | 13:47.30 |
| | tor8: I'm not sure I like the mutool show grep output change. | 13:48.19 |
| | tor8: I have frequently run mutool show grep on multiple files, e.g. all the cluster files | 13:48.37 |
| | looking for a particular type of object, e.g. JBIG2Decode | 13:49.08 |
| | when doing so the filename has actually been helpful to me. | 13:49.22 |
| | in particular that the entire object as well as object number and filename all reside on a single row. | 13:49.38 |
| tor8 | sebras: but when you do, you always call it in a for loop right? | 13:49.43 |
| | mutool show $file grep | sed "s/^/$file:/" could work | 13:50.19 |
| sebras | tor8: I don't quite remember, but, yeah, probably. | 13:50.19 |
| tor8 | mutool show doesn't take more than one file as input | 13:50.36 |
| | https://bugs.ghostscript.com/show_bug.cgi?id=699295 | 13:51.01 |
| sebras | the only benefit I see now is that ths stream is printed, but why is that important? | 13:51.10 |
| sebras | reads bugzilla. | 13:51.18 |
| tor8 | I've found myself wanting to know if an object is a stream or not in the grepable output | 13:51.35 |
| sebras | tor8: in that case I'd suggest adding another colon with a set of comma-separated strings between them. "stream" currently being the only one. | 13:53.18 |
| tor8 | this 'new' format is similar to the actual pdf object syntax | 13:53.56 |
| | 10 0 obj <</Foo/Bar/Length 10>> stream | 13:54.08 |
| sebras | yes, I know. | 13:54.26 |
| | and I'm not sure I like it. :) | 13:54.30 |
| tor8 | I don't really like the idea of inventing new unreliable syntaxes (and : is not a reliable separator) | 13:54.58 |
| sebras | I tend to use cut -d: -fnumber to split things out and now that would require sed for the same thing. | 13:55.02 |
| | not reliable because it might show up in filenames? | 13:55.27 |
| tor8 | and in PDF strings and names | 13:55.44 |
| sebras | yes, but those are less of a problem since the number of fields in a row is known. | 13:56.09 |
| tor8 | can you give me a concrete example of what you want to do that is now more difficult? | 13:57.14 |
| sebras | so what you want is a flag to the normal mutool show to say "tight" and put it all on a single line? | 13:57.20 |
| tor8 | and how do you mean add another field with : and comma separated list of 'stream' and nothing else? | 13:57.34 |
| | sebras: that's what 'mutool show $file grep' is intended to do in the first place (and not print the stream contents) | 13:58.07 |
| | sebras: maybe a 'mutool grep $file $pattern' would be better? | 13:58.28 |
| sebras | what I means was something like: boids3.pdf:80:stream,otherflag,whatever: <</Filter/FlateDecode/Length 14637>> | 13:58.36 |
| | tor8: sometimes, but not necessarily. Sometimes I don't know what I'm looking for yet. | 13:59.04 |
| tor8 | mutool show with a smarter object selection syntax would be handy sometimes | 13:59.46 |
| sebras | tor8: e.g. I have already run mutool show grep on the cluster files and put the output into a (gigantic) file, ready for me to grep whenever I need to. | 13:59.47 |
| | that I agree with, but I'm less sure about exactly what I would need. | 14:00.06 |
| tor8 | mutool show $file page[5].Resources.Fonts etc | 14:00.11 |
| sebras | quite often I'm looking for names being present in the top-level dictionary though. | 14:00.38 |
| tor8 | or mutool show $file trailer.Info.Author | 14:00.41 |
| | mutool show $file trailer.Root.AcroForm | 14:01.03 |
| sebras | but when I was looking for JBIG2Decode-able streams I didn't care if they were used in a page or not, and whether they were image masks or normal images. just the fact that they were JBIG2 bitstreams. | 14:01.43 |
| | next I filtered out the ones that had JBIG2Globals, because they had a separate symbol dictionary. | 14:02.08 |
| | tor8: maybe reuse pdf_dict_getp() syntax? i.e mutool show trailer/Info/Author ? | 14:03.31 |
| | tor8: mutool show $file trailer/Info/Author | 14:03.54 |
| | but then we'd still have mutool show $file 42 123 for showing object numbers | 14:04.32 |
| | and mutool show $file grep for what this commit is changing. | 14:04.46 |
| tor8 | sebras: https://ghostscript.com/~tor/show.js something like that maybe | 14:23.45 |
| sebras | with this mutool show $file pages[5].Resources.Fonts would be hard, right? I fail to see how pages[5] resolves, but I might be missing something. | 14:31.00 |
| tor8 | pages.5.Resources.Font | 14:31.11 |
| sebras | ah, yes, the obj[sel]! | 14:31.29 |
| | this looks like it would work. | 14:31.45 |
| | tor8: this also makes me think that we don't really need out C-based mutools anymore... ;) | 14:36.22 |
| tor8 | sebras: most of them could be replaced, yes | 15:11.19 |
| | okay, new fancy 'mutool show' on tor/master | 15:24.05 |
| sebras | tor8: add outline to the help..? | 15:34.09 |
| | tor8: it was there before, and it can be chosen. | 15:34.17 |
| avih | tor8: is this more reasonable? this one i implemented myself not based on that tight c code (but following hoare's approach from wikipedia) https://pastebin.mozilla.org/9084303 | 15:35.39 |
| sebras | tor8: why not fz_atoi() in showselector()? | 15:38.56 |
| avih | it's slightly less sophisticated (pushing low+hight to the stack for each iteration rather than just one value and doing the other "inline"), but i think it's more readable and perf penalty is negligible (~2%) | 15:44.15 |
| sebras | tor8: after having looked through it, I like it. :) | 15:44.46 |
| | this will help us not having to care about object numbers as much! | 15:45.15 |
| | tor8: however mutool show doc.pdf trailer.Root.1.2 leaks the pdf_new_indirect() created at showselector 264. | 15:51.27 |
| | tor8: I need to pay attention to capitalization, but it works great! :) | 15:54.35 |
| tor8 | sebras: yeah, it needs cleaning up. | 15:54.53 |
| | avih: I'll take a look later this week, a bit busy right now. | 15:55.06 |
| avih | tor8: np, just make a copy please. iirc it might disappear after a day despite setting longer expiry | 15:55.53 |
| | Forward 1 day (to 2018/05/01)>>> | |
Log of #mupdf at irc.freenode.net.