| | <<<Back 1 day (to 2018/03/14) | 20180315 |
| tor8 | velix_inuse: okay, I looked at your example bug and file and I don't see any obvious problems with syntax or invalid refs. | 09:12.17 |
| | mutool convert throwing away layers is only to be expacted (that's after all what it's supposed to do--recreate the visual appearance of a document but in a different format), but how is the file invalid? | 09:13.26 |
| ohir | :) chan is kicking'n'alive. | 11:21.33 |
| | but after reading backlog I doubt I'll find licensing advice here.... | 11:22.53 |
| kens | You can discuss it, but if its legal, then you'll need competent leal advice | 11:23.19 |
| | We are not lwayers | 11:23.29 |
| ohir | I do understand AGPL but I could not find any estimate of commercial licensing costs. | 11:24.48 |
| kens | Oh well then you need to talk to our sales people, we don't do that either :-) | 11:25.05 |
| | Give me a minute, I'll find a link | 11:25.15 |
| | OK I've been told recently that people should go to: | 11:25.40 |
| | https://artifex.com/contact-us/ | 11:25.40 |
| ohir | because I am against cheating (as seen in many 'free readers' in playstore) I just wanna check ways for my inapp reader. | 11:26.11 |
| | thx, kens :) | 11:26.41 |
| kens | FWIW Artifex has been chasing a number of licence violators | 11:27.02 |
| ohir | good to hear | 11:27.45 |
| sebras | tor5: are you seeking review of tor/master? | 11:48.02 |
| tor5 | sebras: not at the moment | 11:48.12 |
| | still working on some of those commits | 11:48.24 |
| sebras | tor5: noted. | 11:48.31 |
| paulgardiner | There's a commit on my master branch, adding a win32_2015 platform with project files updated to VS 2015. This is needed for Windows muso | 12:14.57 |
| tor5 | paulgardiner: so you're saying I'm going to need to maintain *two* separate bunches of project files whenever I change something? | 12:17.42 |
| paulgardiner | Yeah bad. We're just discussing this on Skype. Maybe should move here. | 12:18.20 |
| kens | Or update to VS 2015 as standard | 12:18.33 |
| | But I think that precludes support for Win XP ? | 12:18.43 |
| tor5 | either we *radically* simplify the project structure for windows, or we ditch vs2005 support, IMO. | 12:18.58 |
| Robin_Watts | paulgardiner: As I said on skype. No. | 12:19.05 |
| | Make a muso branch. convert the project, commit it there. | 12:19.21 |
| tor5 | kens: I think VS2015 still supports winxp, it's just dropping win2k | 12:19.31 |
| kens | Oh, well one of those :) | 12:19.44 |
| tor5 | but given how much I use windows, I wouldn't bet on me being correct | 12:19.50 |
| Robin_Watts | That way whenever you want to update the submodule you reconvert the project. | 12:19.51 |
| | Every point on that branch works. | 12:20.00 |
| | The rest of the team isn't forced to do extra work to accomodate your particular needs. | 12:20.14 |
| | Or keep the converted projects in your own source tree. The choice is yours. | 12:20.36 |
| | Nothing after VS2005 supports XP SP1. | 12:21.16 |
| kens | Right. | 12:21.31 |
| Robin_Watts | everything else only goes back to XP SP2. | 12:21.32 |
| kens | While I'm not advocating the change, would it be a real disaster to drop support for an ancient obselete OS ? | 12:21.57 |
| Robin_Watts | kens: It'd be a shift in toolchain for no good benefit. | 12:22.25 |
| | Later VS's can import old projects, but it doesn't work the other way around. | 12:23.05 |
| kens | Well, it'd be would be a benefit for Paul :) | 12:23.14 |
| Robin_Watts | kens: At the cost of ****ing everyone else who doesn't have an (almost) up to date VS. | 12:23.43 |
| kens | True, and that would include me... | 12:24.04 |
| Robin_Watts | It's not that big a deal to have to reconvert the projects on the rare occasions when you resync the submodules. | 12:25.31 |
| | (if the projects have changed, which is rare). If they haven't changed it's just a single merge operation. | 12:26.09 |
| | What's more, you don't need to get reviews for the MUSO branch, so it's not like there would be a delay involved. | 12:26.31 |
| sebras | Robin_Watts: if we envision muso updating often, being on a separate branch would create a _lot_ of merging to the muso branch. | 12:26.54 |
| kens | I'm mostly intrested from GS's point of view really, wondering howmuch longer it'll be possible to import a VS 2005 project into current VS. | 12:27.08 |
| sebras | Robin_Watts: I see the benefits though. | 12:27.15 |
| Robin_Watts | sebras: Only if we envisage MUSO pulling in lots of changes. | 12:27.19 |
| sebras | Robin_Watts: yes, that's my underlying question, that I don't know th3e answer to. | 12:27.36 |
| kens | I'd assume MuSO would want the latest MuPDF, especially if Tor is doing lots of work to support features in it | 12:28.00 |
| | Though obviously that would settle over time | 12:28.10 |
| Robin_Watts | And the work involved is not HUGELY greater than the work involved in pulling in a changed submodule anyway. | 12:28.12 |
| sebras | Robin_Watts: after the first initial burst of development, maybe we envision mupdf to be updated only when a release is done..? | 12:28.18 |
| Robin_Watts | sebras: Indeed. | 12:28.26 |
| kens | should shut up really, since I'm not involved | 12:28.42 |
| sebras | Robin_Watts: agreed. | 12:28.58 |
| Robin_Watts | But the key thing is, is it reasonable for a requirement for MUSO should foist lots of work on to the main project? (i.e. keeping the VS2015 copies of the projects up to date constantly). | 12:29.16 |
| | My answer is no, bolstered by the fact that we have enough trouble ensuring the VS2005 ones don't get broken! | 12:29.38 |
| tor5 | as long as the vcproj files don't change, you wouldn't need to do anything when merging | 12:30.11 |
| paulgardiner | I'm not disagreeing. It was just a suggestion. Calm Calm | 12:30.13 |
| sebras | paulgardiner: :) | 12:31.35 |
| paulgardiner | I wondered if I need commit it anywhere at all, but I guess the answer is yes because of automated builds. | 12:33.34 |
| jogux | I'm guessing the conversion can't be automated, but I've not checked | 12:34.56 |
| paulgardiner | Making it part of the containing project has attractions, but I think what I have at the moment works only because the new folder is at the same level in the tree as the old. | 12:36.43 |
| | Make it part of the containing project, and have it copied into the mupdf tree as part of the build process perhaps. | 12:40.01 |
| Robin_Watts | The conversion is slow enough that you wouldn't want to do it on every build. | 12:40.02 |
| paulgardiner | I wonder, since we so clearly can see that keeping three build systems up to date is untenable, whether we should consider two too many. cmake? | 12:42.57 |
| Robin_Watts | paulgardiner: The act of requiring users to use a non-standard make system is itself a severely retrograde step. | 12:44.58 |
| jogux | I'm going to go out on a limb here and accuse vs2005 of being a 'non-standard make system' ;-) | 12:45.35 |
| Robin_Watts | gs manages to use the "natural" make systems everywhere (make on unix, VS/nmake). | 12:45.41 |
| | jogux: No. VS is the natural build system for windows. | 12:45.58 |
| jogux | VS2005 can't really be said to be. Not for anyone writing any kind of modern (ie. UWP) app. | 12:46.31 |
| sebras | wants to ask about what the three build systems are, but also doesn't want to participate in the discssion with a 10 foot pole. | 12:46.44 |
| jogux | sebras: ;-) | 12:46.55 |
| spanners | I came for the fistfight | 12:47.09 |
| Robin_Watts | and the VS scripts for gs call down to nmake, so it's actually a single make system really. | 12:47.10 |
| | sebras: make, VS2005, VS2015 | 12:47.21 |
| paulgardiner | sebras: maybe badly worded. I meant gmake, VS2005 and VS2015. | 12:47.37 |
| | :-) | 12:47.41 |
| jogux | I'd also throw in that working with mupdf in Xcode is a pita currently, and also that the current xcode integration has a build that takes an infinite amount of time :-( | 12:48.11 |
| Robin_Watts | jogux: Yes, there ought to be an xcode project. | 12:48.32 |
| | But then you'd have to find someone prepared to do that, cos I'm not going near that steaming pile. | 12:48.58 |
| paulgardiner | sebras: I have a similar level of attraction towards this discussion, but I just have less choice. :-) | 12:49.25 |
| Hufokus | Hello all! If I perform fz_run_display_list( g_ctx, lst, idev, &ctm, &RCT, NULL ) with fz_rect RCT.y0 set to 200, will page be rendered in pixmap at 200 pos in pixmap? Or will it be rendered at 0 pos in pixmap, but from 200 pos in source? | 12:51.00 |
| tor5 | Hufokus: neither. the RCT is used to limit the rendering to a subregion, so it won't touch pixels outside that area. | 12:52.13 |
| paulgardiner | Isn't the point of cmake that it can create VS projects, Xcode projects, Android projects all from a single project description... or have I misunderstood. | 12:52.16 |
| tor5 | Hufokus: actually, slight modification to my statement: it means that you are only interested in the pixels inside the area; it may still touch pixels outside but can drop objects that are outside it to save time. | 12:53.25 |
| | Hufokus: if you want to adjust where the render appears in the pixmap, use the e,f components of the ctm or the x,y coordinates in the pixmap when you create the 'idev' | 12:54.14 |
| spanners | paul> yes. it's a meta build system. | 12:57.34 |
| Hufokus | tor5: I ask because when I perform fz_run_display_list with RCT.y0 increasing up from 0, the labels and titles begin to disappear from the top of the rendered page. So it looks like RCT.y0 means position in pixmap, _where to render_? It starts rendering not at 0 position in pixmap? | 12:57.57 |
| | tor5: where does it put first pixel in pixmap? It puts pixel where RCT in fz_run_display_list points to, or at 0 position? | 12:59.40 |
| Robin_Watts | paulgardiner: If you can come up with a cmake file that actually produces a decent VS project and makefile from a single source, then I'll reconsider my position. | 13:00.07 |
| tor5 | Hufokus: the RCT argument is called 'scissor' -- it has nothing to do with where pixels are put, just which pixels it can avoid drawing altogether | 13:00.31 |
| | Hufokus: where pixels are put depends on (a) the ctm.e and ctm.f translation components | 13:00.45 |
| paulgardiner | Robin_Watts: I'm quite keen to try that. If I ever have time I will give it a go. | 13:01.07 |
| tor5 | and (b) the pixmap.x and pixmap.y origin coordinate (the top left pixel of the image is at these coordinates) | 13:01.10 |
| | so yes, if you increase scissor.y0 then items above that coordinate will be dropped from the rendering | 13:02.03 |
| | only objects within the scissor rectangle are guaranteed to show up | 13:02.22 |
| chrisl | paulgardiner: I couldn't find a decent way for a cmake generated build to call an interim executable as part of the build - not to mention, allowing for different compilers for different parts of the build process | 13:03.30 |
| sebras | paulgardiner: not sure if it helps any, but an alternative for cmake is https://premake.github.io/ which may or may not be better (I haven't used it). | 13:04.14 |
| tor5 | No. I would rather write an nmake file than use cmake. | 13:05.07 |
| | or any other bloated makefile maker. | 13:05.24 |
| | I am somewhat inclined to just drop in a statically compiled gnumake.exe in our source repository... | 13:06.04 |
| paulgardiner | chrisl: I think I've seen both those issues addressed in howtos | 13:06.08 |
| chrisl | paulgardiner: Possibly - I found a *lot* of instructions about how *cmake* could call executables, but in my (not hugely extensive) searchings, I couldn't find it for the resulting build files | 13:07.50 |
| | There is a project by a company I can't mention that uses a perl script to convert VS .sln and .proj files between versions. I'm guessing that if you don't use new features from new versions, there's not a lot of difference between the XML of the different VS versions | 13:13.01 |
| Hufokus | tor5: I do understant how scissor.y0 affects cropping of the source, but I can't understant why it also affects the position in pixmap where things are start rendering to. Or may be it's due to scaling matrix which I also apply with fz_run_display_list ? So how should I render to 0; 0 position of pixmap undependently? | 13:13.14 |
| | tor5: also I checked out: pixmap.y and pixmap.x are both equal to 0 | 13:13.37 |
| Suraj | Does anybody knows how to use mupdf c codein node js .If have any sample . | 13:17.52 |
| Robin_Watts | Suraj: The MuPDF team has not used it with node.js, as far as I know. | 13:18.33 |
| Suraj | Does anybody worked on mupdf integration in node js ? | 13:18.59 |
| tor5 | Hufokus: the matrix to fz_run_display_list will affect where things are rendered, yes. | 13:19.00 |
| | Suraj: Not that I'm aware of. | 13:19.14 |
| jogux | chrisl: I think there has been previous talk of checking in the results of the make generate phase into git; that kind of neatly sidesteps the issue. | 13:26.43 |
| Robin_Watts | tor5, sebras: Just prodding at Cody's issue now. | 13:31.52 |
| Hufokus | tor5: well but if I want to both use scaling and render at 0 pos, what should I do?) | 13:44.35 |
| tor5 | Hufokus: what are you trying to do? render a scaled full page image? | 13:46.31 |
| | render a zoomed in area of the page? | 13:46.37 |
| Hufokus | tor5: I want to render a zoomed region of pdf into window's client area. So I have to render it into 0,0 of the client area | 13:50.18 |
| tor5 | Hufokus: create a pixmap with the 'bbox' set to the area of the page you want rendered | 13:53.15 |
| | fz_new_pixmap_with_bbox | 13:53.35 |
| | the area is *after* the transform matrix has been applied, so it's in device space coordinates | 13:54.28 |
| Hufokus | tor5: oh, thanks, I'll try this | 14:04.10 |
| Robin_Watts | tor5, sebras: Cody's problem is down to resources in a Pattern. | 14:59.33 |
| tor5 | paulgardiner: try the commits on tor/for-paul to see if the bug 699026 is fixed | 15:51.56 |
| | I'm having difficulty testing this | 15:52.10 |
| Robin_Watts | tor5: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=b6be187699f056c18467116e00aab20b4ff30308 | 15:53.08 |
| | or: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=ac9005fca33064e6d38ff388de92bca15f0a4402 with added speeling. | 15:54.08 |
| tor5 | Robin_Watts: I'm not too happy about the name 'res' when I see lines like 'res = resources'. perhaps pattern_res and form_res would be better? | 15:54.22 |
| Robin_Watts | tor8: Sure. | 15:54.33 |
| tor5 | Robin_Watts: I'm leaving in about 10 minutes, but with improved names it LGTM | 15:56.04 |
| Robin_Watts | pat_res and xobj_res to match the stuff around it? | 15:56.08 |
| tor5 | Robin_Watts: sure. | 15:56.13 |
| Robin_Watts | Thanks. | 15:56.38 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a3527d2839a83e7a764e979b696693db53069a75 | 15:57.58 |
| tor5 | Robin_Watts: LGTM. | 16:05.44 |
| Robin_Watts | Ta. | 16:06.07 |
| fturco | hello | 16:19.25 |
| mubot | Welcome to #mupdf, the channel for 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. | 16:19.25 |
| fturco | i have the following problem: https://bugs.ghostscript.com/show_bug.cgi?id=697619 | 16:20.21 |
| | basically i have several epub files that i cannot open due to drm | 16:20.38 |
| | but if i edit them and remove META-INF/encryption.xml i can open them | 16:21.07 |
| | i would like to provide an example epub file to developers in order to help them fix this bug | 16:21.41 |
| | where can i send it? | 16:21.48 |
| kens | Attach it to the Bugzilla report | 16:21.56 |
| fturco | kens: i feel i cannot legally do that because it's a copyrighted work | 16:23.21 |
| | i can share it privately | 16:23.29 |
| kens | Well I can mark it private, which will prevent anyone else looking at it | 16:23.43 |
| fturco | ok, i'm going to upload it then! :) | 16:24.07 |
| kens | OK looking at the bug now | 16:24.20 |
| fturco | kens: done | 16:26.56 |
| kens | Its private | 16:27.04 |
| | I believe you should still be able to see it, and our staff can, but nobody else | 16:27.19 |
| fturco | kens: yeah, i can see it when logged in. i can't see it when logged out | 16:28.06 |
| kens | Yep, that's pretty much what I'd expect | 16:28.25 |
| fturco | in order to open epub books i previously used calibre. but i don't like it very much. too bloated. then i discovered mupdf. it can open both pdf and epub books! :) | 16:29.27 |
| | basically i started reading books again | 16:30.26 |
| | calibre modifies epub books on disk when you open them, while mupdf doesn't (as far as i know). this is good | 16:31.56 |
| sebras | fturco: thanks for helping out in improving the bug reports. | 16:36.52 |
| | tor5: I think you have reviewed sebras/master, save for the top one. | 17:35.08 |
| | tor5: ok, and the jbig2dec update too. | 17:39.32 |
| | tor5: it reclustered fine. | 17:59.38 |
| | Robin_Watts: can I trouble you with a review of sebras/master? | 19:27.54 |
| | Robin_Watts: it would be nice to get it in. | 19:28.16 |
| Robin_Watts | sebras: Sure. let me look. | 19:28.28 |
| sebras | Robin_Watts: most patches are small. | 19:28.47 |
| Robin_Watts | sebras: fz_warn(ctx, "freetype getting character advance: %s", ft_error_string(fterr)); | 19:32.40 |
| | freetype what when getting character advance? | 19:32.53 |
| sebras | it matches the existing ones, does it not? | 19:34.13 |
| | fz_warn(ctx, "freetype setting character size: %s", ft_error_string(fterr)); | 19:34.14 |
| | fz_warn(ctx, "freetype finalizing: %s", ft_error_string(fterr)); | 19:34.23 |
| | fz_warn(ctx, "freetype setting character size: %s", ft_error_string(fterr)); | 19:34.30 |
| | that's what I aimed for at least. :) | 19:34.53 |
| Robin_Watts | sebras: OK, so they all suck. | 19:36.18 |
| | freetype failed setting character size. | 19:36.31 |
| | freetype failed getting character advance. | 19:36.42 |
| | etc | 19:36.43 |
| | But never mind. | 19:36.47 |
| | The encryption one worries me, because it's encryption. | 19:37.04 |
| sebras | Robin_Watts: there are no less than two of those. | 19:37.28 |
| Robin_Watts | if n->length > 16*8, then you'll overwrite memory. | 19:37.46 |
| sebras | Robin_Watts: one is simply rearranging code. | 19:37.48 |
| Robin_Watts | The md5 result is always 16 bytes. | 19:38.09 |
| | so why do you now use n rather than 16 ? | 19:38.20 |
| | - fz_md5_update(&md5, key, 16); | 19:38.33 |
| | + fz_md5_update(&md5, key, n); | 19:38.34 |
| | That's not just rearrangement. | 19:39.08 |
| sebras | it should have been. | 19:39.21 |
| | the next patch takes care of exactly the case you mention. | 19:39.48 |
| | namely that I have seen a fuzzed file where length > 16, and then we overstepped the part of key initialized by md5. | 19:40.23 |
| Robin_Watts | sebras: So can you squash a fix for that back? | 19:40.55 |
| | otherwise all lgtm. | 19:41.05 |
| sebras | Robin_Watts: I'll fix that line, yes. I'll probably hand edit it. | 19:41.23 |
| | until then I'll merge the others. | 19:41.44 |
| | Robin_Watts: just we we're clear: I updated sebras/master and I'll only include th patches upto and including "Update to latest jbig2dec." OK? | 19:42.46 |
| Robin_Watts | ok. | 19:42.57 |
| sebras | Robin_Watts: thanks. | 19:48.50 |
| tor5 | Robin_Watts: you use 'n' instead of 16 because the spec says to use the first 'n' bytes of the md5 sum. | 20:45.29 |
| | oh. nvm, I'm tired :) | 20:46.38 |
| | Forward 1 day (to 2018/03/16)>>> | |
Log of #mupdf at irc.freenode.net.