| | <<<Back 1 day (to 2016/02/28) | 20160229 |
| kent3116 | Hi - Is anyone available to assist me with an issue I'm having with visual studio 2015 and the mupdf library ? | 01:31.03 |
| | ? | 01:34.51 |
| kent3116_ | ? | 02:32.15 |
| NTQ | Hi. I want to convert the text in a pdf file to black. Images should not be changed. Is this possible? If yes, how? | 12:51.42 |
| kens | NTQ you cannot do ths with Ghostscript as it curretnly stands. Undoubtedly you could modify the source code to do so. Of course first you will have to define 'text' and 'black' | 13:11.00 |
| chrisl | You could probably use the same approach as the object filtering in Postscript I wrote a while back - but you'd have to know Postscript quite well to do it | 13:14.53 |
| kens | You could undoubtedly modify the existing C device code too :-) | 13:18.45 |
| tor8 | kens: I hope you don't intend to use the cluster today... I'm about to push a huge set of commits. | 14:08.26 |
| kens | Well, only if I can fix thsi weird problem.... | 14:08.41 |
| | And my test will jump the queue anyway if I need to | 14:08.56 |
| rayjj | I updated the GhostscriptOrMuPDF twiki with timings from the slowest Celeron (x86) laptop I have around | 19:16.56 |
| | That's 1.6GHz. Imagine, right before I started with Artifex, we were running a large format inkjet 720 dpi running gs on a 100MHz Pentium (single core, of course) | 19:18.23 |
| | of course, inkjets are relatively slow to print, so it seemed reasonable at the time | 19:19.13 |
| Robin_Watts | My first desktop ARM based computer was 8MHz. | 19:28.45 |
| malc_` | Robin_Watts: bbc micro? | 19:29.29 |
| Robin_Watts | Archimedes. | 19:29.39 |
| | BBC was 6502 based. | 19:29.46 |
| malc_` | oh | 19:29.51 |
| rayjj | the 6502 was a cousin to a 6800 iirc | 19:40.28 |
| | 8-bit 16-bit address space, relatively sane register set and instruction set (unlike the 8080) | 19:41.19 |
| | bear in mind that after the IBM 360 asm, the PDP-11 (and 6800) instruction set was MUCH nicer | 19:42.47 |
| | the first printer that used Ghostscript in an embedded RIP used an 8MHz MIPS (risc) CPU, driving a 400 dpi 36 inch wide laser printer. Needless to say, it spooled the raster off to HDD before printing | 19:46.42 |
| | Peter didn't quite believe it when we told him what we were using it for | 19:48.32 |
| | Robin_Watts: what are the arguments for mupdf to generate cmyk. I would guess -c cmyk -F pam | 19:51.04 |
| Robin_Watts | mutool draw -o out.pam should do it. | 19:51.25 |
| | oh, but you want to avoid the writing time? | 19:51.33 |
| rayjj | Robin_Watts: is there a way to do that now ? | 19:51.49 |
| | (other than -o /dev/null) | 19:51.58 |
| Robin_Watts | no, just /dev/null, sorry. | 19:52.17 |
| | -F pam | 19:52.21 |
| | or -F pnm | 19:52.26 |
| rayjj | Robin_Watts: as long as it has the buffering of writes fixed | 19:52.50 |
| Robin_Watts | No, pnm is gray or rgb. | 19:52.54 |
| | It should do. | 19:52.56 |
| rayjj | (I'll know soon enough) | 19:52.59 |
| Robin_Watts | -F pam -C cmyk then, you were right. | 19:53.28 |
| rayjj | Robin_Watts: is there a way to select bit depth ? (istr, -b depth) | 19:53.30 |
| Robin_Watts | Not for pams no. Always 8 bit, I think. | 19:53.48 |
| | We always render in 8bits. | 19:53.57 |
| | 1bpp output formats are postprocessed. | 19:54.14 |
| rayjj | Robin_Watts: so "-c mono" is post halftoned "-c gray" ? | 19:54.54 |
| | (same as what happens with -F pbm) ? | 19:55.34 |
| Robin_Watts | Yes. | 19:55.39 |
| rayjj | Robin_Watts: OK. | 19:56.04 |
| | I'm pulling latest sources to update the mupdf performance numbers including mono 1-bit | 19:56.38 |
| | Robin_Watts: for 1-bit, what halftoning is used ? | 19:56.51 |
| rayjj | hopes not error diffusion | 19:57.04 |
| Robin_Watts | magic thresholding code. | 19:57.05 |
| rayjj | oooh, "magic" sounds good ;-) | 19:57.26 |
| Robin_Watts | That I wrote and then forgot about until someone pointed it out to me :) | 19:57.35 |
| rayjj | Robin_Watts: any chance that the threshold array can be diddled (i.e., user or implementor choice) ? | 19:58.31 |
| Robin_Watts | rayjj: It's a parameter to the code, so sure. | 19:58.49 |
| rayjj | Robin_Watts: where's the magic ? (you can tell me on #artifex if it's a secret ;-) ) | 19:59.04 |
| Robin_Watts | mutool draw is just an example of how to call the C lib. | 19:59.10 |
| | source/fitz/halftone.c | 19:59.34 |
| | There is no magic. | 19:59.39 |
| rayjj | Robin_Watts: OK, thanks. | 19:59.44 |
| | Robin_Watts: but no way to get 1-bit cmyk, right ? | 20:00.13 |
| Robin_Watts | You want pkm output basically? | 20:00.54 |
| | It'd be easy to do I think. | 20:01.00 |
| rayjj | Robin_Watts: no, For benchmarking, I don't need output, but CMYK w/o color correction probably isn't important anyway | 20:02.54 |
| | mostly for comparison to gs, RGB contone and Gray or 1-bit are probably all that would be used | 20:03.31 |
| | (in a printer world) | 20:03.41 |
| Robin_Watts | rayjj: Well, we render in contone. Simple poor mans color correction could be used on the final image when going to 1bpp. | 20:03.50 |
| rayjj | Robin_Watts: oh, yuck. *MUCH* better to color correct before writing stuff, generally | 20:04.27 |
| | Even with a fairly large color conversion cache, converting entire rasters is a killer. | 20:05.05 |
| Robin_Watts | rayjj: Indeed, and that's on our list of things to do. | 20:05.09 |
| rayjj | not to mention, needing contone buffers vs. 1-bit | 20:05.41 |
| Robin_Watts | rayjj: a) This would only ever be an approximation. | 20:05.53 |
| | Doing color correction properly needs much more work, and requires contone buffers throughout. | 20:06.15 |
| rayjj | which "This" would only ever be and approximation | 20:06.33 |
| Robin_Watts | FAR better to just accept that fact and work with it, than to go through the hell of trying to pretend we're rendering in low bpp and interpose contone buffers higher up like gs does with the compositor. | 20:07.07 |
| rayjj | Robin_Watts: but with PDF14 transparency, I agree that one needs color management throughout | 20:07.27 |
| Robin_Watts | Rendering without color correction to a contone CMYK output and then 'bending' the output down to 1bpp will only ever be an approximation. | 20:07.44 |
| rayjj | Robin_Watts: d'accorfd | 20:07.59 |
| Robin_Watts | The correct thing to do is to put proper color correction into mupdf. | 20:08.00 |
| | and that might be what Michael gets to do next :) | 20:08.15 |
| rayjj | Robin_Watts: that;s quite a performance hit. So making it "optional" adds complication, but is important for some users that don't care | 20:09.03 |
| Robin_Watts | rayjj: Yeah. | 20:09.15 |
| | Ideally it'll be both a runtime or a compile time option. | 20:09.54 |
| rayjj | Robin_Watts: runtime isn't too bad of a performance hit with gs. | 20:10.54 |
| | compile time makes the code less readable/maintainable IMHO | 20:11.33 |
| Robin_Watts | rayjj: We'll find a way to make it look nice. | 20:14.12 |
| rayjj | having mupdf detect (by pre-scanning the input PDF or while writing the display list) whether or not transparency is needed, _would_ let it have pre-select a rendering device that was 1-bit vs. contone | 20:14.23 |
| Robin_Watts | The antialiasing level in mupdf is both compile time and runtime configurable. | 20:14.33 |
| | rayjj: We already check for transparency or not, but I am not coding the rendering that way. | 20:14.54 |
| | It compromises the quality you get out at the end. | 20:15.11 |
| rayjj | Robin_Watts: and detecting color vs. monochrome during display list creation is a *real world" desire | 20:15.22 |
| Robin_Watts | (Look at gs with halftoned output with small patterns for example) | 20:15.56 |
| | rayjj: Yes, I think I already have a neutral color detector in there somewhere. | 20:16.29 |
| | Got to step afk for a bit. | 20:17.07 |
| rayjj | Robin_Watts: I agree that rendering to contone and then halftoning is better quality, but for performance applications, going directly to 1-bit is better on low end CPU's that the price sensitive (paranoid) printer vendors want | 20:18.12 |
| kent3116 | Morning - is anyone able to offer a hand with mupdf and visual studio compile link issue I'm having ? | 20:46.14 |
| | Or is it afternoon ? | 20:50.58 |
| rayjj | kent3116: maybe. Most of the mupdf developers are in the UK, so it's evening there, but some of us (mvrhel and I have built mupdf with VS) | 20:52.55 |
| | kent3116: first, which mupdf source and which VS version ? | 20:53.16 |
| | plinnell: you seem to have a LOT of network connection issues | 20:55.56 |
| | kent3116: I'll be around -- it's 1pm where mvrhel and I are, so we might be able to help. Even if we are not on IRC, we can check the logs when we come back on | 20:59.07 |
| kent3116 | Hi Rayjj | 21:02.50 |
| rayjj | Hi, kent3116 | 21:02.58 |
| kent3116 | I downloaded the latest from http://mupdf.com/downloads/ | 21:03.29 |
| rayjj | OK, so that would be 1.8 | 21:03.53 |
| kent3116 | I'm in NZ - it's 10am here. | 21:03.54 |
| | yup | 21:03.58 |
| rayjj | (we're about to release the next 1.9 ???) | 21:04.08 |
| | but that's OK. Which VS are you using | 21:04.24 |
| kent3116 | 2015 | 21:04.31 |
| | I can compile and work the download - that's fine. | 21:04.45 |
| | I'm now trying to integrate it into my existing project. | 21:05.06 |
| rayjj | OK, so what's the issue ? | 21:05.07 |
| | well, that may not be something I can help with, but proceed with your explanation' | 21:06.01 |
| | (since I have *NO* idea what your existing project is) | 21:06.25 |
| kent3116 | I've added the 'generated' 'libmupdf' and 'libthirdparty' projects into my project. | 21:06.47 |
| | I've added the header files to my project. | 21:07.27 |
| | When I compile my project - I'm getting an unresolved external symbol. | 21:08.03 |
| rayjj | kent3116: such as ? | 21:08.54 |
| | BTW, you may need mupdf-curl | 21:09.10 |
| kent3116 | SeverityCodeDescriptionProjectFileLine ErrorLNK2019unresolved external symbol "struct fz_context_s * __cdecl fz_new_context_imp(struct fz_alloc_context_s *,struct fz_locks_context_s *,unsigned int,char const *)" (?fz_new_context_imp@@YAPEAUfz_context_s@@PEAUfz_alloc_context_s@@PEAUfz_locks_context_s@@IPEBD@Z) referenced in function "void __cdecl pdf_OpenDocument(void)" (?pdf_OpenDocument@@YAXXZ)IDMAD:\Plugins\idma_Plu | 21:09.20 |
| | So far, I've only added two lines of code. | 21:21.18 |
| | fz_context *ctx; ctx = fz_new_context(NULL, NULL, FZ_STORE_UNLIMITED) | 21:21.22 |
| rayjj | kent3116: sorry -- on the phone -- just a minute | 21:25.55 |
| Robin_Watts | kent3116: Are you coding in C++? | 21:26.15 |
| kent3116 | No worries - I had a couple of calls as well. | 21:26.39 |
| | Yes - I have both c and c++ | 21:26.51 |
| Robin_Watts | If so, you should surround the #include "mupdf/blah.h" sections with extern "C" { .... } ; | 21:27.12 |
| rayjj | Robin_Watts: yeah, the fz_new_context_imp undefined may be looking for a C++ function | 21:30.57 |
| | the gobbledygook of the error message lines means little to me. One frustration I have is that clicking on the error message no longer takes me to the source line that caused the problem(with Vs 2015). At least Vs2008 still "works" | 21:33.16 |
| | Robin_Watts: btw, I am going to re-run the mutool draw benchmarks before posting them. If you want to "replicate" them, I can send you the scripts I am using to run and extract the "best of" runs | 21:34.45 |
| | that's on the raspberry Pi | 21:34.59 |
| | you /should/ have time to finish the runs by the time you have to leave for the airport ;-) | 21:35.33 |
| kent3116 | aaaahhhhh - that worked ! | 21:36.10 |
| rayjj | kent3116: great! Thanks, Robin | 21:36.28 |
| kent3116 | Thank you - I spent a whole day Sunday banging my head around this | 21:37.11 |
| rayjj | kent3116: hopefully on something softer than a concrete wall ;-) | 21:37.54 |
| kent3116 | Actually - I had a nice bruise on my right shoulder from where I ran into the door frame in the weekend - but that had nothing to do with this :) | 21:38.47 |
| | BTW: What does mupdf-curl offer that I may need ? | 21:39.49 |
| rayjj | kent3116: you may want to clone the mupdf git and pull that -- there are many interesting updates since 1.8, particularly if you are a Java or javascript developer | 21:39.54 |
| | kent3116: mupdf-curl is used by mupdf to "pull" content from an http: server | 21:40.38 |
| | (as I understand it) | 21:40.47 |
| | I haven't played with that. Robin did that AFAIK | 21:41.17 |
| | kent3116: AIUI it was to allow mupdf to pull "web optimized" PDF's from a server using byte-code range access so pages could be displayed before downloading an entire PDF | 21:42.50 |
| kent3116 | No JAVA or javascript use. | 21:43.30 |
| rayjj | kent3116: I wouldn't know. curl == C URL lib | 21:43.59 |
| | kent3116: so are you a Jave or JS implementor ? | 21:44.27 |
| kent3116 | thanks for the info on mupdf-curl - don't believe that I'll need that - testing will tell | 21:44.34 |
| | Sorry, I don't use any Java or javascript in my application - pure windows / Mac application | 21:45.09 |
| rayjj | kent3116: if so, the new JNI bindings and JS implementation may be of interest. If you are just using C/C++ apps, then probably not | 21:45.50 |
| kent3116 | just c / C++ | 21:46.01 |
| rayjj | kent3116: good enough | 21:46.25 |
| | (or probably better) | 21:46.36 |
| kent3116 | Right - thanks heaps for your help - hopefully now I can actually start actually figuring out how to use. My need is to: | 21:49.28 |
| | 1) Get a PNG representation of a specific page | 21:49.39 |
| | 2) Print an entire PDF document | 21:49.46 |
| | 3) Merge two PDF's together | 21:49.55 |
| | From what I've read, this is all possible. | 21:50.11 |
| | Forward 1 day (to 2016/03/01)>>> | |
IRC Logs