| | <<<Back 1 day (to 2014/12/16) | 20141217 |
| OliverUv | Hello! Is it possible to see which page of a pdf I'm on in mupdf? | 02:12.26 |
| avih | does mupdf have its own font rendering module? does it support subpixel AA ? | 07:14.43 |
| | (thinking of sumatra) | 07:14.50 |
| | (which on my win 8.1 system doesn't have subpixel AA) | 07:15.17 |
| kens | avih as fart as I'm aware MuPDF uses FreeType for font rendering, as does Ghostscript. | 08:02.39 |
| | s/far/fart/ :-) | 08:02.52 |
| avih | heh thx | 08:03.05 |
| tor8 | avih: if by "subpixel" AA you mean cleartype, then no, we don't support it by design. | 09:43.35 |
| avih | tor8: well, cleartype and *nix AA | 09:43.59 |
| | and osx AA etc | 09:44.06 |
| kens | Oh coloured fringes :-( | 09:44.21 |
| tor8 | we do better AA than most font rendering, by actually rendering the characters at subpixel-accurate (i.e. not rounded to integer) coordinates | 09:44.34 |
| | so we don't get the odd awkward spacing that web browsers, adobe and evince have | 09:45.17 |
| avih | kens: fact is, windows, osx and some popular linux distros use subpixel AA by default, so i'd think subjectively most users prefer it over greyscale AA | 09:45.19 |
| kens | avih I spent a lot of time carefully tweaking the ClearType values, then turned it off. | 09:45.52 |
| tor8 | avih: most users wouldn't know what AA is if it slapped them in the face ;) | 09:45.55 |
| kens | I very much dislike the coloured fringe effect. | 09:46.02 |
| avih | tor8: subpixel rendering and subpixel AA are tangential | 09:46.05 |
| | AFAIK for instance OS X does both | 09:46.26 |
| tor8 | avih: orthogonal, I think you mean :) | 09:46.34 |
| | OSX does both, in some places. not Safari though. | 09:46.49 |
| avih | tor8: same :) | 09:46.50 |
| tor8 | which is a huge disappointment... that they didn't bother to fix the integer text coordinate assumptions in KHTML when they forked it into webkit | 09:47.34 |
| avih | anyway, IMO the evidence suggests that subpixel AA is subjectively preferred or else major OS will not have it by default, as it's definitely extra work | 09:47.47 |
| tor8 | anyway, like Ken, I also can't stand the color fringing | 09:47.55 |
| chrisl | A *large* number of users we talk to use MuPDF specifically *because* of the text rendering, which they almost universally seem to feel is better than other applications. Which suggests a lot of users do *not* prefer sub-pixel AA...... | 09:48.12 |
| tor8 | we always say, if you're really desperate for it, you can render at 3x the width and do the color filter downsampling on the full page | 09:48.28 |
| kens | avih yes, the vendors think its a great idea, most people have no idea its there, and just get by with what they have, whether they like it or not. Few users would even be aware it can be altered. | 09:48.40 |
| avih | chrisl: i haven't seen studies, but at the very least the fact that OS X uses it by default would suggest to me that users will prefer it. of course, subpixel rendering is still very good, and sometimes better tha the heavily kerned windows fonts rendering | 09:49.21 |
| tor8 | avih: most people compare windows old pre-cleartype rendering (which is absolutely atrocious) with microsofts cleartype (which is slightly better, if you can live with the color fringes) | 09:49.46 |
| chrisl | avih: that kind of faith in Apple is what keeps making them loads of money ;-) | 09:49.48 |
| kens | avih I don't htink that the fact that OS's ship it says much about whether pepole prefer it. | 09:49.49 |
| | Like I said, most people just use what they get, they don't even realise they can change it. | 09:50.21 |
| tor8 | and linux has sadly tried to emulate windows font technology rather than apple's (with strong font hinting) | 09:50.28 |
| kens | Personally I loathe it | 09:50.35 |
| avih | chrisl: i'm very far from an apple fanboy or even fan, but i can appreciate their work still :) | 09:50.41 |
| tor8 | ...mostly because with strong hinting, the lack of floating point positioning and rendering is not as bad | 09:51.00 |
| kens | avbih I'm pretty sure that was MS work there on ClearType..... | 09:51.09 |
| tor8 | ...which means the old bitmap font APIs don't have to change | 09:51.10 |
| chrisl | avih: as I said, I'm only going by the feedback we get from mupdf users...... | 09:51.10 |
| avih | well, perfonally i find good subpixel AA superior to grayscale AA. though that's subjective | 09:51.13 |
| | chrisl: yeah, i don't disagree with that approach. | 09:51.39 |
| tor8 | moving to using floating point precision for text rendering necessitates API changes, which the people designing Qt and Gtk+ weren't aware of and now it's too late :( | 09:52.03 |
| | windows has made the right switch, with DirectWrite | 09:52.24 |
| avih | yeah, that's unfortunate | 09:52.29 |
| | yes, it now has vertical AA | 09:52.40 |
| chrisl | avih: besides, the other big problem is that to implement it properly would mean breaking mupdf core's platform independent | 09:52.49 |
| kens | Crikey, where does the morning go.... I have to go, back in a few hours. | 09:53.02 |
| tor8 | and kerning! and proper font spacing. lots of people dislike DirectWrite, because it looks different than they're used to | 09:53.05 |
| | avih: there are also patents involved in cleartype | 09:53.25 |
| avih | chrisl: i bet :/ | 09:53.44 |
| tor8 | which is why linux has a worse color filter algorithm which makes the fringing even worse than on windows, last I looked | 09:53.49 |
| avih | tor8: ^ sorrt | 09:53.50 |
| | y | 09:53.52 |
| | dunno, recent ubuntu gets font rendering very good imo. | 09:54.20 |
| tor8 | cleartype also doesn't work too well with non-black text on a non-white background | 09:54.34 |
| avih | which is definitely not something you could say of ubuntu few years ago, or even many distros today | 09:54.45 |
| tor8 | red text would fail spectacularly | 09:54.46 |
| avih | does it?? | 09:55.11 |
| | sec | 09:55.21 |
| tor8 | using red colored text with cleartype would mean you can't use the blue spectrum for the color fringes, and thus lose the cleartype benefits | 09:55.59 |
| avih | tor8: would you expect cleartype to also fail with orange? | 09:56.09 |
| tor8 | avih: any saturated colors, really | 09:56.23 |
| | avih: another problem is that since we do completely unhinted rendering (by design) in mupdf, the color fringing would be worse off | 09:57.49 |
| | with hinted text, most of the stems align with the pixel grid, so the color fringes mostly only appear on diagonals and curves | 09:58.05 |
| avih | http://oi58.tinypic.com/eq8t94.jpg | 09:59.31 |
| | this suggests to me that other than subpixel AA, there's also subpixel rendering (though probably with hinting) | 10:00.15 |
| tor8 | avih: yeah, as you can see the left edges which are supposed to be blue are really faded out | 10:00.25 |
| avih | it looks very good to me from a normal reading distance. | 10:00.48 |
| tor8 | that is not subpixel rendering, the e's look identical and they're also strongly hinted | 10:00.51 |
| avih | though again, that's subjective. i do know the differences between properly kerned, hinted, and subpixel aa/rendering :) | 10:01.14 |
| | re sp rendering, i was judging by the vertical parts of the curly braces | 10:01.39 |
| | though i agree it's not a good enough proof. i'll need to see the same glyph rendered differently to say that | 10:02.15 |
| tor8 | avih: the problem is, it's impossible to talk about rendering fonts with subpixel positioning because everybody associates "subpixel" with cleartype | 10:03.26 |
| avih | obviously not everybody :) | 10:03.51 |
| tor8 | avih: enter "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" in TextEdit on your mac | 10:04.13 |
| avih | tor8: i did | 10:05.35 |
| tor8 | do the i's look different? | 10:05.58 |
| avih | not to me | 10:06.06 |
| tor8 | if you magnify? | 10:06.13 |
| avih | i am magnifying | 10:06.19 |
| tor8 | it might be that the default font has turned off the accurate positioning | 10:06.26 |
| | or just the newer versions of osx, since they've been adding more font hinting every macosx release | 10:06.49 |
| | back in the early (< 10.4) releases, they didn't use font hinting at all | 10:07.08 |
| | then they started adding font hinting for a subset of fonts (the microsoft web fonts, verdana, etc) | 10:07.28 |
| avih | in fact every two instances of the same letter look the same to me, while magnifying, with the default font in textedit | 10:07.42 |
| tor8 | then they started adding vertical font hinting (like the new freetype subtle autohinting) | 10:07.45 |
| | what is the default font? | 10:08.07 |
| avih | don't know. sec | 10:08.18 |
| | menlo regular | 10:08.49 |
| | 11.0 | 10:08.53 |
| tor8 | try helvetica | 10:09.25 |
| | menlo is a monospaced font | 10:09.30 |
| avih | funny how even textedit offers font rendering options... e.g. under kern it has: default, none, tighten, loosen | 10:09.47 |
| | so helvetica has vertical aa | 10:11.09 |
| tor8 | bah, internet hickup | 10:11.46 |
| avih | i'm looking at the same letter at different places at the same line, and at different lines, and the rendering looks identical to my eyes, while magnifying | 10:12.29 |
| tor8 | then apple's messed up the only good remaining part of osx... even less reason for me to go back :) | 10:13.12 |
| chrisl | You need to take a screenshot and magnify the screenshot | 10:13.14 |
| avih | i'm magnifying the screen, isn't this the same? the pixels themselves are magnified, including aa | 10:15.25 |
| | i.e. it doesn't render the text at a different scale, it just does screen scaling with nearest neighbor | 10:15.57 |
| chrisl | I dunno, I've just had so many people "zoom in" in Acrobat, I find it best to recommend a screenshot..... | 10:16.44 |
| | But if subpixel AA is in force, the characters should not look exactly the same across the screen | 10:17.35 |
| avih | when i zoom it looks like the screenshot i posted some minutes ago, just on os x (with the accessibility zoom and without "smooth image") | 10:18.23 |
| | chrisl: true. is that a problem? | 10:18.58 |
| chrisl | Sorry I stepped away from the conversation for a bit: I thought you were advocating subpixel AA...... | 10:19.32 |
| avih | screen rendering could have specialized rendering to screen which is different than for print | 10:19.34 |
| | anyway, this is not a discussion of what is better :) | 10:19.57 |
| | this is a very subjective matter :) | 10:20.05 |
| | chrisl: i like subpixel aa, but i understand that some dont. not advocating. | 10:20.36 |
| chrisl | But what you are reporting suggests you are not using subpixel AA on OSX | 10:20.57 |
| tor8 | there's that terminology confusion again... | 10:21.14 |
| avih | chrisl: it uses subpixel aa, but apparently not subpixel rendering (=alignment) | 10:22.20 |
| tor8 | avih: better to say cleartype and subpixel positioning | 10:22.51 |
| avih | cleartype is windows TM thingy | 10:23.07 |
| | and just one implementation | 10:23.20 |
| tor8 | avih: yeah, but it's clear what you mean (pardon the pun) | 10:23.20 |
| chrisl | Ah, okay, I guess I missed that. TBH, as I dislike AA text, I tend not to pay as much attention as I should..... | 10:23.27 |
| avih | :) | 10:23.28 |
| tor8 | as much as I like nicely AA text, I do use non-AA bitmap fonts for my text editor... | 10:23.56 |
| avih | tor8: you hear that? you should move to black and white fonts :) | 10:24.03 |
| | ah, you did lol | 10:24.20 |
| tor8 | avih: http://ghostscript.com/~tor/stuff/fonts/codec/ | 10:24.37 |
| avih | i also prefer aa on text editors and terminals :) | 10:24.41 |
| tor8 | nothing I've used beats that font for clarity | 10:25.00 |
| avih | what about that link? | 10:25.10 |
| tor8 | the bitmap font I use | 10:25.18 |
| | in various formats. so I don't ever lose it. | 10:25.30 |
| avih | oh | 10:25.37 |
| | that's how my zoomed editor looks http://oi60.tinypic.com/24gly5v.jpg | 10:30.11 |
| | though it's on a BGR pixel order | 10:30.22 |
| tor8 | yuck. syntax coloring ;) | 10:30.52 |
| chrisl | See, that sort of setup give me a headache..... | 10:30.55 |
| tor8 | and light text on a dark background, that tires my poor astigmatic vision way too quickly | 10:31.10 |
| chrisl | But that's why it's all just so personal..... | 10:31.38 |
| tor8 | I need a bright window to flood my vision with photons so my pupils contract and increases the depth of field | 10:31.40 |
| avih | i was with dark text on light background, and tried light text on black background, but eventually settled on light text on grey bg. | 10:32.10 |
| | this way the colors don't "shout" | 10:32.36 |
| | tor8: seriously? you don't use syntax coloring? :) | 10:33.15 |
| chrisl | The colour scheme isn't offensive to me, but the fuzzy edges on the text make my eyes think they're not focussed properly | 10:33.32 |
| tor8 | avih: can't stand it. too distracting with candyland colors everywhere. | 10:33.42 |
| avih | chrisl: your monitor probably has an RGB pixel order, and this was rendered for a BGR monitor | 10:33.59 |
| tor8 | if your code needs syntax coloring to look good, you're not trying hard enough... | 10:34.05 |
| | avih: zoomed in, the subpixel color order is irrelevant :) | 10:34.24 |
| avih | man, i almost break the kb when i type. you can't say that :) | 10:34.27 |
| chrisl | avih: I don't mean your screenshot specifically..... | 10:34.30 |
| avih | tor8: indeed re order | 10:34.44 |
| | anyway, i never claimed it's absolutely better, just that sibjectively i prefer it and the fact that OS vendors put effort and use it by default suggests that i'm not the only one. but it still remains a subjective thing :) | 10:35.46 |
| tor8 | avih: as you can see, there are too many of us here that don't like it :) | 10:36.33 |
| | and the people who do have learned to keep quiet once we get going... | 10:36.52 |
| avih | all so far :) | 10:36.53 |
| | heh | 10:37.05 |
| chrisl | OS vendors spend a lot money looking for ways to differentiate themselves - not always to the benefit of users..... | 10:37.12 |
| avih | dunno. i don't keep quiet, but i also never claimed my perspective is superior | 10:37.28 |
| | though in that case it might be ;) | 10:37.33 |
| | chrisl: fair point | 10:38.50 |
| chrisl | avih: plus, arguing with tor8 is *definitely* a quick way to insanity ;-) | 10:39.45 |
| avih | good thing i'm not arguing then :) | 10:40.10 |
| tor8 | avih: http://www.linusakesson.net/programming/syntaxhighlighting/syntax2.png this is one of my arguments against syntax coloring... | 10:40.18 |
| | I don't like syntax coloring for english, why would I like it for code? | 10:40.42 |
| | chrisl: heeey! | 10:41.09 |
| avih | tor8: why would you like a guava? some people fine it nice, others don't :) | 10:41.57 |
| tor8 | s/guava/guano/ and I might agree ;) | 10:42.15 |
| avih | :) | 10:42.27 |
| chrisl | Whereas, I like (subtle) syntax coloring..... | 10:42.48 |
| avih | tor8: ultimately though, i fully agree that if your customers prefer grey AA, then sibpixel AA is probably not something you should put effort into. | 10:44.15 |
| tor8 | avih: there is a way to get it; render at 3x the width and filter the full page | 10:44.42 |
| | adding cleartype-style font rendering to the mupdf renderer would mean a lot of invasive changes | 10:45.22 |
| | since we'll need to support 3-channel alpha | 10:45.30 |
| avih | i guess. never thought of SP AA algorithms. but that sounds plausible | 10:45.37 |
| | yeah | 10:45.49 |
| tor8 | since there are a *lot* of ways to render text in PDF | 10:46.08 |
| | text used as a clip mask, type 3 bitmap fonts, etc | 10:46.22 |
| | easier to just do it as a post process | 10:46.33 |
| | and that gets you the same benefits for line art and full page bitmap scans | 10:46.54 |
| avih | i don't disagree because i'm not familiar enough with the field to assess the technique TBH | 10:47.09 |
| | but like i said, it does sound plausible to me | 10:47.23 |
| Robin_Watts | I've coded a cleartype equivalent in the past. | 10:49.20 |
| | It worked nicely, it gave nicer (subjectively, to me) results than the others out there, but it's all blown to hell by modern screens which are more complex than simple RGB triplets. | 10:50.04 |
| avih | tor8: however, seeing how much cleartype can be fine tuned, i'm guessing that a "naive" approach like you suggest might not be the best looking one. but that's a guess. | 10:50.11 |
| Robin_Watts | So the only way to do it nicely these days is to render to a bitmap 3 times as wide and to filter down. | 10:50.40 |
| avih | Robin_Watts: yeah. not to mention pentiles :) | 10:51.27 |
| tor8 | I'm just waiting for a decent 24" 16:10 aspect ratio 4K monitor to come along... | 10:51.38 |
| Robin_Watts | pentiles were what I was thinking of. | 10:51.42 |
| tor8 | or better yet, 4:3 | 10:51.50 |
| avih | 19:10 is fine IMO | 10:52.03 |
| | 16:10* | 10:52.07 |
| Robin_Watts | avih: All the same tunings that can happen for clear type can happen for bitmap filtering, I believe. | 10:52.19 |
| tor8 | 16:9 (which is all that exists for 4K) is just too damn narrow | 10:52.23 |
| avih | is the new apple 5K 16:9? | 10:52.25 |
| | tor8: yeah, i don't disagree and also prefer 16:10 over 16:9, and have such monitor. but one gets used to anything. ultimately, that's not what really counts :) | 10:53.26 |
| | anyway, gtg now. thx for the chat. later :) | 10:54.02 |
| tor8 | avih: it's 16:9 (and too big at 27") | 10:54.02 |
| | avih: not to mention that it's got a mac attached... | 10:55.13 |
| avih | heh, true that | 10:55.22 |
| chrisl | tor8: those headphones I couldn't remember the name of the other week: http://www.psbspeakers.com/products/headphones/M4U-2-Headphones | 10:57.51 |
| tor8 | chrisl: oh, right. are these over-ear on on-ear? | 10:59.09 |
| chrisl | Over | 10:59.18 |
| tor8 | chrisl: now you made me curious... must... not... open... wallet... | 10:59.51 |
| chrisl | But as I said, they are not the largest/deepest cups, hence all the reviews saying to try them with that in mind | 10:59.58 |
| tor8 | yeah, they do look a bit like on-ear (hence my question) | 11:00.13 |
| | but now I remember you mentioning the shallowness of the cups | 11:00.26 |
| chrisl | tor8: I'll get a set before the next meeting in the US (if they fit, I'll bring them), and you can try them | 11:00.38 |
| tor8 | chrisl: I'd appreciate that :) | 11:02.10 |
| chrisl | If they are as good as is claimed, I'll be very happy | 11:03.04 |
| Robin_Watts | Remember, it's hifi. 50% hype, 30% utter bollocks and 20% lies. | 11:08.49 |
| chrisl | Robin_Watts: you are just describing "Sales and Marketing"....... | 11:10.05 |
| Robin_Watts | no, hifi takes it to the next level. | 11:25.59 |
| chrisl | I think television vendors are catching up fast! | 11:29.02 |
| Robin_Watts | My favourite thing about TV adverts is when they do TV adverts on telly, saying "look how great the picture is!" :) | 11:31.26 |
| chrisl | The first time I remember that was when the first 100Hz TV was released: "note the lack of flicker"...... | 11:37.27 |
| OliverUv | oh cool, activity, does anyone know of a way to make mupdf display the page i'm currently on? | 12:04.34 |
| chrisl | OliverUv: presumably you mean display the page number in the application? On what platform etc? | 12:20.50 |
| OliverUv | on linux | 12:21.00 |
| chrisl | Them I suspect the answer will be "you can't" but tor8 would be the one to answer for sure | 12:21.31 |
| | s/Them/Then | 12:21.38 |
| OliverUv | ok, thanks | 12:21.52 |
| tor8 | OliverUv: the page number is in the window title bar | 12:26.06 |
| OliverUv | oh! | 12:26.45 |
| | nice | 12:26.50 |
| tor8 | OliverUv: sebras has a patch to display page numbers on-page (since he uses a wm without title bars) but you'll have to ask him where he keeps it | 12:27.18 |
| OliverUv | i can get titlebars on my windows very easily, so it is not necessary | 12:28.28 |
| henrys | tor8: miles wants a table comparision with v8 tinyjs and another vs. mujs. I think reasonable rows for the table would be size, speed, supports ios, android, memory etc. | 12:28.33 |
| OliverUv | btw, this is the best pdf reader i've found so far - thanks! | 12:28.50 |
| henrys | tor8: we might be able to do a bounty for it. | 12:32.16 |
| | tor8:having a full blown article on wikipedia would help also but you shouldn't write that. | 12:35.18 |
| Guest16843 | hi | 12:36.00 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 12:36.00 |
| sebras | tor8: I though my 'P' patch was still on origin/master..? | 12:38.42 |
| | tor8: maybe you lost it again in some code reorgnization though. I haven't checked recently. | 12:39.06 |
| tor8 | sebras: OliverUv: oh yeah, shift-P | 12:39.15 |
| OliverUv | huh, can't believe I missed that | 12:40.06 |
| | i thought i even /page in the manpage for it | 12:40.23 |
| | what is "presentation mode" ? | 12:40.45 |
| | ah, pages will change | 12:41.03 |
| | badly | 12:41.07 |
| | :p | 12:41.09 |
| sebras | OliverUv: I'm not sure shift-P is mentioned on the manpage though. | 12:41.30 |
| OliverUv | it is on this computer, maybe I have an older version on my other computer (which does run an older dist) | 12:41.59 |
| | ah yeah ok, it depends on the version | 12:42.26 |
| tor8 | henrys: yeah, a wikipedia page is difficult to keep alive without plenty of secondary sources to point to | 12:43.39 |
| | the wikipedia deletionists are pretty hard core | 12:43.48 |
| | henrys: I'll take a look at compiling a table with data for various js implementations | 12:44.20 |
| henrys | tor8: but we would show the implementation being slower than say v8 I wonder if that would make it less advertisement like. | 12:45.36 |
| tor8 | henrys: can do "startup" speed ;) | 12:46.43 |
| | and showing we're not any slower than spidermonkey in bytecode mode | 12:47.06 |
| henrys | kens:if you want me to answer rons questions I will let me know. | 14:18.17 |
| kens | henrys yes please, I did just send a reply, but if you could point him to the PCL in question that would probably help | 14:18.37 |
| | And I cna get back to chasing the 3 cases that still don;'t work properly | 14:19.12 |
| henrys | kens: or I can walk down there and slap him, trying to decide. | 14:22.35 |
| kens | LOL are they near you then ? | 14:22.47 |
| henrys | 7 miles | 14:23.06 |
| kens | Wow, that is near | 14:23.17 |
| henrys | not annoyed because he doesn't understand it, but it would be wise to let us just focus on the issue... | 14:23.57 |
| kens | Indeed! I am working on it, I don't expect it to take long, but I'm not willing to promise anything | 14:24.27 |
| henrys | kens: well we can always just fall back to "if high level device print as usual", I looked at the test diffs and it's nothing pdfwrite is going to get completely correct because of the rop/transparency etc. | 14:26.15 |
| | i.e. it doesn't create new problems just changes them a bit. | 14:26.52 |
| kens | But... This is clearly a bug in pdfwrite. Nothing in the change I made in the PCL interpreter should change the result, and it does, so there's a bug. THe first one (which I've fixed) was definitely a potential bug for PDF input. | 14:27.28 |
| | THe three files which have problems (22-09, 22-10 and 30-05) all have 'text' which shouldn't be there | 14:28.15 |
| | It probably all the same problem, the other file 'enter.test' had missing text instead | 14:28.39 |
| henrys | in your bmpcmp? | 14:29.44 |
| kens | Yes | 14:29.48 |
| | the first results are just slight shifts in text position. Probably caused by the fact that I now flush text before a grestore takes place (that was the first problem) which presumably causes some fractional floating point difference in the position | 14:30.55 |
| | The PostScript tests are known indeterminisms, that just leaves the 3 files I mentioned | 14:31.32 |
| henrys | kens:as if your parameter is not taking effect? | 14:32.17 |
| kens | Yes, pretty much | 14:32.27 |
| | The content was missing previously, now its not | 14:32.37 |
| | Eg the club symbol in 22-10.bin | 14:32.54 |
| henrys | kens: that might be a bitmap or intellifont - will that matter? | 14:33.01 |
| kens | I shouydl say the *black* club symbol | 14:33.08 |
| henrys | I'm not sure where the parameter takes effect in the pipeline. | 14:33.34 |
| kens | The text render mode ? its associated with the text | 14:34.04 |
| | But I need to reduce these files a bit before I can see what's really going on | 14:34.29 |
| | Pag11 of two files, page 14 of the other.... | 14:34.44 |
| henrys | kens: well I'll do that piece just tell me which graphic you want. | 14:35.08 |
| kens | Ideall the line of text with the clubs in it on page 14 of 22-10.bin | 14:35.38 |
| | Since all the 'algorithms' seem to be the same, any one will do I guess | 14:35.59 |
| henrys | okay give me a few minutes | 14:36.14 |
| kens | Thanks, I'll grab a quick coffee then | 14:36.25 |
| tor8 | avih: wow, duktape is *really* slow... | 14:43.22 |
| avih | tor8: :/ didn't test it yet.. is it?? :/ | 14:43.45 |
| | it says someplace that it's comparable to lua, which i think is reasonably efficient for an interpreter (not luajit) | 14:44.15 |
| tor8 | running a fibonacci test (fib(1) through fib(20)) 1000 times | 14:44.31 |
| avih | it does have different performance bottlenecks than mujs | 14:44.53 |
| tor8 | with mujs compiled with exactly the same flags as duktape's default (-Os -fomit-frame-pointer -fstrict-aliasing) | 14:44.53 |
| | mujs takes 4s | 14:44.57 |
| | duktape takes 14s | 14:45.00 |
| avih | hmm | 14:45.04 |
| tor8 | spidermonkey without jit takes 4.5s | 14:45.16 |
| avih | http://duktape.org/guide.html#performance | 14:45.30 |
| tor8 | mujs with -O2 takes 3.5s | 14:45.30 |
| avih | though i think in most fib implementations it shouldn't hit noticeable perf bottlenecks | 14:46.20 |
| | but then again, i didn't actually use it yet | 14:46.29 |
| tor8 | nope, a fibonacci test should be a pretty raw interpreter overhead performance indicator | 14:46.52 |
| | i.e. how fast are recursive function calls and simple arithmetic | 14:47.13 |
| avih | also, it's main goals, other than completeness and real world compatibility, is low memory usage, which trades off speed i think | 14:47.46 |
| | tor8: and besides, mujs is fast-ish :) | 14:48.16 |
| tor8 | yes, I'm just surprised it's 3x slower... | 14:48.19 |
| | mujs and spidermonkey byte code interpreters are pretty much equivalent in performance | 14:48.31 |
| avih | yeah, i recall similar numbers too when i compared some stuff | 14:48.52 |
| tor8 | I'd have imagined any bytecode based JS would be in the same ball park, give or take 50% | 14:48.53 |
| avih | yeah, i guess they have more overheads. | 14:49.35 |
| tor8 | mujs is also smaller than duktape, but duktape does implement a fairly large set of non-standard extensions | 14:50.26 |
| avih | yes, and seems to be compatible with amiga os too :) | 14:50.49 |
| tor8 | 203kb vs 240kb with same build options | 14:51.05 |
| avih | and indeed, code size is about x3 compared to mujs. | 14:51.08 |
| | roughly the perf difference ;) | 14:51.13 |
| tor8 | must be a coincidence! | 14:51.24 |
| avih | sure, though a funny one :) | 14:51.33 |
| tor8 | though a significant chunk of mujs size are the unicode conversion tables | 14:51.39 |
| | eh, no, I take that back. the tables are only 7k | 14:52.16 |
| avih | i think the duktape api is cluttered. it mixes essentials with convenience functions and non negligible overlap between APIs, and it ends up quite bulky imo | 14:52.52 |
| | iirc mujs is ~15LOC and duktape is ~40k, right? | 14:53.57 |
| | 15K* LOC | 14:54.08 |
| tor8 | yes. | 14:55.12 |
| | sloccount puts mujs at 12.5kloc and duktape at 43kloc | 14:55.57 |
| | 44* | 14:56.05 |
| avih | i guess your design is better than, or duktape's extra functions end up hitting performance | 14:57.01 |
| | then* | 14:57.05 |
| | for searching properties, you have O(log n) with relatively small factor, and they use IIRC straight linear search arrays upto 36 properties, and string hashes for more properties | 14:58.19 |
| | but for normal non sparse arrays they have O(1) access. they only change it to named property based if the array becomes sparse enough | 14:59.08 |
| tor8 | okay, espruino can't even take fib(8) without asserting (stack overflows I guess) | 14:59.22 |
| avih | heh | 14:59.31 |
| tor8 | which is disappointing, but not unsurprising given their target platform | 15:00.08 |
| avih | never tried it, but failing for fib(8) sounds like a major issue. | 15:00.09 |
| | OTOH, until 50 days ago you could easily crash mujs with splice or end up with incorrect array values after some array manipulations ;) | 15:01.08 |
| tor8 | cannot have more than 15 'locks' on a variable in espruino... I guess they do variable scoping in some funny way | 15:01.36 |
| avih | and pop was terribly slow :) | 15:01.40 |
| tor8 | *nothing* can be as slow as espruino... | 15:02.58 |
| avih | IMO the requirements for a general JS engines are 1. stability 2. features. 3. speed. | 15:03.04 |
| tor8 | I bumped the stack limit | 15:03.08 |
| | it's still running... | 15:03.24 |
| avih | so usually 1 is taken for granted, but in practice, in several "small" engines which i tested that was not the case | 15:03.45 |
| tor8 | avih: I hope mujs now satisfies 1, at least better than 2 months ago | 15:04.19 |
| | 2m34s... | 15:05.28 |
| avih | tor8: i haven't experienced a single crash since your last stability fix, despite running it many many times (albeit with the js code not significantly changing between the runs), and it seems stable. | 15:05.32 |
| | lol | 15:05.36 |
| | is that for fib(1000)? or 8? :) | 15:05.45 |
| tor8 | 1000x fib(1..20) | 15:05.54 |
| avih | well.. you should do 1x first, then go through 10x, 100x, it would seem ;) | 15:06.33 |
| tor8 | 1000x was the smallest to get meaningful results from 'time' on mujs/spidermonkey/duk | 15:07.09 |
| avih | what's obviousl anyway? who uses it? | 15:07.46 |
| | espurino* (wtf??) | 15:07.56 |
| tor8 | it's competition in our target, internet-of-things | 15:08.16 |
| avih | oh. doesn't sound too fierce :) | 15:08.30 |
| tor8 | but as it stands, I'd say it's pretty much a joke if you want serious scripting | 15:08.34 |
| | but it *is* impressively small | 15:08.45 |
| avih | what good is small if it doesn't do what you like it to do? | 15:09.04 |
| tor8 | oh, wait, something must be wrong... | 15:09.04 |
| | the espruino binary is >400k | 15:09.14 |
| avih | so is it written in python and statically linked to it? ;) | 15:10.06 |
| tor8 | it's written in C | 15:10.35 |
| | but it interprets directly from source, never builds bytecode or a parse tree | 15:10.47 |
| | which makes it dreadfully slow, but saves RAM | 15:10.58 |
| avih | yup | 15:11.04 |
| | i guess it could be a useful tradeoff on some cases | 15:11.25 |
| | depending on how much is being traded off | 15:11.39 |
| kens | got the file henrys, about to start on it, thanks! | 15:18.56 |
| | Hmm, that's odd.... | 15:20.14 |
| henrys | your output should start with a black club if not I screwed it up. | 15:20.15 |
| kens | That file doesn't draw the clubs at all in PDF. I'll just check the raster output | 15:20.40 |
| | OK so it draws the clubs in raster mode. | 15:21.17 |
| tor8 | avih: mujs uses 165k for the fib test, duk uses 410k | 15:21.43 |
| | and v8 uses 18m | 15:21.48 |
| avih | :) | 15:21.59 |
| tor8 | valgrind doesn't like spidermonkey, it can't trace its memory allocations :/ | 15:22.08 |
| avih | tor8: see, duk is consistently 3x worse ;) | 15:22.11 |
| henrys | kens: pdf works for me. | 15:22.32 |
| avih | tor8: weird with valgrind. it's main maintainer works for mozilla... | 15:22.47 |
| kens | Yeah, but you don't have my patch :-) | 15:22.50 |
| tor8 | avih: I expect spidermonkey uses its own allocator | 15:23.00 |
| | espruino uses 34k :) | 15:23.12 |
| kens | OK now I'mpuzzled foo.pcl doesn't go through gthe code I changed | 15:23.23 |
| tor8 | so yes, there's definitely a memory/performance tradeoff there | 15:23.25 |
| avih | tor8: possibly own allocator, but i'm 99% sure it should work with valgrind, or at least can be made to work with some config options maybe | 15:23.50 |
| kens | decides to do a full rebuild | 15:23.52 |
| avih | tor8: i think mujs has a very good balance of speed vs code size vs runtime memory. it lacks a bit on features compared to more established engines, but very promising indeed :) | 15:25.11 |
| tor8 | avih: I think the biggest lack at the moment is documentation... | 15:25.31 |
| avih | dunno about it. it's not too bad imo | 15:25.49 |
| tor8 | and "use strict" would be nice to have | 15:25.49 |
| avih | and the fact that such small docs covers it reasonably well is a testament to its simplicity | 15:26.24 |
| | maybe it needs a bit more examples and possibly deeper explanation at places, but i think it just got enough (docs) to be reasonably useful | 15:27.09 |
| | anyway, gtg, meeting. later. | 15:27.58 |
| kens | henrys, when you run foo.pcl it goes through 'pcl_show_chars_slow' for you ? | 15:30.16 |
| | D'oh, I'm running the wrong file..... | 15:31.01 |
| | OK that's fine, the PDF has the first black club showing, so now I cna look at it | 15:32.24 |
| | Looks like the opposite screwup to the first problem, its never emitting the altered Tr. I suspect its a similar problem. | 15:33.07 |
| henrys | but why does it turn black that's what I was trying to figure. | 15:34.24 |
| kens | Well previously we just didn't draw it, now we do. I suspect its black because that's the inital color in the graphics library. If you don;t specify something else, that's what you get | 15:35.06 |
| henrys | yeah but the color was specified. | 15:35.31 |
| kens | Oh, I haven't looked at the PCL, just the PDF output | 15:35.48 |
| henrys | well no matter | 15:35.49 |
| | you may lazily set the color | 15:36.06 |
| kens | It coudl well be related, we aren't setting the graphics state properly, which is why the Tr goes missing | 15:36.06 |
| | We set *everything* lazily in pdfwrite, including buffering the text until we have to emit it. | 15:36.41 |
| | Ah, it looks like hte problem is we 'fall back' to the default implementation, because we can't deal with the font, I'm not sure why. I can special case that for text rendering mode 3 anyway and just drop it. | 15:46.22 |
| | We don't like the character code, its > 255 so we can't deal wiht it in a simple font. | 15:48.32 |
| | So we build a type 3 bitmap font from the glyph. | 15:50.57 |
| henrys | kens: I can live with that broken in the cet in exchange for the other improvements, we can make a low priority bug | 15:54.17 |
| | of course I never checked it fixed his original problem ;-) I assume you did | 15:55.08 |
| kens | I cna fix it by testing Tr before doing the fallback. We can't apply Tr to the fallback if its a bitmap, so that's as good as it gets. | 15:55.09 |
| | Yeah, his original problem is fixed. | 15:55.17 |
| | I'll do another cluster test in a second, just writing a few comments so I have some chance of figuring this out in future. | 15:55.49 |
| | Hmm, that seems to be messing up the customers file :-( | 16:03.17 |
| kens | wonders what I've done wrong | 16:03.26 |
| | Oh. The customer's file also triggers the fallback, but does not emit a bitmap font, it emits a vector type 3. Damn, more discrimination required. | 16:06.53 |
| McErroneous | Hi, again i am having problem to create a "printer-specific-file" with "gs". And again it does not creates an output-file. I typed "gs -sDEVICE=bjccolor -sOutputFile=Test.prn Address.ps | 16:17.23 |
| kens | What platform, what version of GS, where can we see the PostScript file, did you try any other PostScript input ? If not try the tiger in the examples folder | 16:18.16 |
| McErroneous | 8.71 | 16:19.14 |
| kens | Then the firast thing you need to do is try the current version, 9.15 | 16:19.29 |
| McErroneous | crunchbang 10 (codename statler) | 16:19.36 |
| | Hi, i can't create a "printer-specific-file" with ghostscript, since i am a noob i am using version 8.71 and it happend to me before, but worked later without updating "gs", is any of you able to see a mistake in following command in my home-folder: gs -sDEVICE=bjccolor -sOutputFile=Test.prn Address.ps ? | 16:47.58 |
| | It is display correctly on my screen | 16:48.12 |
| | displayed | 16:48.19 |
| chrisl | Presumably that drops you back to the gs prompt? | 16:48.33 |
| McErroneous | but the file does not get created.., yes...(-dBATCH) | 16:48.58 |
| kens | You didn't mention -dBATCH, please be *very* specific about hte command line, it maes a difference | 16:49.21 |
| tor8 | avih: just for comparison, the equivalent code in lua takes plain lua 1.6s, and luajit 0.10 | 16:49.48 |
| kens | When you say it displays correctly, what do you mean ? DO you mean you tried it without -sDEVICE=bjccolor ? | 16:49.50 |
| tor8 | which makes luajit 50% faster than both v8 and smjs with JIT | 16:50.01 |
| McErroneous | i displayed the ps-file with gv... | 16:50.57 |
| kens | GV is no use at all | 16:51.10 |
| Robin_Watts | McErroneous: OK, Give us the *exact* command line you are trying. | 16:51.12 |
| kens | Try it with "gs address.ps" assuming you have a build of GS which will display on your system | 16:51.43 |
| McErroneous | i gave it to you already... | 16:52.26 |
| kens | Ahem, you didn't mention -dBATCH, anything else you would like to mention ? | 16:52.46 |
| Robin_Watts | McErroneous: No, you didn't. You gave a command line, then said "oh, and there is -dBATCH". | 16:52.50 |
| | so, give us the exact command line you are using. | 16:52.59 |
| McErroneous | gs -sDEVICE=bjccolor -sOutputFile=Test.prn Adresse.ps | 16:54.10 |
| kens | So no -dBATCH then ? | 16:54.23 |
| Robin_Watts | OK. So instead of that, please try: | 16:54.31 |
| | gs -sDEVICE=bjccolor -o Test.prn Address.ps | 16:54.47 |
| | Damn. Got to step away. | 16:54.52 |
| avih | tor8: maybe the web should move to lua then :) | 16:55.08 |
| kens | The first problem I see is that there is (now at least) no bjccolor device | 16:55.12 |
| | We have 4 other bjc devices, but not that one. | 16:55.32 |
| chrisl | bjccolor must only be on the Unix builds | 16:55.51 |
| kens | Possibly, its not on my WINdows build | 16:56.03 |
| | I see it in contrib | 16:56.12 |
| | gdevbjc_.c | 16:56.21 |
| | So possibly it has simply bit rotted and doesn't work | 16:56.29 |
| avih | tor8: for luajit including the compilation? (i'm guessing yes?) | 16:56.48 |
| kens | Try -sDEVICE=tiff24nc and see if that produces output | 16:56.49 |
| chrisl | bjccolor does output a file for a simple showpage | 16:57.49 |
| kens | <shrug> maybe its a broken GS then. | 16:58.11 |
| | Try gs -sDEVICE=tiff24nc -sOutputFile=out.tif -c "showpage" -f | 16:58.46 |
| McErroneous | okay...., got a file created now..., "showpage was missing in the ps-file" hopefully that is the origin of the mistake.... | 17:00.29 |
| | but, i think it is wired... for the mistake to be in the ps-file..., why does gs- cares at all ? | 17:02.02 |
| kens | THat's what the spec says, no showpage, no output | 17:02.20 |
| chrisl | showpage is the operator that says "eject the page" | 17:02.40 |
| | gs is just doing what it's told | 17:02.53 |
| McErroneous | it told it to produce a file.., did i ? | 17:03.38 |
| kens | SO you'd be OK with a 0 byte file ? | 17:03.52 |
| | You didn't tell GS to print and eject the page, so it did not transfer any bits to the device. | 17:04.08 |
| McErroneous | hmm..., , well that at least could have given me a hint.., sorry , iam such a noob | 17:04.29 |
| chrisl | The thing is, there is nothing wrong with your file - it's perfectly valid, just doesn't emit a page | 17:05.00 |
| | I have a lot of utilities written in Postscript that don't emit pages | 17:05.19 |
| | I'd get quite annoyed if every time I ran one of those utilities, it insisted on creating an output file | 17:05.50 |
| McErroneous | is it, that the switch -sOutputFile or -o would tell ghostscript to create a file..., or am i wrong, and just missing knowledge ? | 17:07.51 |
| kens | That just tells it the name of the file to create, if it needs to create a file | 17:08.11 |
| Robin_Watts | McErroneous: The -sOutputFile and -o says "When you have data to output, this is where to put it" | 17:08.17 |
| | You never did a showpage, therefore there never was pagedata to output, so no data was produced. | 17:08.37 |
| kens | Not emitting a file is broadly equivalent to not emitting a blank sheet of paper | 17:08.40 |
| Robin_Watts | You can rail against postscript and say "that's not what I expected", but it's broadly like writing a C program and not providing a "main" and then wondering why your program doesn't work. | 17:09.29 |
| McErroneous | well..., i hope i got it right this time..., thanks to everybody | 17:10.05 |
| kens | henrys trying to distinguish the 2 cases (customer file and foo.pcl) is proving awkward. I can't currently see why we are not emitting the rendering mode for the reduced FTS file, I'll have to dig deeper. Its getting late here, so I'll get back to it tomorrow. | 17:12.23 |
| | translation: I've had enough for the day and I'm off..... | 17:12.40 |
| | Goodnight everyone | 17:12.45 |
| Robin_Watts | night kens | 17:12.54 |
| mvrhel_laptop | aha! now I see why my xpswrite output is failing for planar source images. it turns out that xps only supports chunky tiff image no planar so I will need to repack the data | 17:35.44 |
| henrys | mvrhel_laptop: or punt to rectangles if you don't want to spend the time on it. | 17:44.19 |
| mvrhel_laptop | henrys: it wont take long | 17:44.32 |
| | I am about done to the point where we will support all bit depths and configs. the only thing missing would be masks | 17:45.01 |
| | I am sharing the decode / map stuff out of the color monitoring code that was happening in the clist image enum which allows me to support just about everthing | 17:46.07 |
| | henrys: then I will get back to work on SOT. promise | 17:54.09 |
| henrys | mvrhel_laptop: oh don't worry about it. I'm concerned doing anything with this because of MS, if they would just do something that indicated XPS is not going into the trash bin I'd be happy | 18:00.21 |
| mvrhel_laptop | henrys: I think we are stuck with it in terms of printing which is my motivation here for gsview | 18:00.58 |
| | gsview printing is pretty decent speed wise now with the image code and the -dNOCACHE setting | 18:01.35 |
| | I suspect shadings may be slow still though | 18:02.01 |
| | but I am not as worried about that as I was with the images | 18:02.18 |
| Robin_Watts | henrys: come to skype. | 18:02.25 |
| mvrhel_laptop | come to the dark side | 18:02.33 |
| mvrhel_laptop_ | off to dr. appt. bbiaw | 18:20.54 |
| stenci | i am having a problem with ghostscript, where can i find some help? | 19:21.30 |
| chrisl_away | stenci: state your problem, someone here may be able to help | 19:22.07 |
| stenci | i have an excel addin that creates postscript files and puts them together into one pdf with "gswin64c.exe @gsparams" | 19:23.15 |
| | it usually succeed also with 1000 pages or more, today it fails after 135 pages | 19:23.38 |
| | with the following message: | 19:23.44 |
| | ERROR: limitcheck OFFENDING COMMAND: .makeoperator STACK: {--dup-- /FontType --eq-- 2 --index-- 32 --eq-- --and-- {--pop-- --pop -- false }{--resourcestatus-- }--ifelse-- } /resourcestatus /resourcestatus -dictionary- ( Version 5.2.2) /Creator -dictionary- -dictionary- | 19:23.53 |
| chrisl_away | stenci: that really isn't enough information to go on: we'd need the Postscript input and the exact ghostscript command line | 19:26.19 |
| | Your best bet would be to report the problem to the author of the plugin, and they can report it to us if it turns out to be a gs problem | 19:27.13 |
| stenci | it's a folder with 408 files, including the gs.cmd that does the job, should i zip it and... ? | 19:27.30 |
| chrisl_away | Well, if you want us to look at it, you would be best to try to reduce the problem to the smallest set of files (and pages) you can manage. | 19:28.47 |
| | stenci: also, what version of Ghostscript are you using? | 19:28.58 |
| stenci | 9.15 | 19:29.17 |
| chrisl_away | It looks like the job in question is just exhausting a particular resource - there is probably not a good solution for it | 19:32.21 |
| | stenci: if you want to open a bug report, with a minimal example of how to reproduce the problem, you can do so at bugs.ghostscript.com | 19:33.30 |
| stenci | i tried to run it with the files 1-100, 101-200, etc. and it always works, but if i run it with more than 135 files it crashes, so the "minimal" example involves many files | 19:44.42 |
| | i will report a bug | 19:44.50 |
| chrisl_t530 | stenci: FWIW, the error message makes me suspicious: no PS input should be called the .makeoperator operator - it's really a Ghostscript "internal use only" extension | 19:57.30 |
| stenci | i modified the gsparams file and ran it many times with the first 100, second 100, etc .ps files, and they all worked well | 20:01.49 |
| | i couldn't find any .ps file that fails | 20:02.16 |
| | and this is an excel macro that we used every day to create pdf files with hundreds or thousands of pages, and never had a problem for more than one year | 20:03.05 |
| chrisl_t530 | Hmm, actually, I think I might know where the problem is..... | 20:03.08 |
| stenci | :) | 20:03.17 |
| | i just reported a bug: http://bugs.ghostscript.com/show_bug.cgi?id=695745 | 20:03.51 |
| chrisl_t530 | Thanks, okay. I'll take a look - but probably tomorrow (I finished work a couple of hours ago) | 20:04.23 |
| | Grr, it's not a crash, it's an error! | 20:04.47 |
| stenci | ? | 20:05.06 |
| | it exits half way, isn't that a crash? | 20:05.15 |
| | i'm just asking, perhaps i'm using the wrong word? | 20:05.47 |
| chrisl_t530 | What you have is a graceful exit with an error condition. A crash, it would just exit without error or warning | 20:06.33 |
| stenci | i usually call errors wrong results, crashes incomplete results caused by an early unexpected exit | 20:06.38 |
| | ok | 20:06.53 |
| chrisl_t530 | You'd probably get the Windows "program caused a problem....." dialogue | 20:07.06 |
| | with a crash | 20:07.10 |
| stenci | ok, makes sense | 20:07.42 |
| chrisl_t530 | "Crashes" are generally more critical as they can indicate security problems, amongst other things. | 20:08.40 |
| stenci | should i edit the bug description? | 20:09.39 |
| chrisl_t530 | I've already done so | 20:09.47 |
| stenci | thanks for your time, see you tomorrow | 20:10.31 |
| | maybe... | 20:10.37 |
| chrisl_t530 | Er, you haven't attached the files | 20:10.50 |
| stenci | what??? i waited 2 minutes for it to go, and i had... | 20:11.14 |
| | ok | 20:11.14 |
| chrisl_t530 | Oh, they might be too big for our bugzilla database - how big? | 20:11.40 |
| stenci | it's 10MB, the interface says 51MB is the limit | 20:12.15 |
| | it's uploading again, 80% | 20:12.22 |
| chrisl_t530 | Hmm, yeh, that should be fine | 20:12.26 |
| stenci | now i see it | 20:12.35 |
| chrisl_t530 | Yeh, me too | 20:12.47 |
| | Forward 1 day (to 2014/12/18)>>> | |
IRC Logs
