| | <<<Back 1 day (to 2015/04/20) | 20150421 |
| rayjj | chrisl_away: (for the logs). I opened a strange bug and dumped it on you since it seems to be memory related. Feel free to dump it on someone else. It shouldn't be possible for us to cause memory issues from PS. I discovered it by accident | 04:51.46 |
| | is it really that quiet, or is ghostbot asleep ? | 14:07.21 |
| kens | ...tumbleweeds..... | 14:07.31 |
| Robin_Watts | rayjj: it's that quiet. | 14:07.49 |
| henrys | ghostdocs is humming along ! | 14:08.20 |
| rayjj | hates skype, so I usually don't have it running | 14:08.43 |
| kens | Oh, nearly meeting time, best I fetch some coffee | 14:09.31 |
| rayjj | chrisl_away: fast work on bug 695952 | 14:17.12 |
| chrisl | rayjj: as long as that *was* the problem you saw - I fixed the problem I saw. | 14:17.37 |
| rayjj | I'll retry my tests locally with your patch | 14:18.08 |
| Robin_Watts | henrys: Do you need anything for the newsletter? | 14:20.14 |
| | (actually, maybe that's a meeting question. I'll shut up for 12 mins0 | 14:20.26 |
| henrys | Robin_Watts: yeah I had a few meeting items about that. | 14:20.56 |
| rayjj | chrisl: it fixes both of the tests I had running (with and without the -Z@$?) | 14:22.05 |
| chrisl | rayjj: Excellent! | 14:22.17 |
| rayjj | mvrhel_laptop: the remaining issue with 7.6.4 is applying the transfer function to the areas where it was turned off due to one of the conditions. When there is a transparency group, I could apply it to all non-zero opacity areas in the tos when blending to the nos | 14:26.38 |
| henrys | I got this gmail plugin that searches everywhere for people's pictures and short bios it's looks on linkedin and places like that. Each email I see the sender's pictures. Not sure if I like it. | 14:27.32 |
| rayjj | mvrhel_laptop: this would work OK for groups that set the BM or SMask or CA/ca, but changes within the group would not work with this | 14:27.49 |
| mvrhel_laptop | morning | 14:28.22 |
| rayjj | henrys: for the person sending you the email ? | 14:28.28 |
| chrisl | henrys: that sounds horrible!! | 14:28.31 |
| rayjj | mvrhel_laptop: oh, good morning :-) | 14:28.39 |
| henrys | chrisl: yea I think it is. | 14:29.11 |
| rayjj | henrys: I'll make sure and not try that plugin | 14:29.29 |
| henrys | funny rayjj should mention skype I have had a complete turnaround on this and think we should have the meetings on skype. To discuss customers and speak more freely. Thoughts? | 14:32.07 |
| mvrhel_laptop | rayjj: I will need to think about the transfer function some and how what you describe would work with the multiple nested groups. | 14:32.20 |
| kens | I'd rather not | 14:32.22 |
| chrisl | doesn't like skype :-( | 14:32.28 |
| mvrhel_laptop | I am fine either way | 14:32.49 |
| henrys | The big news is we have a new VP of Marketing Ted Simon - if he comes around say hi... I'm not sure if that means we have 2 VP's of marketing or if Scott is now VP of Sales. That part of the company looks a little top heavy to me. | 14:33.44 |
| rayjj | mvrhel_laptop: with nested groups, once you are in a group that has a condition that has you turn off the transfer function, it stays in force for all nested groups (per the spec) | 14:33.46 |
| mvrhel_laptop | henrys: wow that is big news | 14:34.01 |
| kens | Will we meet him and fred in SFO ? | 14:34.12 |
| mvrhel_laptop | rayjj: ok. I have to go back and read it. | 14:34.22 |
| jogux | henrys: does that mean appstore descriptions, screenshots, videos, etc are no longer our problem? :-) | 14:34.43 |
| henrys | he will be in SFO, his mission is to help with Mobile stuff... | 14:34.49 |
| rayjj | mvrhel_laptop: I have the nesting working, AFAICT (all in the PDF interp in PS) | 14:34.53 |
| mvrhel_laptop | ok | 14:35.03 |
| henrys | jogux: I would say no. | 14:35.27 |
| rayjj | mvrhel_laptop: and I've tested it with fts_09_0913 and 0914 and tweaked those to add in transparency (ca/CA 0.5) at various stages to make sure the Q reverts properly | 14:36.22 |
| mvrhel_laptop | rayjj: sounds great | 14:36.36 |
| rayjj | mvrhel_laptop: BTW, I also fixed TRDefault to work with colortransfer | 14:36.54 |
| jogux | henrys: darn :) | 14:37.01 |
| rayjj | jogux: it probably just means we will get more requests from him to provide stuff :-/ | 14:37.36 |
| henrys | Robin_Watts: yeah so about the newsletter I wanted to pass on the mupdf vs gs twiki but I'm not really happy with it as an end user document. I find it confusiing that if I poke at one of the underlined words I don't go to a link, but I get an authentication. Is there some way to make this thing more like an "expected" web page? | 14:38.30 |
| Robin_Watts | henrys: Well, we can drag the text out into a word doc? :) | 14:39.07 |
| mvrhel_laptop | henrys: any chance we can squeeze gsview beta into the news letter? I think it is ready to go | 14:39.35 |
| Robin_Watts | or we can edit it so that the underlined words (wikiwords) do what you want. | 14:39.36 |
| rayjj | henrys: I also found the auto-linking of things like mupdf or GhostScript to be confusing (since they don't go anywhere useful) | 14:39.53 |
| henrys | rayjj: that's exactly what I meant. | 14:40.10 |
| rayjj | Robin_Watts: if anything, they should probably go to the home page for the product | 14:40.21 |
| tor8 | henrys: skype? I'd rather we hosted our own private IRC server in that case. | 14:40.33 |
| henrys | and the minor nit that Ghostscript does not have a capitol medial 'S' like PostScript. | 14:40.52 |
| Robin_Watts | rayjj: By default any word LikeThis is interpreted as a Wiki word - i.e. a link within the wiki. | 14:41.04 |
| rayjj | henrys: I think we have a majority hating skype | 14:41.06 |
| jogux | henrys: slack might be worth looking at as an alternative | 14:41.11 |
| tor8 | is it possible to pay to remove the ad banners in skype at least? | 14:41.26 |
| Robin_Watts | Now, you can do explicit links by putting [[MuPDF][http://www.mupdf.com/] | 14:41.35 |
| jogux | OS X skype seems not to have ad banner | 14:41.38 |
| henrys | mvrhel_laptop: oh well last time miles told me he got a write up from you about gsview so I assumed ... but I'm happy to do it this time if you want. | 14:42.04 |
| rayjj | Robin_Watts: yes, thanks for telling me that. That's why I changed Ghostscript to GhostScript so it would be highlighted the same as MuPDF | 14:42.07 |
| mvrhel_laptop | should Ghostscript have a capital S? Its not that way on our web site | 14:42.12 |
| tor8 | jogux: I run skype in a quarantined^Wvirtualbox windows xp install | 14:42.24 |
| | jogux: and I expect it's only a matter of time until OSX also gets the ad banners | 14:42.36 |
| mvrhel_laptop | oh I don't recall doing a write up about gsview | 14:42.40 |
| rayjj | mvrhel_laptop: see above (I did it because MuPDF was highlighted and Ghostscript wasn't) | 14:42.46 |
| henrys | mvrhel_laptop, rayjj It should not have a capital S | 14:42.47 |
| Robin_Watts | tor8: You can remove the ads in skype without paying, according to a quick google search. | 14:42.50 |
| mvrhel_laptop | ok | 14:42.51 |
| tor8 | Robin_Watts: I looked for a way to remove them last time I had to log in to skype, but found no way to do so | 14:43.20 |
| rayjj | I'd rather we just turned off the auto wiki word stuff, and put in explicit links where we want | 14:43.30 |
| Robin_Watts | henrys: When I wrote the document, MuPDF got underlined because the wiki thought it was wikiword. | 14:43.32 |
| henrys | If there is lots of objection to quickly jumping over to skype for the meeeting, no big deal. | 14:43.40 |
| | s/is/are/ | 14:43.55 |
| Robin_Watts | Ray then thought it was unfair that MuPDF was underlined and gs wasn't, and so moved from Ghostscript to GhostScript. | 14:43.55 |
| | tor8: I suspect it involves hackery :) | 14:44.09 |
| rayjj | my Windows Skype client doesn't have ads, but then, I am a paying customer (for my Skype in phone #) | 14:44.13 |
| henrys | not a battle I'm willing to engage in ;-) | 14:44.14 |
| mvrhel_laptop | I don't have any ads | 14:44.19 |
| jogux | henrys: does http://twiki.ghostscript.com/do/view/Ghostscript/GhostscriptOrMuPDF?cover=print look better? | 14:44.30 |
| kens | never uses Skype and so has no idfea about ads | 14:44.37 |
| henrys | jogux: the problem is click on PostScript. I don't have problem with the appearance. | 14:45.23 |
| tor8 | Robin_Watts: yeah, /etc/hosts hackery... | 14:45.39 |
| mvrhel_laptop | I would vote for color to be spelled the American fashion | 14:45.40 |
| jogux | henry: ah. Just put a "!" before things we don't want to be links IIRC. | 14:45.52 |
| | s/links/wikiwords/ | 14:45.56 |
| rayjj | Robin_Watts: can't we just get rid of all the wikiword nonsense ? | 14:46.07 |
| Robin_Watts | mvrhel_laptop: Yes, fair enough. | 14:46.09 |
| henrys | jogux: okay super | 14:46.21 |
| Robin_Watts | rayjj: Not without losing the entire benefit of actually using a Wiki :) | 14:46.34 |
| | Sticking !'s in seems reasonable. | 14:46.44 |
| rayjj | jogux: so if I do !PostScript it still looks like just PostScript, but without the link and highlighting ? | 14:46.47 |
| Robin_Watts | I'll do that now. | 14:46.48 |
| jogux | rayjj: correct | 14:47.14 |
| henrys | Robin_Watts: can you search and replace the 'S' with 's' also. | 14:47.26 |
| | ? | 14:47.27 |
| Robin_Watts | no I won't, cos jogux is editing the doc. | 14:47.30 |
| | I will do when I can get in. | 14:47.36 |
| jogux | I'm not really, just go ahead. | 14:47.38 |
| tor8 | Robin_Watts: and the /etc/hosts hackery gets rid of the ad, but not the HUMONGOUS banner space | 14:47.43 |
| jogux | Robin_Watts: I've cancelled my edit now. | 14:47.50 |
| henrys | mvrhel_laptop: so I'll just add a few words about gsview. Did you try epub in gsview? | 14:47.57 |
| rayjj | Robin_Watts: and an explicit link for Ghostscript and MuPDF in the intro paragraph (not everywhere) and as henrys said change GhostScript to Ghostscript | 14:47.59 |
| jogux | Robin_Watts: wasn't really editting, just didn't know how else to get to the formatting documentation :-) | 14:48.04 |
| mvrhel_laptop | yes. epub works great in gsview | 14:48.09 |
| rayjj | Robin_Watts: do you want to do the fix up, or should I ? (I don't have to be involved in the next meeting) | 14:48.39 |
| henrys | tor8: I need the beta epub compatibility version for the viewer in the release? | 14:48.53 |
| Robin_Watts | rayjj: I'll take a run at it. | 14:48.54 |
| rayjj | Robin_Watts: OK. | 14:49.01 |
| mvrhel_laptop | chrisl: you have the keys to the gsview website. The windows installer is in ~mvrhel/gsview. I think Fred is pretty much ready too but it may be another day last I talked to him (which was Friday) | 14:51.10 |
| tor8 | henrys: uhm, could you rephrase that? I don't understand what you're asking. | 14:51.22 |
| henrys | mvrhel_laptop: okay so I'll hum a few bars about gsview in the newsletter, but it should be up there before it goes out. | 14:51.28 |
| | tor8: what version of epub are you emulating? | 14:51.45 |
| chrisl | mvrhel_laptop: okay, just let me know | 14:51.51 |
| mvrhel_laptop | henrys: yes I agree. Windows is ready. | 14:51.54 |
| tor8 | henrys: right. we support EPUB 2.0, but far from completely. | 14:52.02 |
| mvrhel_laptop | let me ping fred hold on | 14:52.07 |
| henrys | mvrhel_laptop: fred is out today but hopefully tomorrow? | 14:52.20 |
| tor8 | should be enough for a lot of books, but there are many features still missing. | 14:52.21 |
| | s/a lot of/most/ | 14:52.39 |
| rayjj | henrys: specifically, *not* 3 (except for the patches Tor made to tolerate some 3 differences) | 14:52.47 |
| mvrhel_laptop | henrys: ah ok | 14:52.51 |
| | henrys: when is the newsletter going out? | 14:53.29 |
| henrys | mvrhel_laptop: it's supposed to go today but I can hold it up. | 14:53.47 |
| mvrhel_laptop | ok thanks. | 14:53.56 |
| rayjj | I was amused by the guy that asked if we were doing a browser since we had html parsing, javascript, curl and other parts | 14:54.23 |
| chrisl | We can put up the Windows gsview, and say in the newsletter the OSX/Linux one to follow shortly | 14:54.24 |
| henrys | chrisl: that's be fine by me. mvrhel_laptop ? | 14:55.05 |
| mvrhel_laptop | I am fine with that if you want to move forward | 14:55.09 |
| henrys | that was my list for the gs/mupdf meeting. Anybody want to add? | 14:56.27 |
| | Robin_Watts: I'll create a bug for that path problem with duplicate operations after the meeting so we don't forget. | 14:57.22 |
| Robin_Watts | henrys: not a bug. not a bug. not a bug. | 14:57.37 |
| henrys | Robin_Watts: oh great. | 14:57.54 |
| Robin_Watts | It's just down to the way different stroking modes work. | 14:58.12 |
| henrys | Robin_Watts: so we aren't using more memory space for those paths? | 14:58.42 |
| mvrhel_laptop | henrys: I am going to be working on 695929 this week. Marcos told the customer it should be easy, but anything in the SSE2 halftone stuff is not going to be quick | 14:58.50 |
| Robin_Watts | henrys: absolutely not. | 14:58.51 |
| | http://twiki.ghostscript.com/do/view/Ghostscript/GhostscriptOrMuPDF?cover=print | 14:59.26 |
| rayjj | mvrhel_laptop: Does it work without the SSE2 (just the C code) ? | 14:59.30 |
| marcosw | I said "relatively easy" :-) | 14:59.38 |
| chrisl | mvrhel_laptop: there's no tag in the gsview repo for the beta release...... | 15:00.22 |
| henrys | mvrhel_laptop: and we can't pull the commit because it was an enhancement for whom? see that we need skype. | 15:00.48 |
| rayjj | Robin_Watts: do you mind if I add in the links to the product home pages on Ghostscript and MuPDF in the first sentence ? | 15:01.00 |
| Robin_Watts | rayjj: Use the linking thing [[blah][url]] | 15:01.29 |
| rayjj | Robin_Watts: OK. | 15:01.47 |
| Robin_Watts | actually, let me. | 15:01.47 |
| rayjj | Robin_Watts: OK | 15:01.54 |
| mvrhel_laptop | rayjj: I have not looked at it yet. just getting started | 15:02.15 |
| | chrisl: I was just about to tag it | 15:02.25 |
| chrisl | mvrhel_laptop: What's the earliest version of Windows gsview will run on? | 15:04.49 |
| Robin_Watts | rayjj: I had that the wrong way round. it's [[http://www.ghostscript.com][Ghostscript]] | 15:04.53 |
| | But have a look now. | 15:04.58 |
| mvrhel_laptop | chrisl: vista. although I have not tried it. I have a vista laptop here that I will try | 15:05.23 |
| chrisl | Ta | 15:05.34 |
| kens | Robin_Watts : there's a twiki link MuPDF under the Porting paragraph | 15:06.02 |
| | THe second mention there | 15:06.08 |
| henrys | mvrhel_laptop and all: let's start thinking about gsview on other platforms, should we be thinking about replacing the mupdf viewer? | 15:06.14 |
| rayjj | Robin_Watts: thanks. Looks good. | 15:06.16 |
| Robin_Watts | and DeviceN. | 15:06.17 |
| mvrhel_laptop | chrisl: now it should be tagged | 15:07.11 |
| henrys | off to skypeland! | 15:07.47 |
| Robin_Watts | kens: Fixed, I hope. | 15:07.54 |
| mvrhel_laptop | chrisl: hmm maybe not | 15:08.02 |
| chrisl | mvrhel_laptop: it looks like you haven't push it - you need to "git push --tags" | 15:08.06 |
| kens | Yes looks OK to me now Robin | 15:08.07 |
| Robin_Watts | henrys: IMHO, no, we should not replace the current mupdf viewer. | 15:08.11 |
| mvrhel_laptop | chrisl: ah. thanks | 15:08.17 |
| | hold on | 15:08.18 |
| Robin_Watts | We should absolutely point people towards GSView, but there will be lots of people that want the existing 'cut down' viewer. | 15:08.35 |
| mvrhel_laptop | chrisl: ok now its there | 15:09.01 |
| Robin_Watts | because it's extremely attractive to a certain class of user (no extra UI, no wasted screen space etc) | 15:09.07 |
| rayjj | the existing mupdf viewer is also a good example for those that want to get started doing a viewer | 15:09.18 |
| kens | And smaller, whch may be important on mobile devices | 15:09.23 |
| rayjj | kens: right. Since gsview includes gs, it's pretty bloated by comparison | 15:10.08 |
| kens | Exactly | 15:10.14 |
| | Looks like ~27 Mb on WIndows | 15:10.25 |
| Robin_Watts | GSView is a much more polished experience though. | 15:10.51 |
| | I think they complement one another nicely. | 15:10.58 |
| kens | I guess it depends what you want | 15:11.02 |
| rayjj | the download I just did of the gsview_setup_6.0.exe was 25,127 Kb | 15:11.17 |
| kens | I assume thaqt's compressed, I was adding up the binary files | 15:11.34 |
| Robin_Watts | Alas MuPDF will not fit on a floppy any more :) | 15:11.40 |
| mvrhel_laptop | rayjj: that is the installer | 15:14.45 |
| chrisl | GSview is now available for download. I'll revamp the page during the next week or so, so it fits better with the gs and mupdf sites | 15:14.55 |
| mvrhel_laptop | which includes dlls for mupdf and gs both 32 bit and 64 bit | 15:14.58 |
| | they are not all installed | 15:15.03 |
| | 31 meg installed... | 15:15.45 |
| | ;) | 15:15.48 |
| | gs is 14 of that | 15:15.59 |
| | mpdf stuff is 10 of it | 15:16.17 |
| | the viewer exe is 2 | 15:16.34 |
| rupert | hi does anyone have any documentation on building for windows 8.1? | 15:23.06 |
| kens | Building what ? | 15:23.17 |
| rupert | mupdf | 15:23.27 |
| kens | AFAIK it works | 15:23.49 |
| Robin_Watts | You can build the standard desktop viewer for windows 8.1 just using the normal supplied VS solution. | 15:23.58 |
| | If you want something that runs in the tiled mode, we don't supply that. | 15:24.19 |
| | but it's perfectly possible to write your own mupdf based viewer. | 15:24.31 |
| | Does GSView work in the tiled mode, mvrhel_laptop ? | 15:24.58 |
| rupert | so if i open /platform/windows/mupdf.sln | 15:25.01 |
| mvrhel_laptop | Robin_Watts: I need to add a tile mode | 15:25.11 |
| rupert | and build the solution | 15:25.13 |
| | that should be sufficient? | 15:25.24 |
| Robin_Watts | rupert: It should. | 15:25.45 |
| rayjj | mvrhel_laptop: chrisl: I just installed the gsview from mvrhel's account and it seems to have 9.18 PRE-RELEASE instead of 9.16 gs DLL in it | 15:27.12 |
| mvrhel_laptop | it has the lastest update of gs | 15:27.44 |
| | and mupdf | 15:27.57 |
| rayjj | IMHO, we should have it using a release of gs (and mupdf), not some who-knows-which version. | 15:28.40 |
| mvrhel_laptop | then I suppose I should greab 9.17 | 15:29.42 |
| rayjj | mvrhel_laptop: for the feature list, when we do the 'distill' of PS to get the PDF, it would be nice to be able to view the log from gs (as Acrobat allows) | 15:29.54 |
| kens | Hmm, 9.17 is a commercial release | 15:29.58 |
| rayjj | mvrhel_laptop: 9.16 is the AGPL release | 15:30.11 |
| | mvrhel_laptop: and the recent release of mupdf (1.?) | 15:30.43 |
| mvrhel_laptop | 1.7 | 15:30.51 |
| | rayjj: I think you can view the log | 15:31.08 |
| | go to file->show messages | 15:31.23 |
| rayjj | mvrhel_laptop: just found it. I hadn't looked everywhere. Thanks | 15:32.05 |
| Robin_Watts | rayjj: I think it's absolutely fine for mvrhel to use whatever version of gs or mupdf he wants. | 15:32.14 |
| | As long as he tags the gsview repo for each release, the wonder of git submodules will completely specify the versions of gs and mupdf in use. | 15:32.53 |
| rayjj | Robin_Watts: for support purposes, it's hard to figure out | 15:32.58 |
| chrisl | Why do we bother doing releases.....? | 15:33.17 |
| Robin_Watts | rayjj: No, it's not. He gets told the gsview version, and everything else follows from that. | 15:33.18 |
| mvrhel_laptop | well, it will not be much different than getting a bug now and testing if if works with the latest version to be honest | 15:33.34 |
| rayjj | Robin_Watts: and the whole point of our prior to release test cycle is to not have some potentially unstable intermediate version | 15:33.53 |
| henrys | mvrhel_laptop, rayjj : so what is the problem with GSView being targetted at ios and android. Why would we want to continue development of two viewers? | 15:34.07 |
| | I said rayjj and I meant Robin_Watts | 15:35.00 |
| Robin_Watts | henrys: There is a voiciferous group of users who would consider gsview to be a step backwards. | 15:35.12 |
| rayjj | henrys: I don't have a problem with also having gsview for android and/or iOS. But as several have pointed out, gsview is quite a bit more bloated | 15:35.26 |
| mvrhel_laptop | henrys: I am thinking of gsview as eventually being more like acrobat | 15:35.31 |
| Robin_Watts | linux users mostly. | 15:35.32 |
| chrisl | And Android users | 15:35.49 |
| mvrhel_laptop | I think having a light weight view only app for the mobile devices is a good idea | 15:36.26 |
| Robin_Watts | I'm not proposing we should actively push ahead with development of the existing linux/windows viewer. | 15:36.27 |
| | Just that we don't remove it from the distro. | 15:36.44 |
| henrys | Robin_Watts, mvrhel_laptop one of the problems I was hoping to have addressed before chicago was being able to view high end graphics - remember gs processes CMYK and mupdf to view? | 15:36.50 |
| rayjj | Robin_Watts: you mean adding more features to mupdf? If so, I agree. It's pretty much fine the way it is | 15:37.05 |
| Robin_Watts | rayjj: exactly feature freeze, pretty much. | 15:37.19 |
| henrys | on mobile devices. | 15:37.22 |
| Robin_Watts | henrys: Now, gsview for android is a whole new ballgame. | 15:37.52 |
| mvrhel_laptop | henrys: yes. I can probably get something like that up for windows mobile but I fear I would be slow getting it for the other platforms. But maybe not | 15:37.58 |
| Robin_Watts | If we wanted a gsview for android, I'm not sure I'd start from a gsview for .net | 15:38.36 |
| mvrhel_laptop | hehe no. we would want to work with the current viewer code base for android and to an interface to gs to do distilling and other conversions | 15:39.11 |
| henrys | Robin_Watts: it isn't just .net we have qt, I was assuming we could incorporate other UI frameworks as well. | 15:39.42 |
| Robin_Watts | possibly we might want to make use of michaels cpp classes that sit atop of mupdf - in the same way that I believe fred has done. | 15:39.45 |
| rayjj | henrys: the problem with CMYK (at least as far as overprint) is that mupdf doesn't do it, so converting a PS file to PDF and using mupdf, the overprint is ignored. The only way that would work is if the rendering were done by gs and the viewer just has a bitmap | 15:39.57 |
| mvrhel_laptop | yes that would make sense what Robin_Watts said | 15:40.04 |
| Robin_Watts | henrys: Right. That's the cpp classes that I just mentioned. | 15:40.13 |
| henrys | rayjj: we are going to create tiffs from gs and have mupdf view them. | 15:40.31 |
| mvrhel_laptop | henrys right | 15:40.41 |
| Robin_Watts | henrys: Well, if that's all you want, that can be bolted onto the existing mupdf for android viewer. | 15:40.58 |
| mvrhel_laptop | for color proofing this would work fine | 15:41.05 |
| rayjj | henrys: we would only want to do that if they wanted "Simulate Overprint". Otherwise it'll be a lot slower manipulating a large TIFF image | 15:41.32 |
| | henrys: or color proofing or some other special thing | 15:41.55 |
| Robin_Watts | Can we not use gs to process things to a pdf with RGB only? | 15:41.56 |
| | so transparency/overprint etc would be baked in as a bitmap ? | 15:42.13 |
| mvrhel_laptop | rayjj: "proofing mode" will be understood to be slower | 15:42.18 |
| rayjj | Robin_Watts: but then you still lose overprint, and can't color proof | 15:42.27 |
| henrys | Robin_Watts: the previous agreement was gs would generate a tiff I don't see it makes much difference if it's an RGB pdf. | 15:42.56 |
| Robin_Watts | rayjj: I was hoping that overprint would be baked in to the bitmaps. | 15:43.03 |
| mvrhel_laptop | yes. unfortunately we really need to go to a bit map. would could go to rgb or cmyk | 15:43.10 |
| | it will be backed into the bitmaps | 15:43.21 |
| Robin_Watts | henrys: I already have a version of MuPDF for android that pulls .doc files in, calls an exe on them to make them into pdf and then views the pdf. | 15:43.37 |
| henrys | Didn't we choose CMYk tiffs last time? | 15:43.44 |
| rayjj | mvrhel_laptop: how do you decide what res (size) to use for the bitmap ? | 15:43.45 |
| Robin_Watts | Hence it would be trivial to change that to pull a .pdf in, feed it through gs to make a new pdf and then view that. | 15:44.12 |
| mvrhel_laptop | henrys: we talked about that. but we could make a device that converted to rgb at the end. not much advantage of it. The easiest route is to use the tiffsep device and to get the composite cmyk tiff image | 15:44.46 |
| Robin_Watts | hence if we can get gs to bake in the overprint simulation and the color proofing, we're there. | 15:44.51 |
| mvrhel_laptop | rayjj: you render it to the size based upon the resolution of the display device and the zoom value. | 15:45.09 |
| rayjj | Robin_Watts: but if the new PDF is RGB ProcessColorModel, overprint will be ignored during the conversion. Same as viewing the original PDF directly with mupdf | 15:45.19 |
| mvrhel_laptop | no different than mupdf "decides" | 15:45.21 |
| henrys | mvrhel_laptop: yeah last we talked about it I thought the tiffsep seemed the most straightforward. | 15:45.25 |
| rayjj | mvrhel_laptop: so every time you change scale factor, you re-render the TIFF ? | 15:45.51 |
| mvrhel_laptop | rayjj: yes | 15:45.56 |
| Robin_Watts | mvrhel_laptop: Urgh. | 15:46.09 |
| mvrhel_laptop | I see no other way | 15:46.15 |
| henrys | mvrhel_laptop, Robin_Watts : but it's not just that feature it would be nice to have one viewer why would the ios and android version have to be any more bloated than what we have? | 15:46.29 |
| rupert | i have built the mupdf VS solution file which built fine | 15:46.43 |
| rayjj | henrys: I think we need an option for tiffsep that doesn't write the separation files -- just the CMYK | 15:46.44 |
| mvrhel_laptop | mupdf has to rerender with scale changes | 15:46.49 |
| | why would gs not have to? | 15:47.01 |
| henrys | rayjj, mvrhel_laptop perfectly reasonable for high quality preview. | 15:47.04 |
| Robin_Watts | mvrhel_laptop: Well, not necessarily. | 15:47.10 |
| rupert | when i attempt to run the project gsview i get DllNotFoundException:MuPDF DLL not found 11 | 15:47.23 |
| | not found 1* | 15:47.31 |
| Robin_Watts | rupert: What solution file did you build? | 15:47.40 |
| | platform/win32/mupdf.sln ? | 15:47.46 |
| rupert | i build platform/windows/mupdf.sln | 15:48.13 |
| mvrhel_laptop | I thought that was removed | 15:48.21 |
| Robin_Watts | rupert: Don't build that file. | 15:48.25 |
| | rupert: Please use the latest version of MuPDF, 1.7. | 15:48.35 |
| rupert | ok ill try again | 15:49.00 |
| rayjj | mvrhel_laptop: I didn't know if you would render with gs to something like 4x current zoom, then display the scaled down size so that zoom up to 4x would not require re-render. Bigger bitmaps, but more responsive. | 15:49.12 |
| mvrhel_laptop | rayjj: that would make sense | 15:49.26 |
| Robin_Watts | henrys: In order to do color proofing, MuPDF needs to be fed RGB bitmaps that are color adjusted for the current screen. | 15:49.45 |
| rayjj | mvrhel_laptop: but that's up to whoever is doing it | 15:49.49 |
| Robin_Watts | If you give MuPDF CMYK bitmaps, it'll do a quickish-and-not-too-dirty conversion to RGB, which will screw color correctness. | 15:50.21 |
| mvrhel_laptop | Robin_Watts: what does mupdf do with cmyk tiff images? | 15:50.28 |
| | too slow | 15:50.33 |
| Robin_Watts | :) | 15:50.36 |
| mvrhel_laptop | ick | 15:50.39 |
| | ok. In that case, we fixe that | 15:50.47 |
| Robin_Watts | mvrhel_laptop: fix that how? | 15:51.00 |
| | Adding optional color management to mupdf has been a todo thing for ages. | 15:51.29 |
| henrys | Robin_Watts: I don't think anyone would prepress proof on an iphone, it's just a preview. But maybe I'm mistaken. | 15:51.31 |
| mvrhel_laptop | we need to do some color mangement in the application which will allow the setting of the display profile, and apply the profile in this case to the the incoming tiff image | 15:51.32 |
| | Robin_Watts: not in all of mupdf just this part | 15:51.46 |
| rayjj | mvrhel_laptop: once I get my enhancement to do simulate overprint to RGB devices, (using the pdf14 compositor as we discussed) then gs can produce an RGB that has overprint | 15:51.56 |
| rupert | theres no windows folder in 1.7 do i use win32? | 15:51.57 |
| Robin_Watts | rupert: Yes.# | 15:52.04 |
| mvrhel_laptop | oh | 15:52.25 |
| | actually this is easy | 15:52.28 |
| rayjj | mvrhel_laptop: I've started on that, so if Len doesn't hit me with more stuff, I may actually make progress | 15:52.49 |
| Robin_Watts | MuPDF decompresses images 'lazily', remember. | 15:52.56 |
| rayjj | mvrhel_laptop: what's easy ? | 15:52.58 |
| henrys | for now we have plenty to do, it's on the agenda and we'll talk some more about it later. | 15:53.08 |
| rayjj | Robin_Watts: what does "decompress lazily" mean ? | 15:53.32 |
| mvrhel_laptop | I am thinking that we have gs do the heavy lifting of all the color management and I add an option of tiffsep to create a color managed rgb composite tiff output for a given proof profile | 15:53.35 |
| | then we can hand gs the mobile device profile and the image is done | 15:53.48 |
| Robin_Watts | rayjj: It means we don't decompress an image until we're actually about to render it. | 15:53.52 |
| | It's in the display list compressed. | 15:54.05 |
| | mvrhel_laptop: That would be good. | 15:54.13 |
| rayjj | Robin_Watts: but if gs creates one big image, that doesn't help | 15:54.15 |
| Robin_Watts | rayjj: Does too, cos we decimate as we decompress. | 15:54.43 |
| rayjj | so for the viewer, a device that created tiles of images would be best, right ? | 15:54.55 |
| Robin_Watts | mvrhel_laptop: That's what I was hoping for, but not in the tiffsep device. | 15:55.01 |
| rayjj | a gs device, that is | 15:55.04 |
| henrys | sounds like rupert's issue should be fixed in the installation at least a warning 1.7 is required no? | 15:55.06 |
| Robin_Watts | I was hoping we could do that in in the pdfwrite device. | 15:55.24 |
| mvrhel_laptop | Robin_Watts: I see | 15:55.33 |
| Robin_Watts | henrys: What? | 15:55.41 |
| | ruperts issue is "trying to build a project that's not there anymore". | 15:56.25 |
| rayjj | Robin_Watts: it has to be a rendering device, not a high level device, so that overprint and color management get applied | 15:56.27 |
| Robin_Watts | rayjj: Right. I hadn't appreciated that. | 15:56.49 |
| henrys | Robin_Watts: oh nvm I'm confused. | 15:56.58 |
| rayjj | Robin_Watts: but doing a device that does separations, applies profiles, and emits a PDF as tiled RGB images might be in order | 15:57.17 |
| Robin_Watts | So... one possibility... Run gs to produce cmyk tiffs. Then run gs again to take those tiffs into an RGB pdf | 15:57.18 |
| rupert | Robin_Watts: i have built the win32 version, i can run mupdf which prmpts me to select a pdf which is displayed, how or what do i need to do to get this library into a windows 8.1 app? | 15:57.20 |
| mvrhel_laptop | Robin_Watts: so you want an RGB image wrapped up in the pdf? | 15:57.41 |
| Robin_Watts | mvrhel_laptop: Yes. | 15:57.49 |
| rayjj | Robin_Watts: that would be *really* inefficient | 15:57.50 |
| | mvrhel_laptop: tiled RGB images would let mupdf ignore tiles off the page when zoomed in | 15:58.13 |
| mvrhel_laptop | right | 15:58.27 |
| Robin_Watts | rayjj: tiling the images would indeed be preferably. | 15:58.28 |
| rayjj | s/off the page/out of the current viewport/ | 15:58.35 |
| Robin_Watts | preferable. | 15:58.38 |
| chrisl | Robin_Watts: won't that cause artifacts due to the anti-aliasing? | 15:59.07 |
| Robin_Watts | rupert: Right the way back when you first arrived and asked questions, I told you that we didn't supply a solution for building tiled mode apps. | 15:59.22 |
| | I told you we did provide a viewer that would run in the desktop mode. | 15:59.43 |
| | I have been answering your questions on that basis ever since. | 15:59.54 |
| rayjj | I have to run an errand. bbiaw | 16:00.18 |
| Robin_Watts | chrisl: Why should it? If all the overprint etc has been resolved to bitmaps before we load it, I fail to see why anti-aliasing should be an issue. | 16:00.47 |
| mvrhel_laptop | so in the short term, I would suggest that we do the tiffsep rgb color managed composite output from gs and have mupdf use that | 16:00.52 |
| | we can later look at doing some more efficient image forms in stage 2 | 16:01.10 |
| rayjj | mvrhel_laptop: and *not* generate the sep files -- just the final RGB image | 16:01.25 |
| mvrhel_laptop | rayjj: yes, just what we need | 16:01.38 |
| Robin_Watts | mvrhel_laptop: Right. That will require a new document handler in mupdf to read multiple tiff files as input. | 16:01.49 |
| | That's not that hard to do. | 16:01.58 |
| chrisl | Robin_Watts: I thought there was an issue where two images butt up or overlap caused an oddity with the aa rendering | 16:02.07 |
| Robin_Watts | chrisl: Oh, yes, I see. | 16:02.24 |
| rayjj | Robin_Watts: it doesn't have to be TIFF -- they can be PNG's just as well | 16:02.27 |
| | they are just RGB at that point | 16:02.41 |
| Robin_Watts | There are issues, but I think we avoid those for axis aligned images by expanding them to fill whole pixels. | 16:02.48 |
| mvrhel_laptop | yes, we can do what ever form we want. I am wondering if this should be a different device than the tiffsep.... | 16:02.53 |
| Robin_Watts | rayjj: regardless of the input format, we'd need a new document handler. | 16:03.10 |
| | unless you want to zip them all up and call 'em a .cbz :) | 16:03.22 |
| chrisl | Robin_Watts: in reality, if there was such an issue, we just disable anti-aliasing..... | 16:03.24 |
| Robin_Watts | chrisl: yeah. | 16:03.32 |
| mvrhel_laptop | I need to grab some breakfast. | 16:03.40 |
| chrisl | Robin_Watts: I also thought about cbz, but it means waiting for the entire output to complete before displaying the first page | 16:04.16 |
| Robin_Watts | chrisl: yes. I think we'd be doing that anyway. | 16:04.43 |
| chrisl | Well, it seems TIFF is supported in cbz..... | 16:05.16 |
| Robin_Watts | chrisl: The actual cbz doc handler is pretty small; images are easy enough. | 16:05.45 |
| chrisl | Does the mupdf cbz reader support tiff? | 16:06.08 |
| Robin_Watts | chrisl: possibly :) | 16:06.23 |
| | the image handler does. | 16:06.34 |
| | It possibly even supports multiple image tiffs. | 16:06.44 |
| chrisl | I guess we could use png and not compress the zip archive | 16:07.20 |
| Robin_Watts | I suspect one cheap and cheesy way of doing this is to output a custom image format that has png compressed 'bands' for each page. | 16:07.24 |
| | That gets a similar effect to rays desired 'tiles', and is very easy for us to handle. | 16:07.59 |
| | We could probably even demand load from the file (with a bit of locking I'd need to think about). | 16:08.27 |
| henrys | it would be not to have to process the entire job in gs before mupdf starts display... | 16:10.51 |
| chrisl | I suspect performance will be an issue - the storage on mobile devices isn't known for speed | 16:11.03 |
| Robin_Watts | henrys: It would be nice to to have to process the entire job, but for a first version, it'd do. | 16:11.36 |
| | We *could* do a document handler that called gs to convert a page at a time. | 16:11.53 |
| | It all depends how complex you want to get. | 16:12.00 |
| henrys | Robin_Watts: agree | 16:12.02 |
| chrisl | So, how about the "preview" display is separate to the "normal" display. You navigate to the page "normally", and select preview for that page only. As soon as you navigate away, you drop back to "normal" display. | 16:12.55 |
| Robin_Watts | The key thing is to get data out of gs that is: 1) high enough quality that mupdf can just scale it when zoomed, 2) is color correct in rgb, 3) has simulated overprint done. | 16:13.07 |
| | chrisl: That requires hackery in the android app. | 16:13.37 |
| | but anything can be done with suitable programming. | 16:13.46 |
| kens | COuldn't we just create an RGB PDF file ? | 16:13.54 |
| Robin_Watts | kens: I started by suggesting that :) | 16:14.07 |
| chrisl | kens: does pdfwrite "flatten" overprint? | 16:14.10 |
| kens | Sorry, I've been busy | 16:14.14 |
| | chrisl, no | 16:14.18 |
| Robin_Watts | Apparently RGB PDF files wouldn't have simulated overprint in. | 16:14.24 |
| kens | Notg even if you convert to RGB | 16:14.25 |
| chrisl | So, then we'd lose overprint preview | 16:14.29 |
| kens | No, they wouldn't you're correct | 16:14.34 |
| Robin_Watts | kens: you and I were shot down in the same way :) | 16:14.44 |
| kens | Anyway, got to run off, goodnight all | 16:14.45 |
| chrisl | Not much use for a proofing app | 16:14.45 |
| | Robin_Watts: as rayjj said, if he gets the pdf14 compositor emulating overprint, pdfwrite could leverage that | 16:15.21 |
| | But whether PDF would be a sensible solution.... I don't know | 16:16.09 |
| henrys | chrisl: do you know if all the other color management stuff is ready to go in pdfwrite? The high level goal is something like process the Altona files. | 16:16.20 |
| Robin_Watts | PDF would be a sensible solution, modulo a couple of things... | 16:16.53 |
| chrisl | henrys: the ICC workflow has been the default in pdfwrite since at least last September's release | 16:17.06 |
| Robin_Watts | 1) we'd be tied to always completing the job in gs before mupdf could open. | 16:17.07 |
| | 2) we'd like pdfwrite to generate striped bitmaps rather than page sized ones, ultimately, to save memory. | 16:17.42 |
| henrys | chrisl: yeah so I think it is just overprint really. | 16:17.59 |
| | Robin_Watts: why couldn't we use %d and read them as they become available? | 16:18.55 |
| chrisl | Robin_Watts: I think the problem with producing stiped bitmaps is that the clist logic would make overlapping bands really, really hard to make | 16:18.58 |
| henrys | them == pages | 16:19.06 |
| Robin_Watts | henrys: We could do that (at the cost of more complexity in mupdf, yes) | 16:19.34 |
| | chrisl: overlapping bands? | 16:19.48 |
| chrisl | Robin_Watts: yes, you need the image strips to overlap | 16:20.06 |
| Robin_Watts | chrisl: why? | 16:20.14 |
| henrys | have to talk to kens some more the high level pdf output does sound compelling. If we can just get overprint in. | 16:20.21 |
| Robin_Watts | henrys: I was imagining that in the simulated overprint case, the pdf output would just be wrapped bitmaps. | 16:20.59 |
| | Like the flattened transparency case. | 16:21.11 |
| chrisl | Robin_Watts: because images that butt up to each other at a given resolution, may not do so at aother resolutions | 16:21.14 |
| | So, you can get 1 pixel gaps appearing | 16:21.31 |
| Robin_Watts | chrisl: urm... only if your maths goes wrong. | 16:22.05 |
| chrisl | Robin_Watts: "wrong" as in rounding errors coverting from the image coordinate space to device space | 16:22.31 |
| | s/coverting/converting | 16:22.49 |
| Robin_Watts | henrys: We could not afford to have some elements of the files handled at the high level and some as bitmaps, as otherwise we'd lose color correctness. | 16:22.55 |
| chrisl | Robin_Watts: we can have pdfwrite produce color corrected PDFs | 16:23.28 |
| Robin_Watts | chrisl: absolutely. i was relying on that. | 16:23.40 |
| | I read henrys comment (possibly incorrectly) as suggesting that he'd like the pdfs to have some high level elements in for mupdf to render. | 16:24.20 |
| | rather than being pure bitmaps. | 16:24.29 |
| | and I think that would be bad. | 16:24.40 |
| chrisl | Yes, so pdfwrite can produce vector output color corrected | 16:24.43 |
| Robin_Watts | chrisl: And when MuPDF renders that with antialiasing on top of bitmap bits? | 16:25.50 |
| chrisl | I think I would argue that proofing shouldn't use anti-aliasing.... but yes, I take your point | 16:26.31 |
| Robin_Watts | chrisl: If we don't use AA then we really must only have bitmaps. | 16:28.12 |
| | Cos mupdf doesn't obey the 'any part of a pixel' rules etc. | 16:28.28 |
| chrisl | Well, that settles that, then...... | 16:29.24 |
| henrys | unless there were some way pdfwrite would not fall back to raster but I don't see how that can be avoided. | 16:31.46 |
| chrisl | henrys: I think what Robin_Watts is saying is that the entire page much be bitmapped | 16:32.43 |
| Robin_Watts | s/much/must/ yes. | 16:32.55 |
| chrisl | But I think for emulating overprint, that would have to be case anyway | 16:33.33 |
| Robin_Watts | I like to think that we could manage to do striped bitmaps within pdfwrite without too much pain. | 16:33.47 |
| | Either by overlapping them by a pixel (which isn't that bad to do), or by ensuring that they abut correctly. | 16:34.26 |
| henrys | I guess I'm confused, if we didn't fall back to bitmaps for overprint pdf supported it somehow at the high level then we wouldn't need to have bitmaps. Right? | 16:34.48 |
| chrisl | henrys: care to put that in English?? | 16:35.19 |
| Robin_Watts | (Kens will now correct me in the logs tomorrow - I am aware that me saying that anything in pdfwrite is "not that bad" comes from a place of deep ignorance) | 16:35.34 |
| | henrys: No one has ever proposed that pdfwrite should be able to do simulated overprint at a high level. | 16:36.14 |
| henrys | that was my new proposal ;-) | 16:36.38 |
| chrisl | henrys: "flattening" overprint is basically just the same as flattening transparency - we don't do that at the vector level | 16:36.56 |
| Robin_Watts | What has been suggested, AIUI, is that if simulated overprint can be pushed into the pdf14 compositors, it can be available to more devices. So that when pdfwrite does a 'getbits' (as it currently does to output bitmap output with flattened transparency), it would get simulated overprint there too. | 16:37.38 |
| mvrhel_laptop | Robin_Watts: that is correct. that requires a little work but the pdf14 compositor could do this | 16:38.23 |
| | then all the devices can simulate overprint | 16:38.53 |
| | not sure about pdfwrite in this case. I guess we could force it to go to version 1.2 | 16:39.51 |
| | 1.3 | 16:39.53 |
| | sorry | 16:39.55 |
| henrys | but we can't preserve the vectors so we are stuck with full page bitmap. | 16:40.16 |
| mvrhel_laptop | yes. | 16:40.25 |
| Robin_Watts | henrys: or full page of striped bitmaps at least. | 16:40.35 |
| mvrhel_laptop | if mupdf is not going to support overprint there is no other way | 16:40.38 |
| chrisl | I think overprint has been in pdf from the beginning | 16:40.40 |
| mvrhel_laptop | ah ok | 16:40.45 |
| chrisl | It was an early hack at "sort of" transparency | 16:41.11 |
| henrys | okay I'm off to meeting #3 bbiab | 16:41.43 |
| mvrhel_laptop | henrys: I also need to get slides ready for open printing. doing the annual gs/mupdf review next week | 16:56.11 |
| Robin_Watts | mvrhel_laptop: Let us know if there is anything you need for the mupdf side of that. | 17:03.20 |
| mvrhel_laptop | Robin_Watts: Thanks! I can probably get everything I need from the newsletter but I may need more details and will bug you about them | 17:04.40 |
| Robin_Watts | mvrhel_laptop: So has gsview been released now? | 17:04.57 |
| mvrhel_laptop | the windows beta is up there. why did you find an issue? | 17:05.12 |
| | I just need to stop for a bit and work on the customer bugs. so we should let any gsview bugs queue up for a bit... | 17:05.59 |
| Robin_Watts | I thought chrisl said something about it "being available for download now" | 17:06.08 |
| mvrhel_laptop | Robin_Watts: it is | 17:06.13 |
| Robin_Watts | where? | 17:06.24 |
| mvrhel_laptop | gsview.com | 17:06.28 |
| Robin_Watts | http://www.ghostscript.com/GSview.html should be updated then. | 17:06.43 |
| mvrhel_laptop | oh good point | 17:06.52 |
| | chrisl is away | 17:07.04 |
| | don't know if anyone else has keeps to the web site | 17:07.44 |
| | keys | 17:07.47 |
| | can't type today | 17:07.51 |
| Robin_Watts | I do. | 17:07.56 |
| | We should make GSview.html redirect to GSView.html | 17:09.05 |
| | and then have GSView.html have some new words on. | 17:09.16 |
| mvrhel_laptop | yes good idea | 17:09.41 |
| Robin_Watts | The new words should point people to gsview.com, and acknowledge that versions of GSview below 6 were from Ghostgum. | 17:10.31 |
| mvrhel_laptop | yes. | 17:12.53 |
| Robin_Watts | mvrhel_laptop: Does GSView do JPEG, PNG, CBZ etc too? | 17:17.30 |
| mvrhel_laptop | yes | 17:22.00 |
| | Robin_Watts: I need to add printing support for these forms though | 17:22.10 |
| | in windows all printing is done through the xps path | 17:22.27 |
| | those forms need to be done a bit differently | 17:22.37 |
| | I also need to get form filling and the ability to add annotations | 17:24.38 |
| Robin_Watts | mvrhel_laptop: http://www.ghostscript.com/GSView.html | 17:24.59 |
| mvrhel_laptop | oops. no tiff I think I had not added that. but epub | 17:25.35 |
| Robin_Watts | Updated. | 17:26.38 |
| mvrhel_laptop | versions 6 and above... | 17:26.44 |
| | Russells last version was version 5 | 17:27.00 |
| | I think you need to drop the last sentence too | 17:27.18 |
| Robin_Watts | Updated again :) | 17:27.20 |
| | yes. | 17:27.26 |
| | Updated again | 17:27.47 |
| mvrhel_laptop | do we still wan the link to Russells work? | 17:28.04 |
| | is he going to provide a link to ours? | 17:28.14 |
| Robin_Watts | I'm happy to drop it. | 17:28.21 |
| mvrhel_laptop | I would drop it for now | 17:28.27 |
| Robin_Watts | ok | 17:28.31 |
| | done. | 17:28.48 |
| | now let me make GSview -> GSView | 17:28.57 |
| mvrhel_laptop | looks good | 17:28.58 |
| | the gsview.com page make me shudder but I know chris said he is going to go back and fix it up | 17:31.27 |
| Robin_Watts | mvrhel_laptop: OK,http://www.ghostscript.com should have the right links etc now. | 17:33.04 |
| mvrhel_laptop | looks good. thanks Robin_Watts | 17:33.42 |
| Robin_Watts | np. | 17:33.46 |
| mvrhel_laptop | brb | 17:40.24 |
| | marcosw: are you here? | 18:43.36 |
| marcosw | mvrhel_laptop: yes | 18:47.52 |
| mvrhel_laptop | any chance you could add a png of what you are seeing with 695929 and do you have the source image you were using | 18:49.36 |
| | I am seeing some very odd things regardless of -dDITHERPPI=90 or -dDITHERPPI=80 | 18:50.00 |
| | that I would not expect | 18:50.08 |
| | there is something weird going on here that will take a bit of time | 18:50.39 |
| | marcosw^^ | 18:50.42 |
| marcosw | I'll attach the file (thought I had) and a screenshot. | 18:50.54 |
| | I'll also email the customer and tell him my estimate of "easyish" was wrong. | 18:51.08 |
| mvrhel_laptop | at normal resolutions e.g. 600 things look good | 18:51.08 |
| | for 90 or 80 | 18:51.19 |
| | but this hyper resolution of 1680 things get odd | 18:51.32 |
| | off to lunch now. bbiaw | 18:51.41 |
| marcosw | lunch for me as well. | 18:52.46 |
| fredross-perry | are we releasing mac/linux gsview as well? | 19:53.54 |
| Robin_Watts | fredross-perry: Yes, the gsview.com website says it's coming. | 19:56.42 |
| fredross-perry | thanks | 19:56.51 |
| Robin_Watts | If you're ready to go, mail chrisl a pointer to the latest version and I'm sure he'll put it up there tomorrow. | 19:57.05 |
| fredross-perry | will do | 20:03.06 |
| henrys | hi fredross-perry I thought you'd be out all day | 20:05.55 |
| fredross-perry | I am, but taking a short break. | 20:06.15 |
| | did you see my iCloud missive? | 20:06.26 |
| henrys | fredross-perry: I don't see pre-ios 8 folks being an issue but some might disagree. | 20:08.17 |
| fredross-perry | ok | 20:08.34 |
| henrys | jogux? | 20:08.38 |
| jogux | hasn't been following | 20:08.51 |
| | and I don't think I saw the iCloud missive | 20:09.09 |
| henrys | jogux: oh sorry thought you were on tech | 20:09.33 |
| | fredross-perry: can you forward to jogux, he started it ;-) | 20:10.03 |
| jogux | possibly I thought I was on tech. odd. | 20:10.28 |
| fredross-perry | will do | 20:10.33 |
| jogux | thanks fredross-perry | 20:10.37 |
| fredross-perry | done | 20:11.39 |
| henrys | jogux: I'll make a note to check your email status later. Have an errand right now | 20:12.25 |
| fredross-perry | np | 20:12.32 |
| jogux | got it. reading. | 20:12.40 |
| | yes. that makes sense to me. only iOS 8 has icloud drive support, and this only gets interesting/useful for icloud drive. | 20:13.17 |
| | the iOS 7 icloud stuff is significantly more difficult to code for, so would not be worthwhile from that point of view either. | 20:13.55 |
| fredross-perry | ok | 20:14.17 |
| | bye for now | 20:15.44 |
| jogux | the cloud picker stuff is expandable; it doesn't support dropbox/googledrive per-se, the dropbox/googledrive apps hook into it to do that. | 20:16.06 |
| mvrhel_laptop | ok. so where in the documentation is DITHERPPI defined | 21:05.14 |
| | other than in History2.htm .... | 21:05.49 |
| | let me run this without sse2 to see how things behave. | 21:06.55 |
| | ok so this is not about sse2 | 21:15.27 |
| | oh there is the doc on DITHERPPI | 21:17.36 |
| | ok so there is something odd going on with the small dither pattern on that huge image and I suspect it has to do with the apparent gray levels | 21:23.24 |
| x1 | I currently use xdotool for sending keystrokes to mupdf. Is there a clean alternative? | 21:27.50 |
| mvrhel_laptop | so to me this looks like the documentation of N/20 for lpi setting is a bit low for a suggested value for DITHERPPI | 22:16.07 |
| | henrys: on bug 695929 I think N/10 for a lower end which gives 30 lines per inch on a 300 dpi printer is more reasonable | 22:18.43 |
| | pushing it to N/20 leads to poor quantization issues | 22:19.05 |
| | have to run an errand bbbiab | 22:20.06 |
| | bbiab | 22:20.09 |
| rayjj | mvrhel_laptop: How about suggesting that they generate an ordered dither (or stochastic dither) threshold array. Your gen_ordered can make a larger threshold array with a small dot size and avoid the limit on number of levels, right ? | 23:02.46 |
| | mvrhel_laptop: by having a "supercell" that has several smaller cells making it up, so quantization doesn't bite us | 23:03.53 |
| mvrhel_laptop | rayjj: yes we could do that. I think the documentation is still wrong though | 23:05.33 |
| rayjj | mvrhel_laptop: right, and maybe the docs should point people to the toolbin/halftone stuff | 23:06.12 |
| mvrhel_laptop | yes | 23:06.15 |
| | if they bump up the levels to 30 or 60 lines per inch (or even more) at the resolution that they are running the output looks fine | 23:07.13 |
| rayjj | mvrhel_laptop: if you are swamped, I can generate am ordered dither threshold array and tell them how to use it | 23:08.04 |
| mvrhel_laptop | rayjj let me see what it is that they want and if doing something with a lower end of N/10 will work for them | 23:09.36 |
| | I am going to change the docs also to point toolbin/halftone also | 23:10.27 |
| | for other methods | 23:10.31 |
| rayjj | mvrhel_laptop: also, the stochastic threshold generation can accept a 'minimum dot' size/shape (up to 3x3) that would let us have a full 256 levels at a 200 "line" pitch at 600 dpi. The minimum dots are stochastically dispersed across a specified array (e.g. 99x99) | 23:13.17 |
| mvrhel_laptop | right | 23:13.27 |
| | rayjj: I have to admit I don't quite understand how the DITHERPPI parameter is getting used. It is stated that it is like lines/inch. But I am not convinced that this is case. If I am going to a 300dpi output device and I set DITHERPPI to 15 which is 300/20 I get the crummy result I would expect at 15 lines/inch | 23:19.01 |
| | if I have a printer at 1680 dpi and do DITHERPPI of 1680/20 = 84 I get the same looking result as the 15 lines/inch case | 23:20.01 |
| | for 300 dpi | 23:20.03 |
| | I would have thought I would see something much better | 23:20.11 |
| | am I missing something | 23:20.17 |
| | or is this expected | 23:20.53 |
| | of course as the halftone screen is defined in device space I suppose everything should simply scale up appropriately | 23:24.14 |
| | rayjj: I am going to look at the altona stuff now | 23:48.24 |
| | Forward 1 day (to 2015/04/22)>>> | |
IRC Logs