| | <<<Back 1 day (to 2015/08/03) | 20150804 |
| sebras | you can extend the number of components fields in jpeg xr to hold up to 4111 components. wow... I wonder if there is ever has been a use case to use that many... | 08:42.14 |
| chrisl | I take it there is some crazy offset in how it's stored, otherwise that's a bonkers number | 08:44.58 |
| sebras | chrisl: there's a 4-bit number of components+1 field. | 09:38.25 |
| | chrisl: if it has the value 0xf then there is another 12-bit number of components+16 field... | 09:38.59 |
| kens | Smack of over cleverness, just like JPEG2000 | 09:40.25 |
| | Should have just made it a 32-bit number, its not like saving 28 bits is going to make much difference to an image file. | 09:41.10 |
| sebras | kens: 32 - 4 - 12 == 16, but yeah I do see what you mean. | 09:43.27 |
| kens | Well, I meant that the minimum was a 4-bit number in the spec, while a fixed 32-bit number would always be 32 | 09:43.55 |
| | So they save 28 bits, whoop-de-doo | 09:44.11 |
| tor8 | sebras: being too 'clever' so that no decent standard implementations are ever written can't have helped these image formats gain in popularity | 09:59.34 |
| sebras | tor8: I'm tempted to manually create a jpeg xr file using 4111 components and throw it at microsofts original hdphoto implementation just to see if it crashes. :) | 10:02.27 |
| | tor8: btw, I did figure out what was wrong with the alpha. | 10:02.54 |
| | tor8: sometimes the alpha channel is interleaved with the normal components, sometimes it is a separate plane. | 10:03.19 |
| tor8 | sebras: ah, as I feared then :( | 10:03.33 |
| sebras | tor8: the image alpha flag appears to indicate if the alpha is interleaved. | 10:03.39 |
| | tor8: I have also read up on the concept of | 10:03.52 |
| | "pages" in jpeg xr. | 10:04.01 |
| | tor8: it turns out that it restricts the dimensions of all "pages" and then mentions that hdphoto does not support it. | 10:04.36 |
| | tor8: but the T.832 standard doesn't state that. | 10:04.46 |
| | tor8: and I think that the concept of "pages" are different to planes in this context. | 10:05.07 |
| tor8 | sebras: right. so some half-baked attempt at multi-page images? | 10:06.24 |
| | like PNM and TIFF can do | 10:06.55 |
| sebras | tor8: yes. no notion of framerate though... | 10:07.03 |
| tor8 | not animated like gif :) | 10:07.12 |
| sebras | tor8: can PNM do that too? oh! | 10:07.13 |
| tor8 | at least! | 10:07.15 |
| | if you concatenate PNM files you're *supposed* to treat them as multi-page | 10:07.31 |
| | TIFF has multiple images in one file, and given that JPEG-XR seems to inherit the TIFF file structure with chunks etc I'm not surprised they kept that | 10:08.17 |
| sebras | tor8: right. | 10:08.31 |
| | tor8: attempted tone mapping last night. not even bad results yet. just horrid ones. :) | 10:09.11 |
| | tor8: how do I know in what order I should pack the 8-bit components in a fz_pixmap? is it RGBA? | 12:22.35 |
| tor8 | sebras: always alpha last | 12:24.51 |
| | so GA, RGBA, BGRA, CMYKA, etc | 12:25.09 |
| sebras | tor8: ok. | 12:30.25 |
| tor8 | sebras: does that answer your question? | 12:30.45 |
| sebras | tor8: I think so. | 12:31.31 |
| | tor8: but then I assume I must give cspace->n + 1 to fz_unpack | 12:31.44 |
| | fz_unpack_tile(). | 12:31.48 |
| | seems reasonable. | 12:32.16 |
| tor8 | sebras: pixmap->n == cspace->n + 1 | 12:32.50 |
| sebras | mmm. | 12:32.58 |
| tor8 | and that leads me to believe the comment at fz_pixmap_s in pixmap.h to have a typo | 12:33.13 |
| sebras | tor8: at the very end n=3, but it should be n=4. | 12:33.57 |
| | agreed. | 12:34.03 |
| | tor8: is CMYKA handled correctly when it is rendered? | 13:14.00 |
| tor8 | yes. | 13:14.15 |
| sebras | tor8: I might be messing something up but I'm seeing that altering the alpha channel affects the colors. | 13:14.18 |
| | tor8: and I'm just rendering the .jxr directly, no fancy .xps here... | 13:14.37 |
| tor8 | it gets alpha blended with the background, that would affect the colors | 13:14.58 |
| sebras | tor8: but tha background is white, would it then affect the colors? | 13:15.19 |
| | tor8: well.. I asume it is white. | 13:15.28 |
| tor8 | yes, it is white. | 13:15.49 |
| sebras | tor8: if I run mupdf-x11 test.png and it has alpha transparency would it blend with a white background? | 13:15.51 |
| tor8 | yes. mupdf-x11 calls fz_clear_pixmap_rect_with_value(255) to initialize the page to white | 13:17.04 |
| sebras | tor8: and the bit depth is the same 8 bits for alpha as for the other channels..? | 13:17.28 |
| tor8 | and if using mupdf-x11, the CMYKA pixmap will get color converted to RGBA before rendering | 13:17.29 |
| | a white backdrop, a black image with alpha 0.5, will become gray | 13:18.11 |
| sebras | tor8: I have no such image, I have a boat from maui. | 13:18.36 |
| tor8 | mutool draw -F png -c rgba will write the page as a png, but rendered with a transparent backdrop | 13:20.41 |
| sebras | let me try that. | 13:20.56 |
| tor8 | mudraw has a special case where it clears the page to transparent if the output format and colorspace has an alpha channel | 13:21.12 |
| sebras | ok. if I load that png into gimp I do see the alpha channel, but the colors are all wrong. | 13:23.17 |
| | tor8: surprisingly if I run the same file through mupdf-x11 it renders correctly, albeit a bit dark. | 13:23.58 |
| | now I'm fixing each samples alpha to 77. if I set it to anything higher I start to see red patches in the otherwise blue sea. | 13:24.32 |
| | around the boat that is. | 13:24.39 |
| | tor8: if fix the alpha to 0 or 255 then I see the same picture in mupdf-x11 though! | 13:26.27 |
| | running those two examples in mutool draw and then showing them in gimp gives me a fully transparent image when alpha == 0 (if I ask gimp to remove the alpha it gives me a white image), or the picture of the boat when it's 255. | 13:28.44 |
| sebras | is confused. | 13:28.48 |
| henrys | okay ate the Tuesday morning frog... mail sent to Aaron | 13:45.31 |
| kens2 | :) | 13:45.45 |
| chrisl | Does that make 11 times he's been told "no" on this? | 13:46.29 |
| jogux | :-) | 13:47.01 |
| henrys | a pesky but top 10 customer... | 13:51.22 |
| marcosw | morning all | 14:28.46 |
| henrys | meeting time 2 minutes, I need coffee | 14:28.50 |
| kens2 | morning | 14:28.50 |
| henrys | I'll be lucky to make it through this without needing a snack. I've probably consumed my bodyweight since Sunday | 14:30.50 |
| kens2 | How did it go ? | 14:31.04 |
| henrys | exactly the same as last year to the minute. | 14:31.20 |
| kens2 | NO worse at least then :) | 14:31.38 |
| chrisl | You said on fb it was a PB..... | 14:31.45 |
| henrys | yes a 20 second PB on a 12+ hour race. | 14:32.19 |
| chrisl | Still, better than 20s slower! | 14:32.32 |
| jogux | henrys: cool, congrats :) | 14:32.53 |
| henrys | it was a tougher course this year and I trained less so very happy with it. | 14:32.59 |
| | chrisl, how was the tournament? | 14:33.15 |
| chrisl | henrys: bad :-( | 14:33.27 |
| henrys | tor8 what do you think about XFA? Any initial thoughts on it, how is Jeong's work? | 14:35.09 |
| | mvrhel_laptop: let's get to closure on gsview licensing for engineering. Miles and Ted may want changes but let's tell them what we want. | 14:36.14 |
| mvrhel_laptop | henrys: ok | 14:37.00 |
| henrys | mvrhel_laptop, I think we all agreed (except you were going to think about it) GPL for vanilla gsview new acrobat-like features in a commercial only release with no source distribution? | 14:37.30 |
| rayjj | henrys: I assume that the UI parts of the 'pro' version can remain in the source, but just not do anything (in case we want them as hooks for "upgrade" reminders if someone clicks on them) | 14:38.53 |
| henrys | kens2: did you notice norbert's request for a "raster passthrough", how interesting is that for other Postscript and PDF. For PCL it is marginal because many images come in at device resolution. | 14:39.28 |
| | ? | 14:39.30 |
| kens2 | henrys no I missed it completely,did it go to support ? | 14:39.47 |
| rayjj | mvrhel_laptop: if that simplifies the coding | 14:39.48 |
| | henrys: I didn't see that either | 14:40.13 |
| kens2 | In general I would say it is not interesting for PS/PD, except for images whch are compressed with a lossy compression (JPEG/JEPG2000) | 14:40.33 |
| henrys | yes subject pcs 2 pdf conversion Jul 30? | 14:40.45 |
| mvrhel_laptop | henrys: having the split is easy enough coding wise (i.e. to put the extra features in separate files) but have grayed out UI buttons. I don't see any advantage though to fool around with GPL for the windows C# code | 14:41.03 |
| | Linux I understand the reasoning for the GPL for the simple viewer to get in the distributions | 14:41.26 |
| chrisl | henrys: I think Norbert would benefit from a clear explanation of the problems with rops and going to PDF | 14:41.38 |
| henrys | chrisl, that's a different thing I was asking about his item (2) | 14:42.25 |
| kens2 | henrys he only seems to be interested for performance reasons, and I doubt that this would be terribly great. I don't see how he cna not decode the image, but still compress the output (zip or flate) | 14:42.27 |
| | If the input isn't zip or flate, how can we not decompress it and still write it as zip or flate ? | 14:42.54 |
| chrisl | henrys: yes, but I mean in the context of what he's proposing, I suspect rops could be a killer | 14:43.03 |
| kens2 | I think he must be assuming we scale the input samples, which we don't (at least for PS or PDF) | 14:43.25 |
| henrys | chrisl, yes I'm going to discuss with him how difficult that will be. | 14:43.33 |
| | kens2, sound like I should get an example from him for that one. | 14:44.14 |
| tor8 | henrys: there's a lot of xml parsing crap for XFA. | 14:44.18 |
| kens2 | henrys that would probably be useful. Does the PCL interpreter scale the image samples before passing them to the graphics library ? | 14:44.42 |
| chrisl | henrys: cool, okay - I'd hate for them to spend a lot of time on it only to find it simply isn't viable for them (regardless of the specific limitations of our current code) | 14:44.47 |
| tor8 | we can't reuse much of jeong's code. the parsing is all in C++, though fairly trivial and probably easy to search/replace edit | 14:44.54 |
| henrys | mvrhel_laptop, sounds good about the licensing to me. | 14:45.28 |
| tor8 | the integration with the viewer and rendering is going to be worse, because he's using an ancient fork of mupdf | 14:45.31 |
| henrys | all: any comments about gsview licensing? | 14:45.37 |
| | tor8: just expat for parsing right? | 14:45.57 |
| tor8 | the fork is from before we added the device and document interfaces | 14:46.00 |
| | henrys: no, he's using a thirdparty C++ xml parsing library, pugixml | 14:46.46 |
| | we already have our own xml parsing that we use for XPS, SVG and EPUB | 14:47.09 |
| | which also postdates his fork, so he doesn't use that | 14:47.18 |
| henrys | rayjj: I am sort of worried about the packaging. It seems on windows we have a commercial license for everything and a free download then GPL on the other platforms. | 14:47.45 |
| | mvrhel_laptop, ^^^ | 14:47.52 |
| chrisl | It does open the chance of someone taking the Qt version and building it for Windows...... | 14:48.33 |
| mvrhel_laptop | yes | 14:48.43 |
| | that is very true | 14:48.46 |
| | and a concern | 14:48.49 |
| chrisl | Which would make us seem a bit petty | 14:48.59 |
| mvrhel_laptop | but they should not have source code to do the extra features that are not free | 14:49.25 |
| fredross-perry | Why would we make a different decision about free/commercial when it comes to windows, compared to other platforms? | 14:49.42 |
| henrys | The final issue is the P1's let's give these some hours this week, they've been sitting out for a long time and at least need status updates: http://bugs.ghostscript.com/buglist.cgi?list_id=23469&priority=P1&query_format=advanced&resolution=--- | 14:49.44 |
| chrisl | henrys: do you want to talk about fonts here, or should I reply to your e-mail? | 14:50.15 |
| kens2 | Is that the right URL ? | 14:50.17 |
| mvrhel_laptop | that url seems odd.... | 14:50.23 |
| chrisl | The url worked for me.... | 14:50.50 |
| henrys | fredross-perry because we cannot penetrate the linux or macos ecosystem with a commercial license | 14:51.01 |
| kens2 | I got a load of verified and fixed results | 14:51.03 |
| mvrhel_laptop | me too | 14:51.06 |
| henrys | works fine for me, but it is a "search" for the P1 bugs. | 14:51.29 |
| kens2 | YHe 'resolutoin=---' fell off | 14:51.42 |
| fredross-perry | Hmmm. | 14:51.44 |
| chrisl | Personally, I think we should be consistent in licensing across the supported platforms | 14:52.24 |
| henrys | maybe anything "enhancement" should not be P1? | 14:52.35 |
| kens2 | I agree, I thnk WInows should be the same as Linux | 14:52.40 |
| | henrys we disucssed haivg P1 enhancements before | 14:52.56 |
| chrisl | Also Bug 693684 is a slightly special case...... | 14:53.30 |
| henrys | I'd prefer free licensing but we are trying to reach a compromise with mvrhel_laptop who wants a straight commercial license. I thought that's where we were in this, maybe I've forgotten something. | 14:54.24 |
| | kens2, what did we say? ;-) | 14:54.51 |
| kens2 | henrys I no longer remember exactly | 14:55.02 |
| mvrhel_laptop | I don't mind free. I just don't think we need to supply the source code | 14:55.05 |
| fredross-perry | If youâre viewing the presence of a viewer as a âcalling cardâ, then would a non-pro version not suffice? Or is it necessary for users to experience (as opposed to read about) pro features in order to become more interested in becoming a customer? | 14:55.06 |
| mvrhel_laptop | at this stage | 14:55.14 |
| henrys | kens2, ROFL | 14:55.20 |
| kens2 | We all know I have no memory :-( | 14:55.29 |
| | I thought we decided that enhancements could be P1, but I can't be certain | 14:55.47 |
| chrisl | mvrhel_laptop: do you not think it a bit crap to have *just* the Windows specific source not open? | 14:56.01 |
| henrys | fredross-perry, we need open source to get in distributions: port, brew, ubuntu etc. | 14:56.17 |
| mvrhel_laptop | its a different code base and i don't see any advantage to do it | 14:56.26 |
| chrisl | Public relations, mainly..... | 14:56.38 |
| mvrhel_laptop | so no I dont think its a bit crap | 14:56.39 |
| fredross-perry | Yes, so have open source for a free version, and hold back the source of a pro version. | 14:56.41 |
| kens2 | I have to say I can't see why we wouldn't open the Windows code, what does it gain us to keep it private ? | 14:57.14 |
| chrisl | mvrhel_laptop: what's your *objection* to open sourcing the Windows version (as opposed to you don't see an advantage)? | 14:57.41 |
| henrys | we could do a free QT release for windows and say the native stuff is closed? | 14:57.50 |
| mvrhel_laptop | I just don't see a compelling reason | 14:57.56 |
| kens2 | Well, we could, but why ? | 14:58.00 |
| kens2 | puzzled | 14:58.10 |
| mvrhel_laptop | I would not say I have an objection. I do understand why you would have GPL for the linux distributions | 14:59.08 |
| kens2 | But why not simply make the Windows source open too ? | 14:59.25 |
| | TO me it does seem slightly perverse not to | 14:59.36 |
| fredross-perry | So, what IS the compelling reason for having a non-free version of gsview at all, on any platform? | 14:59.39 |
| kens2 | So we can sell it for money :-) | 14:59.50 |
| chrisl | I was under the impression that there was considerable common code between the two versions.... | 14:59.50 |
| mvrhel_laptop | why write software | 14:59.52 |
| fredross-perry | Over time I am hearing conflicting ideas on this, is why I ask in that way. | 15:00.24 |
| | You can make a piece of software for itself to generate revenue, or you can use it as a marketing vehicle to generate revenue for another product or service. | 15:01.44 |
| henrys | in a consensus situation you'll never reach a perfectly rational and reasonable solution. That's a good thing to live with though... | 15:01.45 |
| fredross-perry | SO I do think itâs helpful to *try* and decide which of these youâre on about, before committing to an approach. | 15:02.40 |
| henrys | In that spirit I think binary download windows the rest open source is something we can live with. | 15:03.01 |
| mvrhel_laptop | fredross-perry: true. if we are using gsview as a marketing tool then it should be open source def. If we are selling it for its features then having it open makes little sense to me | 15:03.11 |
| chrisl | TBH, I don't have a strong opinion, but if it gets popular, the question will be asked why one is open and one isn't, and we should have a clear answer for when that happens | 15:03.16 |
| jogux | chrisl: we could just say we don't like Windows users :-) | 15:03.37 |
| mvrhel_laptop | exactly... | 15:03.46 |
| fredross-perry | well, itâs true, right? | 15:03.48 |
| chrisl | didn't want to go there, but...... | 15:04.08 |
| mvrhel_laptop | if we run into that problem then its a good thing | 15:04.23 |
| | we can always open it up later if we want | 15:04.39 |
| tor8 | fredross-perry: historically, artifex has fallen strictly in the latter category (everything open source as a marketing vehicle) | 15:04.40 |
| rayjj | actually, what we don't like are the linux distros that refuse to include non GPL software (at least from us) | 15:04.46 |
| mvrhel_laptop | except SOT.... | 15:04.51 |
| tor8 | lately though, miles has become enamoured with the idea of selling apps on the app stores | 15:04.53 |
| henrys | we (Miles and Ted) are attempting to have a go at retail with this. I don't think it will work but it might. | 15:05.29 |
| chrisl | I wonder if we're making much money out of that | 15:05.39 |
| rayjj | if we were distributed by the linux distros, we would prefer to keep it closed source. It's not like we get all that much contribution from the community | 15:05.52 |
| henrys | so can I go with my proposal above and we can always change it down the road? | 15:06.13 |
| tor8 | it's hard to compete when there are so many free alternatives out there, like sumatrapdf and evince and adobe reader | 15:06.18 |
| fredross-perry | So given that, it makes sense (to me) to have a free open source version, and a paid non-open source pro version, on all platforms. | 15:06.34 |
| mvrhel_laptop | that would be fine too | 15:06.50 |
| henrys | mvrhel_laptop, oh okay I didn't think that was on the table. You seemed to want to keep the C# stuff out? | 15:07.21 |
| | rayjj, I don't know of any large distribution that will give it out without source. | 15:08.15 |
| mvrhel_laptop | well I could be convinced if it makes things more consistent across the platforms. Especially since someone could take the QT version and make a windows version | 15:08.16 |
| | to do the same features | 15:08.25 |
| rayjj | henrys: yeah, I know :-( | 15:08.32 |
| henrys | I guess we've gone past schedule, sorry about that. | 15:09.03 |
| mvrhel_laptop | henrys: so I do appreciate that aspect. | 15:09.05 |
| fredross-perry | It could be important where you draw the free/pro line. If the free version has just a couple of pro-ish features, but he pro version has many more, that might do it. | 15:09.28 |
| henrys | chrisl, the glyphs yes, I was hoping just to see a commit from you and 2 closed bugs... obviously I've been hanging around Miles too much. | 15:09.56 |
| chrisl | henrys: just sent an e-mail..... | 15:11.11 |
| henrys | chrisl, right I'm inclined to just sort of plan a future with Type 2's and not bother with pushing back on it? | 15:11.46 |
| chrisl | henrys: I suspect we'll still get pressure to include the kerning info in the AFM files | 15:12.23 |
| | henrys: typesetting and page layout apps usually prefer not to have to dig around in the font internals for such things | 15:13.07 |
| henrys | chrisl, I know I'm just thinking how much of that responsibility is ours? | 15:13.38 |
| chrisl | henrys: well, it's only ours because we have become the de facto "upstream" for these fonts | 15:14.14 |
| henrys | chrisl, so what happens when we go to Type 2? | 15:14.50 |
| | chrisl, did you still want to release the Type 1 and AFM's? | 15:15.13 |
| chrisl | henrys: well, if you recall, I did point out there would likely be a backlash from the open source world if we switch to Type 2 | 15:15.34 |
| | henrys: my preference would be to ship the OTF/CFF fonts and AFM files | 15:16.17 |
| henrys | okay let me do this other meeting then we'll come up with something. | 15:17.04 |
| Mo | tor8: I have built your branch. How can I use that Android-like control to browse forward? | 15:19.35 |
| tor8 | Mo: space and 'b' | 15:19.49 |
| chrisl | henrys: I was really hoping it would be a trivial "check this box" in their font design tool/application to generate the kerning information in the AFMs. | 15:20.04 |
| Mo | tor8: Thanks. But does not work here. space does skip pages. | 15:20.53 |
| | b does nothing. | 15:21.08 |
| tor8 | Mo: space and b are active shortcuts in both mupdf-x11 and mupdf-glut, so if b 'does nothing' as you say I wonder what you're actually using | 15:22.01 |
| Mo | tor8: I did git clone git://git.ghostscript.com/user/tor/mupdf.git; cd mupdf; git remote add tor git://git.ghostscript.com/user/tor/mupdf.git; git remote update; git checkout tor/glut; git submodule update --init; make; ./build/debug/mupdf-x11 my.pdf | 15:23.19 |
| tor8 | ./build/debug/mupdf-glut my.pdf | 15:24.42 |
| Mo | Same, b does nothing. | 15:24.52 |
| | what's the difference to -x11? | 15:25.01 |
| tor8 | how many pages is my.pdf? | 15:25.06 |
| | b goes back a page | 15:25.10 |
| | space goes forward | 15:25.13 |
| | if you zoom in, in mupdf-glut, space and b will advance by screen-ful and column just like the android app | 15:25.36 |
| Mo | Oh, I see. b on first page doesn't make sense. 76 pages. | 15:25.40 |
| | tor8: Cool, now it does with mupdf-glut, thanks. | 15:27.14 |
| | tor8: Will that ever got to the main branch? | 15:27.23 |
| tor8 | Mo: I hope so, but it'll most likely not be any time soon | 15:27.47 |
| | there are features missing that need to be added like search, copy & paste, and form filling | 15:28.12 |
| | well, form filling is missing in mupdf-x11 as well | 15:28.28 |
| Mo | Too bad, as it is highly required for zoomed pages, as there is no endless scroll like other viewers have. | 15:28.30 |
| tor8 | but search and copy/paste need to be added, and then there's the headache of depending on opengl for builds | 15:28.56 |
| | hopefully it will make it into the spring release 2016 | 15:29.34 |
| Mo | I know that formfilling is missing in mupdf, it's my best viewer only. For the rare case of form filling PDF I use others. And even then there are weird PDF only working in the one and only acroread which is not maintained on Linux anymore. | 15:29.42 |
| tor8 | I don't think it'll be ready for the fall release | 15:29.45 |
| | still, you can use mupdf-glut as it is now if you don't need search | 15:30.16 |
| Mo | Good PDF reads become more and more important today, as most of my Cloud space consists of (highly compressed) PDF files. | 15:30.25 |
| tor8 | the 'o' key will open and close the table of contents list, which is a new feature that is not in mupdf-x11 | 15:30.33 |
| | and the bookmark and history navigation is much improved in mupdf-glut as well | 15:31.08 |
| Mo | 'o' is nice. But I can't live without / search. This is even more important than Android-like browsing. | 15:31.51 |
| tor8 | Mo: yeah. it's the next feature on the mupdf-glut TODO list | 15:32.22 |
| Mo | I did not get to use Bookmarks yet in mupdf. History only for stepping back. | 15:32.25 |
| tor8 | but I don't get a lot of time scheduled for work on it | 15:32.33 |
| Mo | Is glut some kind of dev branch for main mupdf? Or some branched project? | 15:32.50 |
| tor8 | it's a feature branch, for a new basic viewer based on the GLUT library for windowing | 15:33.23 |
| | the x11/win32 viewer is aging badly, the code is really crufty | 15:33.45 |
| Mo | Interesting. At the end I'll wait for getting it pushed in my Linux distro | 15:33.56 |
| | Please keep it maintained. Using vim all the time and vim like apps, I always used mupdf for reading. | 15:34.26 |
| tor8 | if you really want, you could probably back-port the android-style navigation to the old x11 viewer | 15:34.26 |
| Mo | And on Android mupdf it the fastest backend on weak hardware and large PDF files. | 15:34.59 |
| tor8 | Mo: mupdf-x11 might turn into mupdf-glut, but the basic mupdf viewer isn't going away! I use it myself :) | 15:35.06 |
| Mo | tor8: I see, my distro has installed mupdf and mupdf-x11, what's different? | 15:35.48 |
| tor8 | nothing. mupdf should just be a symlink. | 15:36.03 |
| Mo | /usr/bin/mupdf -> mupdf-x11* I see. | 15:36.15 |
| | Thanks. | 15:36.55 |
| avih | tor8: hey :) mujs _seems_ to not support String.substr, am i right? | 15:50.18 |
| henrys | chrisl, before I write back is everything else fixed font wise? | 15:52.22 |
| chrisl | henrys: I don't know, I haven't had a chance to check the fonts fully - I'll have it done for (your) first thing tomorrow | 15:53.05 |
| henrys | chrisl, okay I'll request the metrics stuff after you're done. thanks | 15:53.40 |
| tor8 | avih: correct. String.substr is deprecated in ES5 | 15:53.46 |
| avih | oh.. but i _think_ it'd probably be nice to support it since every browser supports it | 15:54.10 |
| | and it's probably super simple to implement | 15:54.26 |
| chrisl | henrys: great, thanks. What I've checked so far, the fonts look okay - but then, they looked okay to me before, so.... | 15:54.26 |
| tor8 | avih: if you need it, it's trivial to add the function implemented in javascript | 15:54.45 |
| chrisl | Off now. | 15:54.51 |
| avih | tor8: that wasn't the point. i can always use substring instead. but i'm thinking about better compatibility. also, fwiw, i don't see that it's deprecated: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substr#Specifications | 15:55.30 |
| tor8 | avih: String.prototype.substr is defined in Annex B in the ECMA-262 5.1 specification | 15:57.18 |
| | avih: the chapter on 'hey, here are some things that have been found in the wild, but they aren't part of the spec' | 15:57.42 |
| avih | does it mean it's deprecated? also, it appeats to also be on ES6 according to that page | 15:57.52 |
| tor8 | avih: it's also in Annex B (Additional ECMAScript Features for Web Browsers) in ES6 | 15:59.14 |
| avih | IMO it'd be nice to support it. up to you of course | 15:59.27 |
| tor8 | http://www.ecma-international.org/ecma-262/6.0/index.html#sec-additional-ecmascript-features-for-web-browsers | 15:59.32 |
| avih | i believe you, but i still think the same ;) | 15:59.58 |
| tor8 | that paragraph heavily suggests what normal people would say deprecated :) | 16:00.01 |
| | avih: well, you could just add a prolog that defines the missing functions you want and run it when you create the mujs context | 16:01.57 |
| | I don't want to encourage bad programming, and using these deprecated functions would qualify... | 16:02.28 |
| avih | tor8: it's not a problem at all to bypass it in various ways. but it was a suggestion to increase mujs' compatibility with code in the wild | 16:02.47 |
| | especially if it's relatively easy and not harmful (for the code) | 16:03.29 |
| tor8 | I hear what you say, and I have thought about it. | 16:05.20 |
| | there are 6 functions in Annex B, but all of them have replacements that just work better | 16:06.24 |
| kens | Hey jogux, first time I;ve ever seen Tain in the national news: | 16:09.11 |
| | http://www.bbc.co.uk/news/uk-scotland-highlands-islands-33772228 | 16:09.11 |
| jogux | kens: :-) That's where you're originally from? | 16:10.15 |
| kens | One of my grandparents | 16:10.22 |
| | I still have relatives there | 16:10.52 |
| avih | tor8: i don't dispute that. i just say that adding such functions could increase compatibility with code out there. nothing more, | 16:11.08 |
| kens | That is, nevertheless, a pretty strong injunctoin *not* to implement these functiosn though. It looks to me like they *really* want these functions to die | 16:12.17 |
| jogux | kens: don't think I've ever been further north than Inverness... I really should sometime | 16:12.37 |
| kens | Well, it stays ligth longer.... I'm not sure there's any really good reason apart from that :-) | 16:13.04 |
| | Anyway, goodnight all | 16:13.11 |
| henrys | tor8: did want to check in with you about the github situation, it seems that was the dramatic changes in your absence. Are you good with everything as it is now? | 16:45.36 |
| jogux | henrys: we still need to decide on if / how we mirror the submodules onto github (due to them not support subdirs for repos) | 16:48.41 |
| henrys | of that business why not add each library we have to github and use that repo as a submodule? | 16:53.06 |
| | that should get chrisl_away ear's burning | 16:53.32 |
| jogux | henrys: I think it was just a case of renaming thirdparty/libjpeg.git to thirdparty-libjpeg.git or something. | 16:54.33 |
| | I know tor8 fiddled with this but not sure if he came to any conclusion other than github sucked :-) | 16:54.59 |
| henrys | oh okay if that's easier: I googled this and thought we could do something similar: http://stackoverflow.com/questions/5252450/using-someone-elses-repo-as-a-git-submodule-on-github | 16:56.11 |
| rayjj | speaking of submodules, does anyone object to me pushing the VS 2015 fix that's part of jbig2dec up to git.ghostscript.com/jbig2dec.git ??? | 17:53.17 |
| | chrisl_away: henrys: one of you can possibly answer me about the jbig2dec VS 2015 issue ^^^ | 18:23.02 |
| chrisl_away | rayjj: if you commit it to ghostpdl.git it *should* automatically mirror to the jbig2dec.git repo - if it doesn't, ping tor8 about it | 18:26.05 |
| Robin_ | rayjj: Push any fix you like. | 18:51.17 |
| | Unless we update the pointer in mupdf/gs they won't be affected. | 18:51.51 |
| mvrhel_laptop | bbiab | 18:58.09 |
| | Forward 1 day (to 2015/08/05)>>> | |
IRC Logs