| | <<<Back 1 day (to 2017/03/16) | 20170317 |
| vtorri | hey | 04:45.23 |
| 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. | 04:45.23 |
| vtorri | in mupdf 1.10a topevel Makefile, I can see : $(CC_CMD) -O0 when compiling fonts (line 198) | 04:46.26 |
| | why adding -O0 ?? | 04:46.37 |
| | it's a requirement to avoid optimisations ? | 04:47.06 |
| | i also think that, in mupdf, in the openjpeg files, opj_malloc.c is missong | 08:07.12 |
| | missing* | 08:07.26 |
| chrisl | It's hard to see how it would link if source files were missing..... | 08:17.53 |
| vtorri | well, i have a problem on Windows | 08:18.36 |
| | when creating the shared lib | 08:18.46 |
| | (i've added a rule for my p^roject | 08:19.14 |
| chrisl | Does the regular exe build and link? | 08:19.33 |
| vtorri | and i had an undefined ref because of that missing file | 08:19.34 |
| | i've not tried, i'm not interested in the tools | 08:19.53 |
| chrisl | Oh, right well, good luck | 08:20.23 |
| vtorri | i just tried to build a mupdf dll | 08:20.30 |
| | and as opj_malloc() is used, and opj_malloc.c is defining it, it makes perfect sense to add opj_malloc.c | 08:21.09 |
| | i just report that, do what you want | 08:21.28 |
| | in my case, i had to add it, and i have my mupdf dll... | 08:21.43 |
| chrisl | vtorri: a custom opj_malloc() is defined in source/fitz/load-jpx.c | 08:26.04 |
| | vtorri: and re. the font compiling: given how much time and memory it would take passing a source file of that size through the optimiser, it makes sense not do to so, given that it's pretty easy to make that happen | 08:28.51 |
| kens | I just did an upgrade to master, cledaned the solution and rebuilt. I get an error in mudraw.c(145) : error C2065: 'i' : undeclared identifier | 08:28.59 |
| | gl-main.c has an inline definition of GLFWvidmode, which causes VS 2005 to error out. | 08:30.47 |
| chrisl | Ah, works on Lijnux :-( | 08:31.06 |
| kens | VS can be told to allow it, I think its part of the project settings | 08:31.26 |
| | SO I presume the project is set to disallow it (all I've done is import the solution to VS 2008) | 08:31.42 |
| chrisl | Yeh, on gs we use the gcc option to disallow it | 08:31.47 |
| | Generally, (much to Tor's annoyance) we still try to avoid C99 constructs | 08:32.15 |
| kens | fatal error C1083: Cannot open source file: '..\..\thirdparty\openjpeg\src\lib\openjp2\thread.c | 08:32.24 |
| chrisl | Is your submodule up to date? | 08:32.59 |
| kens | The git pull said it was updating the submodules | 08:33.14 |
| vtorri | chrisl: here is the undef ref without adding opj_malloc.c https://thepasteb.in/p/58hgEOONAARfv (just for your information) | 08:33.20 |
| | oh | 08:33.41 |
| | it's for the thirdparty dll | 08:33.48 |
| kens | chrisl waht's the submodule voodoo ? I may as well do it manually to be certain | 08:33.49 |
| vtorri | not mupdf dll | 08:33.58 |
| kens | Yes. | 08:34.04 |
| chrisl | git pull --recurse-submodules | 08:34.09 |
| kens | Grr, ahde to unchange the solution files.... | 08:34.37 |
| chrisl | That's what stash is for | 08:35.00 |
| kens | Yes I know :-) | 08:35.49 |
| | Jut annoying because I hadn't done it | 08:35.56 |
| | Well it looks like the original pull did *not* update the submodules, despite the fact that it appeared to | 08:36.31 |
| | clean and build again, lets see what we get this time | 08:37.07 |
| | 8 succeeded 9 failed | 08:38.13 |
| chrisl | Well, that ain't good.... something for Robin_Watts I guess | 08:38.30 |
| kens | Still that missing source file too | 08:38.37 |
| | THat's after two declarations of 'int i' in mudraw.c and mving the declaration of GLFWvidmode | 08:39.05 |
| | I could be doing somethin wrong of course. | 08:39.39 |
| chrisl | Well, the file is there...... | 08:40.20 |
| kens | Looks like the openjpeg missing file leads to libthirdparty.lib not being built | 08:40.30 |
| chrisl | Maybe the path is wrong? | 08:40.55 |
| kens | Its not in my checkout | 08:41.18 |
| chrisl | It's there in mine..... | 08:41.33 |
| kens | Definitely not here. | 08:42.07 |
| chrisl | -rw-rw-r-- 1 cliddell cliddell 24K Oct 28 15:56 thirdparty/openjpeg/src/lib/openjp2/thread.c | 08:42.29 |
| kens | It *is* in my Ghostscript checkout of openjpeg | 08:42.31 |
| | also missing are thread.h, tls_keys.h | 08:42.55 |
| chrisl | There are in the repo: https://git.ghostscript.com/?p=thirdparty-openjpeg.git;a=tree;f=src/lib/openjp2;h=10d765c5b18290937a95122a0b2c541c3914a075;hb=19b3d33e7547682364a36a51e61ae38e068262ab | 08:43.45 |
| kens | SO why is Git not pulling it in ? | 08:43.57 |
| | Hmm, I wonder if my remote is wrong | 08:44.56 |
| chrisl | I dunno. Maybe cd into the thirdparty/openjpeg/src/lib/openjp2 directory, and do "git checkout HEAD *" | 08:45.30 |
| kens | what URL are you using for remote ? | 08:45.47 |
| | I have ghostscript.com:/home/git/mupdf.cit | 08:45.59 |
| chrisl | ghostscript.com:/home/git/mupdf.git | 08:46.37 |
| kens | Hmm, well barring my typo that's the same | 08:46.53 |
| chrisl | I assume you are on the master branch | 08:46.57 |
| kens | I suppose I could discard and reclone the repository | 08:47.03 |
| | Yeah on master | 08:47.09 |
| | git log | 08:47.23 |
| | :-) | 08:47.28 |
| chrisl | As I said, I would try explicitly checking out the files in the openjp2 directory | 08:47.44 |
| kens | Tried that, no difference | 08:47.51 |
| chrisl | Maybe delete the contents of thirparty, and do "git submodule update --init --recursive" | 08:48.40 |
| kens | Hmm well lets givce it a try | 08:48.51 |
| | Bah stupid windows says I can't delete the files. | 08:49.59 |
| chrisl | Well, that could be related to the problem...... | 08:51.08 |
| kens | Maybe, I can delete them, but sub-directoty by sub-directory, I ahve no idea what WIndows is doing.... | 08:51.40 |
| | OK cleaned up | 08:54.46 |
| | Yeah that worked | 08:56.43 |
| | Now to rebuild again | 08:56.47 |
| chrisl | Sounds like one of those odd quirks of git on Windows :-( | 08:57.07 |
| kens | Well it all runs under msys, so.... | 08:57.20 |
| | Maybe in WINdows 10 I can (eventually) use a proper bash | 08:57.32 |
| chrisl | Possibly. Another reason I prefer the (to me lesser) horrors of cygwin | 08:57.57 |
| kens | I've never got cygwin to run on WIndows | 08:58.11 |
| | OK so this time 10 succeeded, 4 failed, lets see why | 08:58.27 |
| | Ah this time there's a missing file in glfw | 08:58.48 |
| | Looks like Git is screwing up copying the submodules | 08:59.04 |
| | mudrsaw is still broken though | 08:59.40 |
| | chrisl do you have a 'stdiont.h' somewhere ? | 09:02.31 |
| | sorry stdint.h | 09:02.43 |
| chrisl | On my system? Or in the mupdf repo? | 09:03.03 |
| kens | It look slike its supposed to be a system file, its in '<' '>' brackets | 09:03.22 |
| chrisl | I have it in /usr/include/stdint.h | 09:03.27 |
| kens | ANd that's the file glfw3.h is complaining about | 09:03.33 |
| | I guess I just can't build the open-GL code | 09:04.43 |
| | If I fix mudraw.c then everything else builds | 09:04.56 |
| | javaviewer won't build for the same reason | 09:05.58 |
| chrisl | Well, mudraw.c tor8 can sort out, but the rest probably needs Robin | 09:06.05 |
| kens | I guess so yes | 09:06.13 |
| | Anyway back to proper work | 09:06.20 |
| tor8 | huh, weird. I guess I'll have to fire up my windows xp VM and take a look. | 09:07.04 |
| vtorri | tor8: hey | 09:18.28 |
| | tor8: what is the reason to have 2 static lib (mupdf.a and mupdfthird.a) instead of one ? | 09:18.56 |
| | kens: do you want me to try something on Windows ? I have msys2 | 09:19.40 |
| kens | vtorri no it seems that it a missing <stdint.h> on WIndows that's the problem, the checkout is OK | 09:20.32 |
| vtorri | ok | 09:20.38 |
| Robin_Watts | Ray may be booking flights at the moment. I'm sure he'll be here shortly. | 15:20.54 |
| kens | Hmm, so what you want is a separating device that supports CMYK but not spot colours | 15:34.04 |
| Robin_Watts | I believe it will do that, but (as I think you've found out), it can only do overprint simulation if it is holding the spots separately. | 15:34.39 |
| kens | overprint is only defined for spot colours ort colours *defined* as CMYK | 15:35.02 |
| Robin_Watts | (if we fold the spots down onto the CMYK planes, we've lost the information required to handle overprint) | 15:35.44 |
| kens | I don't think that's exactly the case, we havent' lost any information, but since hte original colour specification was not CMYK, overprint is defined to do nothing. | 15:36.29 |
| | THa's probably as correct as you are going to get, I suspect. | 15:37.36 |
| mvrhel_laptop | That should work find | 15:37.58 |
| | fine | 15:38.00 |
| kens | You can't, at least not in one passs, I don;t think | 15:39.19 |
| | Robin_Watts : its worse than that, because of overprint. | 15:39.36 |
| | II think the composite we produce 'works' (more or less) for spot overprints | 15:39.55 |
| Robin_Watts | kens: Why? overprint would be done on the CMYK +Spots. | 15:40.02 |
| kens | THis is really a Ray question I think | 15:40.08 |
| Robin_Watts | When we fold it down to just CMYK (i.e. form the composite), the overprint is all over and done with. | 15:40.52 |
| | It sounds like a modification of tiffsep1 to me. | 15:41.17 |
| kens | But tiffsep produces a composite not halftoned | 15:41.34 |
| | Or rather, the composite is 8 bit per component, not halftoned | 15:41.51 |
| | WHich is (I believe) why tiffsep1 does its own halftoning | 15:42.08 |
| Robin_Watts | kens: So we halftone during the fold down. | 15:42.21 |
| | (which won't play nicely with your desire to use tags :) ) | 15:42.35 |
| | s/tags/tag specific halftoning/ | 15:42.50 |
| chrisl | tiffsep1 doesn't produce a preview | 15:43.26 |
| kens | But they aren't hooked up like that | 15:43.29 |
| | SOrry tiffsep and apply the halftones like tiffsep1 | 15:43.44 |
| | WHich is, as I was trying to say, a new device | 15:43.59 |
| | But neither device 'as is' will do that | 15:45.11 |
| | Take the composite preview, write a tool to split it into CMYK planes and thne halftone based on the tags | 15:46.37 |
| chrisl | Hmm, a tag plane per ink plane, I wonder? | 15:48.01 |
| kens | Well a tag plabe for the composite would be OK | 15:48.18 |
| | You could use that as a reference when halftoning each plane | 15:48.35 |
| Robin_Watts | We're presumably working in planar mode. | 15:48.37 |
| | CMYK + Spots + Tags | 15:48.55 |
| tor8 | kens: the SAS flight I booked arrives and departs within 20 minutes of your flights. | 15:48.56 |
| kens | AH I ws assuming this was a related question | 15:53.23 |
| Robin_Watts | AIUI, this stuff is going to need to run in contone with separate planes for C/M/Y/K/Spots, and then fold down to just C/M/Y/K at the end, and then halftone. | 15:54.14 |
| | It wouldn't be beyond the wit of man to do C/M/Y/K/Spots/Tags and then fold down to C/M/Y/K/Tags and then selectively halftone. | 15:54.55 |
| | It does mean we'd need to write a cleverer halftone. | 15:55.17 |
| | (a cleverer halftoning routine, I mean. One that apply different halftones to different tags, rather than just to different planes) | 15:55.58 |
| chrisl | Different tags *and* different planes | 15:56.34 |
| Robin_Watts | Yes. | 15:56.48 |
| | I believe we have all the components required to do the non-tag version - it "just" requires replumbing (which can always reveal problems, of course). | 15:57.07 |
| ray_laptop | probably whatever we (I) did the tiffsep1 device for didn't need the halftoned composite at the time | 16:00.56 |
| | this would have the advantage of smaller buffers and could support 64 colorants and not have to use planar mode. The only "gotcha" is that the halftone tiles for the composite colors can get rather large depending on the nature of the halftone for each component | 16:04.16 |
| | GS finds a least-common-multiple widthxheight of the composite halftone to paint tiles | 16:05.02 |
| | with traditional screens rotated at common angles (0, 15, 45, 75) this can get large and inefficient | 16:06.07 |
| Robin_Watts | ray_laptop: Can we do overprint simulation with 1bpp devices? | 16:08.34 |
| ray_laptop | Robin_Watts: yes (or will be able to once bugs are out of it) | 16:09.45 |
| | the overpriint_sim compositor supports spot colors | 16:10.38 |
| Robin_Watts | ray_laptop: So, you're proposing that we run to a 1bpc cmyk+spots device that will do overprint simulation. | 16:11.08 |
| | How would we then fold the spots down onto the cmyk planes alone? | 16:11.23 |
| | folding the spots down requires, AIUI, working in contone. | 16:11.50 |
| ray_laptop | Robin_Watts: no, with the overprint_sim compositor, the target device can just be a 1-bpc CMYK | 16:12.01 |
| Robin_Watts | ray_laptop: OK. | 16:12.20 |
| ray_laptop | Robin_Watts: the overprint_sim _does_ work in contone (always) | 16:12.23 |
| Robin_Watts | right. the compositor works in contone, but hides it from the target device. | 16:12.42 |
| ray_laptop | so that it can collapse/blend the spots. Then it uses the normal DeviceCMYK image method to emit the page (going trhough CMYK->device_colorspace+halftoning) | 16:13.56 |
| | it can only use "put_image" if the device is contone CMYK, or with later optimization, contone. The optimization would convert the buffers using the color transform in order to use put_image | 16:16.07 |
| | and I have not thought through overprint_sim for a device that "has_tags" (should work similarly to the pdf14 compositor, though). The main "gotcha" is that only put_image allows us to pass the tag plane | 16:17.58 |
| | the current method for "dumber" devices of using a DeviceCMYK image would have everything tagged as image | 16:18.46 |
| | we'd need a CMYKt colorspace for that | 16:19.35 |
| | FORGET I SAID THAT ;-) | 16:19.49 |
| | have to run an errand | 16:20.12 |
| | AIUI, the PostRenderProfile would be applied *after* the CMYK is generated from the spots. | 16:25.35 |
| | mvrhel_laptop: comment if we are going somewhere ugly | 16:27.26 |
| mvrhel_laptop | ray_laptop: sorry I am off looking at mupdf stuff | 16:27.46 |
| ray_laptop | mvrhel_laptop: OK | 16:28.53 |
| | going for coffee. bbiab. I'll catch up with the logs... | 16:29.45 |
| mvrhel_laptop | ah. | 16:31.08 |
| | So I may be repeating what was said above but | 16:31.20 |
| | Ray finishing his overprint simulator and then using the tiffscaled device (and making a version with tags plane) would be the best approach | 16:31.57 |
| | Since it has that whole post processing set-up to do in the various threads | 16:32.23 |
| | So once ray_laptop wraps up his overprint compositor, we (or someone) could extend one of those devices to include a tags plane buffer. | 16:37.27 |
| | essentially those devices are already set up to do error diffusion for example if desired after rendering | 16:38.18 |
| | and they have the post render ICC profile application that you need | 16:38.37 |
| | the parts that are missing are ray_laptop's overprint simulation (which will give you the overprint you need by handing the spot correctly) | 16:39.06 |
| | and the object dependent halftoning | 16:39.17 |
| | not sure who is writing that last part | 16:39.23 |
| | oh and you need to make the device include a tags plane in its memory allocation | 16:39.45 |
| | Since you are applying an ICC profile at that time, you have to wait until after that occurs to halftone | 16:40.34 |
| | So you have CMYK + SPOTs + Tags --> CMYK + Tags -> CMYK (ICC profile) + Tags -> Halftoned CMYK | 16:41.30 |
| | tiffsep1 is doing its halftoning post rendering | 16:42.00 |
| | you could extend that device | 16:42.15 |
| | to use a tags plane and do your halftone there | 16:42.30 |
| | Yes. tiffsep1 is an odd duck | 16:42.49 |
| | iirc | 16:42.59 |
| | let me look | 16:43.02 |
| | which will include the tags information | 16:46.20 |
| | let me see if it is already doing the post render icc profile | 16:46.33 |
| | cant rememeber | 16:46.36 |
| | looks like right now it is just tiffsep_print_page | 16:48.51 |
| | That would need to be done | 16:49.15 |
| | tiffscaled already has it but has no spot support | 16:49.41 |
| | likely that it is easiest to extend the tiffsep1 device | 16:50.19 |
| | to do the post render and to make a variant that uses tags | 16:50.38 |
| | then you or someone would need to do the halftone part | 16:50.50 |
| | Not sure how it will look...... | 16:51.43 |
| | It would be straight forward to do the same in tiffsep1 | 17:06.00 |
| | on the contone data before hafltone | 17:06.10 |
| | off to work on mupdf color management | 17:06.42 |
| | sure | 17:17.20 |
| ray_laptop | there may be other stuff passed through those params (that structure) that I never looked at | 17:59.25 |
| mvrhel_laptop | ray_laptop: yes the SSE2 stuff would be good to use. We would probably need some hybrid approach though. i.e.only use the SSE2 call if the whole chunk that is getting done by the SSE2 parallel operation is all the same tag | 18:07.04 |
| | hmm actually no | 18:07.28 |
| | that should not be too hard | 18:07.32 |
| | just a matter of indexing in the correct screen | 18:07.41 |
| | so never mind what I had said I think it could readily be done | 18:07.56 |
| | the SSE2 stuff would work on x86 or x64 | 18:09.00 |
| | back to the cmm salt mine | 18:09.52 |
| | nice | 18:23.15 |
| | hmm he is not even on the channel | 18:36.44 |
| | nice | 18:37.52 |
| | if you are using tiffsep it should be ok. | 18:39.16 |
| | yes | 18:39.33 |
| ray_laptop | and does the input use GL2 or just RTL? A lot of RTL comes from people trying to drive HP inkjets and is only raster | 19:31.05 |
| | iirc, the s/w you got from CalComp (Solus product) had HP-GL/2 + RTL (but that was a monochrome product) | 19:32.21 |
| | I probably still have the s/w laying around | 19:33.22 |
| | that was the world's first embedded printer use of Ghostscript (MIPS cpu, harddrive) | 19:34.25 |
| | Alchemy was Marcos' company | 19:37.12 |
| | and yes, it used GS | 19:37.23 |
| | HenryStiles: would probably know. Been too long since I looked at any RTL | 19:44.49 |
| | APPE ? | 19:56.24 |
| HenryStiles | adobe pdf print engine | 19:56.38 |
| ray_laptop | thanks | 19:57.01 |
| | and I don't mind saying that on a public channel since I have the $$$ and time numbers to back it up :-) | 20:10.13 |
| | in case someone is wiretapping this channel ;-) | 20:10.42 |
| | I thought I'd mention that. | 20:11.29 |
| | BTW, we can always open a private chat from here | 20:11.42 |
| | ALL: ghostbot going down temporarily for maintenance. Channel will remain up | 20:19.54 |
| | Forward 1 day (to 2017/03/18)>>> | |
Log of #ghostscript at irc.freenode.net.