| <<<Back 1 day (to 2017/01/10) | 20170111 |
Zeranoe | Something's up with the way that GS handles transparent "shadows". http://i.imgur.com/LlAUuKx.png Left is GS, right is original. | 01:36.25 |
husstech | hey, just a really quick one hopefully. When using "mutool draw -o %d.png filename.pdf" are there any other flags I need to set for it to use multithreaded mode? I see in the options there is -P, but that causes a segfault for me. Sorry if this is a simple question, I've been reading the source mudraw.c, example.c and multi-threaded.c, but I can't decipher if the command line tool needs to have a flag set. It's late here for | 01:58.53 |
| Thank you for your time | 01:58.58 |
camelopard | Zeranoe: Please file a bug report on bugs.ghostscript.com | 02:25.54 |
Zeranoe | camelopard: Done. https://bugs.ghostscript.com/show_bug.cgi?id=697472 | 04:05.33 |
Darajan | Hello, I'm debugging a mupdf SIGSEGV issue and saw talk about a '/home/support/693503/*/3192.pdf.SIGSEGV.b0.2438' pdf file back in the IRC logs from 2013 (yeah i know :) ). Any chance at all that this file can be retrieved? | 10:14.07 |
kens | That's a customer file, we can't give it out | 10:15.42 |
Darajan | Do you have any simmilar files causing the same issue? | 10:16.50 |
kens | TO answer that I would first have to know what the problem was with that file. Since that was only one from a group of files, I don't know the answer offhand, I'm not dead keen to spend time digging up 3 year old fixes to be honest. | 10:17.59 |
| Also, the problem was fixed, and remains fixed, since that file was added to our test suite (I think) | 10:18.18 |
Darajan | I understand that, the problem relates to #693503, any other file bound to that issue that you can give out would be helpful for me. I understand if you can't | 10:19.02 |
kens | SOrry, all the files relating to that bug report were customer files, we can't give out any of them | 10:19.28 |
Darajan | Ok, thank you | 10:19.34 |
Robin_Watts | Darajan: So... you are debugging a MuPDF segv that's already been solved? | 10:20.51 |
Darajan | The project I'm working on uses the jmupdf library, which itself depends on binaries from an older version of mupdf | 10:22.13 |
| It's a pita as you can imagine | 10:22.24 |
Robin_Watts | Darajan: So... can you just fix jmupdf to work with the newer version of mupdf? It would seem a saner solution. | 10:27.26 |
Darajan | Yes thats what I'm going for, or just removing jmupdf and going straight to mupdf. What I'm looking for is just a way to reproduce the problem detected in our logs & a way to say "yes, this solved the problem" | 10:28.51 |
| Customer did not give access to the file | 10:28.58 |
| Any clues on "make java"? I have the third party libraries (uncofigured) & get a "No package 'freetype2' found" error from pkg-config | 14:55.15 |
kens | Darajan you are building MuPDF from source ? | 15:09.28 |
Darajan | yes | 15:09.37 |
kens | Did you do the submodule update from the Giot repository ? | 15:09.55 |
| BTW I'm not an expert on MuPDF.... | 15:10.02 |
| But I cna ping people who are :) | 15:10.08 |
Darajan | yes & make generate | 15:10.49 |
kens | OK then let me find someone | 15:10.55 |
| Presumably there is a freetype2 directory in the source directory ? | 15:11.54 |
| underthirdparty | 15:12.10 |
Darajan | no, but i have a "freetype" directory | 15:12.21 |
kens | ah, should be freetype, not freetype2, that's 'ionteresting' | 15:12.28 |
| Urr, wait.... | 15:12.46 |
| Why are you running pkg-config ? | 15:12.55 |
sebras | Darajan: do you have a thirdparty/freetype directory? | 15:13.00 |
Darajan | yes | 15:13.05 |
sebras | kens: Darajan: so pkg-config is being run from Makerules as we try to locate freetype. | 15:13.40 |
kens | So, you trype 'make java' and the error is returned by pkg-config ? | 15:13.43 |
Darajan | I also have a freetype directory under build/release/ | 15:13.47 |
kens | shuts up and leaves it to someone with a clue | 15:14.03 |
Darajan | yup | 15:14.05 |
| darareyahi@franklin:~/mupdf/mupdf-1.10a-source$ make java make -C platform/java Package freetype2 was not found in the pkg-config search path. | 15:14.11 |
| shit, username leak | 15:14.26 |
sebras | Darajan: that ok with me. :) | 15:14.39 |
Darajan | too eager | 15:14.44 |
sebras | Darajan: ok so the error message means that our makefiles attempted to locate freetype on your system and couldn't find it. | 15:15.06 |
| Darajan: I would assume that the version in thirdparty/freetype is being used though. | 15:15.22 |
Darajan | it seems to be looking for a file called "freetype2.pc" | 15:15.50 |
| however I can't find it in any directory | 15:15.59 |
ray_laptop | mvrhel_laptop: I just opened a bug -- I was trying to use the bitrgbtags device to work on the issue with BlendColorProfile to a device with tags, and it segfaults :-( | 15:21.51 |
sebras | Darajan: do you have the package libfreetype6-dev installed on your system? | 15:25.16 |
| Darajan: that package should include freetype2.pc for pkg-config to use, that way you'd avoid the error message. | 15:25.35 |
mvrhel_laptop | morning ray_laptop. after I eat breakfast I will take a look at it | 15:26.10 |
ray_laptop | mvrhel_laptop: np | 15:26.40 |
mvrhel_laptop | I suppose we should add the blend color space option to the weekly regression testing. That would have caught this | 15:26.59 |
ray_laptop | mvrhel_laptop: I'm having breakfast and my coffee as well | 15:27.07 |
mvrhel_laptop | bbiab | 15:27.15 |
sebras | Darajan: as to why we prefer to use the system freetype in this case I'm not sure. might be some kind of conflict between freetype in the dynamic library used for the JNI-bindings and a freetype used by the JVM itself. | 15:28.00 |
ray_laptop | mvrhel_laptop: just adding the bitrgbtags device to the weekly testing would suffice. It segfaults even without -sBlendColorProfile=default_cmyk.icc | 15:28.07 |
Darajan | sebras: i installed it and it seems to be building fine :) thank you | 15:28.17 |
sebras | Darajan: excellent. | 15:28.23 |
tor8 | Darajan: okay, stupid question, but is the thirdparty/freetype directory empty? | 15:34.56 |
kens | tor8 I think he's good now | 15:35.09 |
tor8 | ah, yes. catching up to the logs. | 15:35.22 |
| sebras: Darajan: we use the system freetype library for java builds because java uses the system freetype library | 15:35.49 |
| and if there are version mismatches, BAD things happen when you mix and match and functions from our built-in freetype call system freetype functions loaded from a shared library by the JVM | 15:36.19 |
| hence the hacks to build the core mupdf library with FREETYPE_DIR=/foo in the java makefile | 15:37.06 |
Darajan | tor8: no directory is not empty | 15:39.56 |
| tor8: build worked fine after i installed libfreetype6-dev :) | 15:40.38 |
tor8 | Darajan: okay, good :) | 15:42.31 |
Darajan | Any idea what VS-version i need to build the windows .dll's? | 15:43.04 |
| build party going on over here | 15:43.15 |
kens | AFAIK 2005 upwards shold be OK | 15:43.30 |
| I'm using 2008 | 15:43.35 |
Darajan | great | 15:43.43 |
sebras | tor8: right, as I assumed then. I had a vague memory of you mentioning this a long time ago, but didn't remember until I looked at platform/java/Makefile (I assumed we used thirdparty/freetype at first) | 15:59.52 |
| Forward 1 day (to 2017/01/12)>>> | |