| | <<<Back 1 day (to 2015/07/01) | 20150702 |
| mvrhel_laptop | rayjj: I looked at the commit. There are a lot of changes in there and I fear I don't have anything specific to say. If it is matching the standard HT then I would say good. | 03:16.16 |
| | I assume you tested with images in landscape as well as different color types | 03:16.51 |
| kens | chrisl ping | 13:05.54 |
| chrisl | kens: pong | 13:07.51 |
| kens | Can you take a quick look at the reduced file attached to bug #696076 please ? | 13:08.22 |
| | I cannot work out why Acrobat does not display the 'Autodesk' text. Ghostscript does and so does MuPDF | 13:08.45 |
| chrisl | The "Autodesk" at the left side? | 13:10.14 |
| kens | I also tried another PDF interpreter of our acquaintance, and it renders that text too. Yes. that;'s it | 13:10.26 |
| | NB its at the right too | 13:10.40 |
| | But MuPDF doesn't render that text for some reason | 13:11.03 |
| chrisl | Hmm, everybody else seems to render it...... | 13:13.11 |
| | Hmm, '/Ordering (Indentity0)' - yeh, right..... | 13:15.39 |
| kens | Yeah I saw that, but it shouldn't make a difference I'd have thought | 13:15.58 |
| chrisl | It won't make a difference to it displaying, but clearly Autodesk haven't fixed their PDF output | 13:16.25 |
| kens | You mentioned ths before ? | 13:16.40 |
| chrisl | It's come up two or three times in the last few years | 13:17.07 |
| kens | OK fair enough, I can't say I'm surprised they haven't fixed it "Acrobat reads it OK" | 13:17.33 |
| chrisl | I don't suppose you know which object contains the text? | 13:18.57 |
| kens | Its the ones at the bottom of the stream I believe in font C2_1 | 13:19.17 |
| | <FFFF00030024005800570052004700480056004E0003FFFFFFFFFFFFFFFFFFFFFFFFFFFF> | 13:20.08 |
| | Actually I might be wrong about that, I just realised there are more of the same text in font C2_0 | 13:20.34 |
| | The text does get written 4 times, top, left, bottom and right | 13:21.42 |
| chrisl | Oh, so the text isn't OC at all? | 13:22.33 |
| kens | Its in an OCG but the OCG is visible | 13:22.44 |
| | Its the same OCG as the japanese text and strokes | 13:22.56 |
| | '0' in hte layers palette | 13:23.06 |
| | I tried removing the OCG and it made no difference though | 13:23.26 |
| | I thnk the one on the left is in font C2_1 (Arial-Bold)and the other three are in font C2_0 SimHei | 13:25.01 |
| chrisl | I don't follow - the text I'm looking at is in a normal content stream, referenced from the page's /Contents array | 13:25.40 |
| kens | Yes, that's the text | 13:25.49 |
| | But it has BMC/EMC around it | 13:26.07 |
| | Sorry BDC not BMC | 13:26.26 |
| | So we look up the OCG (MC42) to see if we should draw it. If its not in the /OFF array then its visible and we draw it. | 13:27.18 |
| kens | wonders if there is some kind of strange clipping going on | 13:28.53 |
| chrisl | So, are the other objects in MC42 being drawn? | 13:30.25 |
| kens | Yes | 13:30.29 |
| | The other objects are the japanese text and the horizontal lines | 13:30.46 |
| | Nothing I do makes Acrobat draw any of the 'Autodesk' text so I wonder if we're looking at another Acrobat weird bug | 13:31.42 |
| | I'll try and reduce the file further, my last attempts broke it | 13:32.07 |
| | Leave it with me for now | 13:32.27 |
| henrys | Robin_Watts: mupdf header files vary but I like to see a few comments in a .h file, looking at separation.h | 13:35.44 |
| chrisl | kens: the top and right hand cases "sort of" display in Acrobat 9 | 13:38.03 |
| | kens: and I don't think it's OC related because if I remove the BDC/EMC around the text, it doesn't change Acrobat's display (Acro 9, this is) | 13:46.41 |
| Robin_Watts | henrys: Fair comment, yes. | 13:58.38 |
| sebras | Robin_Watts: henrys: in mupdf we used to document the public interface, leaving the internal one undocumented. but I think you guys decided to make all interfaces belong in the public category after some time..? | 14:02.00 |
| | maybe there is a reason to document more of them..? | 14:02.08 |
| chrisl | kens: also, we have four identical strings, but in Ghostscript the one on the right displays differently to the other three | 14:03.31 |
| | Ah, different fonts.... | 14:03.52 |
| henrys | sebras: back in the day Peter would beat me up constantly about this: I think his approach is best: http://www.ghostscript.com/doc/9.16/C-style.htm#Headers ... doesn't matter if it's public, maybe it should be more verbose if public. | 14:08.37 |
| Robin_Watts | Ghostscript is a monumental description of how NOT to do it, IMHO. | 14:14.56 |
| | The APIs are muddy, unclear, undocumented and just plain crap. | 14:15.18 |
| | SOT, for all it's sins, gets this right. | 14:15.41 |
| | gs doesn't follow the "include what you use" rules of header files. | 14:17.03 |
| chrisl | kens: I think I know what the problem is, and this is going to be DIRE :-( | 14:17.07 |
| kens | Oh oh.... | 14:17.15 |
| Robin_Watts | And MuPDF is crap in this regard too. | 14:17.25 |
| chrisl | If I remove the FFFF values from the string, the "Autodesk" displays in Acrobat | 14:17.42 |
| kens | Oh dear..... | 14:17.49 |
| | THat seems just wrong | 14:17.55 |
| | Is there any justification for tht in the spec anywhere ? | 14:18.12 |
| chrisl | I have no idea. | 14:18.41 |
| Robin_Watts | The whole '#ifndef BLAH_DEFINED\ntypedef struct BLAH_s BLAH_t;\n#define BLAH_DEFINED\n#endif' is clear indication that the modularity is poorly defined. | 14:18.48 |
| | (in gs) | 14:18.55 |
| kens | Robin_Watts : we know that already..... | 14:19.14 |
| henrys | Robin_Watts: Indeed restrict my comment to the last paragraph of that section the rest is indeed crap. | 14:19.22 |
| kens | Chrisl OK if I remove the FFFF then I see *three* of the 'Autodesk' lines, top right and bottom, and they are the same as Ghostscript | 14:20.43 |
| | Possibly that font doesn't have enough glyphs in it to draw the whole lot or something | 14:21.00 |
| chrisl | kens: the top, right and bottom ones sort of display in Acrobat with the cut down file you posted on the bug | 14:22.26 |
| henrys | Robin_Watts: is there an API manifesto for SO? | 14:22.31 |
| Robin_Watts | henrys: There is a C coding standard. | 14:22.45 |
| kens | chrisl not for me in Acrobat X | 14:22.49 |
| | Let me try an earlier reader | 14:22.55 |
| chrisl | I'm using Acro9 | 14:23.03 |
| Robin_Watts | In which the requirements on APIs are laid out. | 14:23.06 |
| kens | X! doesn't show any of them | 14:23.41 |
| | Acroibat 9 does, so this is clearly an Acrobat bug | 14:24.09 |
| | Or 'feature' | 14:24.19 |
| chrisl | What I can't fathom is why there's a difference between the Arial and SimHei results | 14:24.53 |
| sebras | henrys: Robin_Watts: I tend to agree with lpd, but I have yet to see documentation that is accurate and complete. | 14:25.04 |
| kens | I assume the SimHei subset doesn't have all the glyphs | 14:25.08 |
| henrys | Robin_Watts: I'm just wondering if we shouldn't lay that out a meeting, and agree to a new coding standard across the board for new code. | 14:25.44 |
| sebras | maybe projects that are more or less done does it better, like libjpeg or zlib. but I never had to read their headers. ;) | 14:25.55 |
| Robin_Watts | sebras: I heartily agree that the header files are where people go. | 14:25.59 |
| chrisl | kens: preflight reports both fonts missing glyph 65535. | 14:26.01 |
| kens | I wouldnt' trust the preflight personally | 14:26.20 |
| Robin_Watts | Picsel adopted doxygen. Every API function (by which I mean across modules too) is described with a doxygen header. | 14:26.47 |
| chrisl | kens: well, no, but clearly the other glyphs are there because we render them - and notdefs for the FFFF | 14:26.55 |
| kens | Ghostscript doesn't, at least not for me | 14:27.17 |
| Robin_Watts | Now, I *never* read the the doxygen generated files, but I always refer to the doxygen definitions in the files. | 14:27.18 |
| jogux | All the iOS tools also grok doxygen style comments | 14:27.20 |
| | so if I mouse over a function it shows me a nicely formatted description of the function etc | 14:27.39 |
| chrisl | kens: Ghostscript renders "Autodesk" | 14:27.43 |
| kens | chrisl I get 'A' and 'de' all the rest are notdef or no marks | 14:27.54 |
| Robin_Watts | i.e. I don't care that doxygen can extract to docs - what I care about is that the information is all there in a clearly defined format. | 14:28.00 |
| jogux | henrys: That would be a 'fun' meeting :-) | 14:28.01 |
| chrisl | kens: I meant for Arial | 14:28.09 |
| kens | I only get Autodesk for the Arial text | 14:28.12 |
| | Oh yes, for Arial sure | 14:28.18 |
| sebras | Robin_Watts: I do the same for gstreamer (they use gtk-doc instead of doxygen, but the are similar enough) | 14:29.05 |
| chrisl | kens: So, if anything, the text that Acrobat is not showing is the only one that makes some sense to actually display | 14:29.16 |
| kens | Yep | 14:29.33 |
| | Madness isn't it ? | 14:29.38 |
| sebras | Robin_Watts: some of my colleagues insist on using some search engine to find the documentation though, which means that they always end up reading the description from some older version. :-( | 14:30.04 |
| chrisl | Well, especially when removing the FFFF codes cause it to display | 14:30.07 |
| kens | I'm going to ignore the random weird behaviour until someone can point me to a part of the spec that says we have to do that too | 14:30.37 |
| | I've already answered the questoin about the 'visibility' of optional content groups, and I may just close it unless Henry or someone tells me to implement something different. | 14:31.09 |
| chrisl | But the random weird behaviour is what the bug is about | 14:31.10 |
| kens | No it isn't | 14:31.14 |
| | The bug is because we draw the text, even when the layer is set to 'don't print' | 14:31.28 |
| | or even 'don't display' | 14:31.41 |
| henrys | Robin_Watts: well you said the api's in mupdf and gs are bad but I assume that has nothing to do with doxygen vs. old school comments | 14:31.43 |
| chrisl | kens: But how do we know Acrobat doesn't? | 14:31.53 |
| kens | Because allwe care about is whether the OCG is in the /OFF array | 14:31.56 |
| Robin_Watts | henrys: No. The APIs in mupdf are spot on. | 14:32.09 |
| | The header file structure in mupdf is crap, cos it doesn't "include what you use". | 14:32.34 |
| | But it's less crap than ghostscript. | 14:32.41 |
| kens | chrisl the user is complaining that setting the OCG to 'don't display' or 'don't print' makes no difference, only setting the default to 'not visible' does. To whcih the answer is 'yes' | 14:32.51 |
| Robin_Watts | The documentation for the APIs in mupdf is not bad (could be better, but the important ones have the required comments). | 14:33.11 |
| chrisl | kens: I thought it was specifically for those pieces of text he was complaining | 14:33.28 |
| kens | He was, but as far as I can tell, only necause when he turns off the layer (don't print), nothing happens | 14:34.01 |
| chrisl | kens: indeed - which may be exactly the same as Acrobat, but how would we tell? | 14:34.37 |
| kens | It isn't the same as Acrobat. If you set the OCG to 'don't print' and then print the document, that layer doesn't get printed. | 14:35.07 |
| | Like wise if you set it to 'don't display' then it doesn't appear in Acrobat | 14:35.20 |
| | In both cases we render it | 14:35.26 |
| henrys | Robin_Watts: I must have misunderstood you - above you said "mupdf is crap in this regard too" | 14:35.51 |
| chrisl | kens: So there is more in the layers than just the four "Autodesk" strings? | 14:36.10 |
| kens | Oh yes | 14:36.17 |
| Robin_Watts | henrys: I complained that gs was crap. And I gave a list of reasons why it was crap. The last one was that "gs does not include what you use". | 14:36.38 |
| kens | A bunch of text, horizontal rules, some linework, you name it really | 14:36.38 |
| chrisl | kens: Ah, well, I agree with you, then...... | 14:36.51 |
| kens | Thanks :-) | 14:36.56 |
| Robin_Watts | and i then said "mupdf is crap in this regard too", meaning "mupdf does not include what you use". | 14:36.59 |
| | I was unclear, as usual. | 14:37.05 |
| henrys | the good thing about LGTM is the G could stand for Greek right? | 14:37.18 |
| kens | Godawful.... | 14:37.32 |
| henrys | Robin_Watts: thanks I wasn't getting that piece. | 14:37.51 |
| Robin_Watts | tor and I have worked quite hard to make the APIs in mupdf consistently named, and sanely behaving. | 14:37.54 |
| | and modular. | 14:38.06 |
| | We have ripped up the rails and relaid it several times, in a way that is not possible with gs. | 14:38.27 |
| chrisl | s/not possible with gs/not allowed with gs | 14:38.57 |
| kens | I wouldn't say its not possible, just that we don't have the resources | 14:39.01 |
| chrisl | I wonder if anyone still builds Ghostscript with TurboC........ | 14:46.40 |
| kens | Can you still get TurboC ? | 14:46.53 |
| Robin_Watts | I guarantee if you remove it, someone will crawl out of the woodwork :) | 14:47.07 |
| kens | Apparently its on SourceForge | 14:47.16 |
| | Someone updated it on January 2013 for WIndows 7 and * o.O | 14:48.05 |
| chrisl | We only seem to have one TurboC related file left, so maybe I removed most of the build already | 14:48.20 |
| | I think I might remove it. | 14:48.45 |
| kens | And wait until somene complains :-) | 14:49.06 |
| Robin_Watts | I think that's reasonable. | 14:49.15 |
| chrisl | And try to explain nicely why we don't care? | 14:49.31 |
| kens | Well if you're feeling generously inclined | 14:50.12 |
| henrys | chrisl: a couple simple changes on my repo for you to look at. I'm bugging you because I had mixed feeling about deprecating margin's resolution entirely, let me know what you think. | 14:50.47 |
| chrisl | henrys: looking...... | 14:51.25 |
| kens | henrys, could do with some input on bug #696076, do you think its worth pursuing ths enhancement ? Should I ask Marcos to take it up with them (note email address of reporter) | 14:52.25 |
| henrys | kens: I'll look | 14:54.05 |
| kens | Thanks | 14:54.08 |
| | You might need to read osme of the back logs between me and Chris as well | 14:54.25 |
| chrisl | henrys: those commits look fine - I'd be happier if we knew the history behind MarginsHWResolution because I can see no logical reason for it at all.... | 14:56.57 |
| henrys | chrisl: Peter read the spec and saw the value could be different from the resolution. It's only use in the code is align.ps, did you have a look at that? | 14:58.03 |
| chrisl | henrys: I don't understand why it's just stored in points | 14:58.33 |
| henrys | chrisl: pagedevice docs say the units should be device specific for margins, right? | 14:59.13 |
| chrisl | henrys: they don't dictate the units we have to store them internally | 14:59.43 |
| henrys | chrisl: no but I think margins should remain "device like" for the user or postscript programmer. | 15:01.09 |
| | chrisl: my thinking is to just say in ghostscript margin resolution always equals device resolution and toss it. I'm afraid this is any easy thing to trip over and waste time for what it delivers ... | 15:02.23 |
| | s/any/an | 15:02.36 |
| chrisl | Aren't those Ghostscript specific parameters? | 15:02.37 |
| henrys | MarginsHWResolution is Margins is not. | 15:03.11 |
| chrisl | Yeh, so why do we need .MarginsHWResolution? | 15:04.00 |
| henrys | chrisl: but Peter was defining a parameter that is implied to be needed from the spec if you allow margin units to be different from device units. | 15:04.03 |
| mvrhel_laptop | TurboC wow. Had not heard that in awhile | 15:04.24 |
| chrisl | henrys: I'm not convinced by that..... | 15:06.05 |
| henrys | what the hell is your PM doing with encryption, I thought folks in the UK were too tech savvy to see that's not a good direction. | 15:06.18 |
| chrisl | At least, from the LL3 PLRM | 15:06.30 |
| kens | henrys the same as your president etc :-) | 15:07.42 |
| henrys | chrisl: it specifically says usually units of device space, so sometimes it must not be device space | 15:07.44 |
| kens | THey like to spy on the people, what could possibly go wrong ? | 15:07.57 |
| henrys | kens: expected in america we're still working on evolution for f*ck sake | 15:08.21 |
| kens | Well, mostly in the South :-) | 15:08.33 |
| | I suspect its all sound bites anyway | 15:09.17 |
| henrys | chrisl: I'll push this and agenda deprecating the resolution for margins which I think is reasonable anyway. We do have to remember to fix align.ps | 15:09.39 |
| chrisl | henrys: it says "device specific units, usually units of device space" - to me that implies it's something totally private to the device, not something visible, or settable from the Postscript world | 15:10.51 |
| henrys | chrisl: oh yes I shouldn't have said settable by the user. Indeed the code says it should not be set. | 15:11.46 |
| | chrisl: but we are still left to decide if we want to support the device changing it to something other than device resolution. | 15:12.46 |
| chrisl | henrys: I don't see that as relevant. | 15:13.05 |
| henrys | chrisl: I am proposing removing it entirely so we never have to trip over it again. | 15:13.36 |
| chrisl | henrys: I agree, I don't think it is (or was) necessary at all | 15:14.02 |
| henrys | chrisl: okay then to the agenda for deprecation. | 15:15.00 |
| chrisl | henrys: yes, possibly we should talk it over with everyone | 15:15.09 |
| | I just disagree with Peter's interpretation of that part of the spec | 15:16.25 |
| macwinner | I was trying to find a relatively efficient way of taking a PDF binary, and extracting an arbitrary page number as an image in nodejs WITHOUT requiring writing the slides to disk. I want to do everything in process and in memory... any tips on doing this? I currently use mudraw to render out the entire pdf into individual slides and store them on disk. | 15:18.15 |
| chrisl | macwinner: a good start would be to just tell mupdf what page you want rendered | 15:21.10 |
| macwinner | chrisl: you mean via the cli parameter? | 15:21.37 |
| chrisl | Yeh | 15:21.44 |
| macwinner | ahh.. yep.. was planning on that | 15:21.56 |
| chrisl | Then you could read the output from stdout instead of writing to disk and reading back | 15:23.04 |
| macwinner | is there a way to output the rendered page to stdout vs a file? | 15:23.06 |
| | heh.. ok | 15:23.21 |
| chrisl | "-o -" | 15:23.37 |
| | You'll probably want the -F option, too | 15:24.53 |
| macwinner | oh.. cool.. when I do mudraw --help, the -o option doesn't seem to mention that | 15:25.11 |
| | i'll give it a try, much appreciated! | 15:25.26 |
| chrisl | Well, I am looking at quite to up date mupdf builds, so..... | 15:25.47 |
| macwinner | now just neeed to find a simple nodejs module that simplifies the wrapping of stdout to a buffer | 15:25.51 |
| | chrisl: I'm looking at 1.7a... oh.. man page mentions it | 15:26.29 |
| chrisl | Well, tbh, I just guessed, tried it, and it seemed to work, so...... | 15:27.33 |
| macwinner | chrisl: you don't happen to see a way to pass the file in via stdin do you? | 15:30.07 |
| chrisl | macwinner: you really can't reasonably do that with a pdf | 15:30.41 |
| macwinner | oh, why not? (sorry I'm pretty noob when it comes to streams).. | 15:32.06 |
| chrisl | PDF is a random access file format, not a stream | 15:32.23 |
| macwinner | oh, but I mean sending the file into mudraw via stdin.. seems like mudraw could just stream in stdin to a buffer and wait for EOF | 15:33.44 |
| | maybe like this: https://github.com/derek-watson/mupdf/commit/39576ec93be2efcfeb1532fd0e0d518de28c876f | 15:34.01 |
| | i'lll try it on cli and report back | 15:34.14 |
| chrisl | mupdf has a goal of minimal interaction with the file system..... | 15:35.23 |
| macwinner | woops, i'm confusing mudraw with mupdf | 15:36.03 |
| chrisl | macwinner: there is scope in mupdf to read a PDF from an http connection, but I've no idea if that's exposed in the normal executable | 15:36.25 |
| macwinner | what's the relationship between mudraw and mupdf? | 15:36.50 |
| chrisl | mudraw is an tool built on the mupdf library | 15:37.16 |
| | In fact, mudraw is now part of mutool | 15:37.30 |
| macwinner | oh.. mudraw is just an alias for mutool? | 15:38.55 |
| | seems like it's own executable | 15:39.15 |
| chrisl | In the current code, I get it with: mutool draw | 15:39.40 |
| | That happened after the 1.7a release | 15:40.23 |
| macwinner | which mutool version? | 15:40.24 |
| | oh | 15:40.30 |
| | you're using latest dev version? | 15:40.42 |
| chrisl | Yes | 15:40.46 |
| henrys | kens, chrisl:2 things (1) is this guy a customer or is he doing something in house or unrelated to the company? and (2) if he is acting as a customer are they licensed to use PDF. Either marcosw or I should get to the bottom of that unless you already know. | 15:42.00 |
| kens | henrys I cannot tell, the email address is significant I would guess. | 15:42.47 |
| macwinner | so seems like I must write file to a tmp location, and then use mudraw to output to stdio and capture that output.. thanks for help chrisl! | 15:42.55 |
| kens | If I weas sure they were a free user I would simply say 'tha's the way it is', but the domain makes me think otherwise | 15:43.10 |
| henrys | kens: right let me talk to Miles first. | 15:43.32 |
| kens | OK we might need to set priorites and stuff | 15:44.04 |
| chrisl | macwinner: that seems to be the best way - it's not going to be any quicker to have mutool/mudraw do the buffering | 15:44.11 |
| henrys | kens: also do we want to push him to mupdf for this business? | 15:45.39 |
| kens | Well he's rendering it, presumably for printing. If they aren't already using MuPDF presumably they'd prefer to stick with Ghostscript, but what do I know ? | 15:46.27 |
| chrisl | macwinner: as I said, the other option would be to look at having mupdf pull the PDF over http - for a class of PDF, that *may* be quicker (at least in terms of time to first page) | 15:46.51 |
| macwinner | chrisl: thanks.. i think that may be a bit over optimized my for my situation :) | 15:47.18 |
| kens | We *can* add support for print/view/visible selection of OCG but it will take a little time and mean (yet more) parameters. Because we aren't interactive the user can't simply change the settings. Of course, for prining, we're never going to be interactive. | 15:47.33 |
| macwinner | is there any relationship between ghostscript and mupdf? i found this node module that uses imagemagick and ghostscript to render pages: https://www.npmjs.com/package/pdf-image | 15:48.03 |
| chrisl | macwinner: they are owned and developed by the same company, some of the same engineers - almost no crossover in terms of source | 15:48.51 |
| macwinner | is one "better" than the other for high fidelity rendering of the PDF pages? | 15:49.57 |
| chrisl | Yes, but which one depends on your definition of "high fidelity" | 15:50.40 |
| Robin_Watts | macwinner: Sorry, I'd have joined this conversation earlier, but have been on the phone. | 15:51.36 |
| | macwinner: What are you trying to achieve? | 15:51.51 |
| macwinner | I have a PDF file stored in mongodb gridfs.. I would like to read the file bytes into memory, and then extract arbitrary pages from it and send them back to a web browser | 15:52.42 |
| Robin_Watts | http://twiki.ghostscript.com/do/view/Ghostscript/GhostscriptOrMuPDF | 15:52.49 |
| | "extract pages"? You mean "render as bitmaps for screen use"? | 15:53.13 |
| macwinner | right.. render as PNG | 15:53.34 |
| Robin_Watts | Then, IMHO, mupdf is the one you want. | 15:53.46 |
| macwinner | then send back via HTTP content-type image/png | 15:53.54 |
| henrys | bbiab | 15:54.01 |
| macwinner | oh, i know this is not pdftk channel, but I stumbled upon it.. does it attempt to do something like mudraw? | 15:54.58 |
| chrisl | pdftk does not render anything | 15:55.14 |
| Robin_Watts | macwinner: I bet mongodb gridfs has a way of getting to files without unpacking them completely. | 15:55.45 |
| | Depending on how much work you want to do, you could make mupdf access the files in the db with no temp files. | 15:56.09 |
| macwinner | got it | 15:56.55 |
| | thanks for link to ghostscript vs mupdf | 15:59.32 |
| | regarding fidelity, I guess I mean which one will look the closest to how adobe acrobat displays the PDF :) | 16:00.24 |
| chrisl | Generally Ghostscript will be closer to Acrobat, but in practice there's not much difference | 16:01.31 |
| Robin_Watts | For screen use, I'd probably argue that MuPDF is closer to Acrobat (unless you go fiddling with the AA options in gs :) ) | 16:02.17 |
| chrisl | Erm, ICC color spaces, fuller transparency support, transfer function...... | 16:02.48 |
| macwinner | not sure what you mean by "screen use".. as opposed to? | 16:02.52 |
| chrisl | macwinner: Ghostscript is generally more targeted at printing | 16:03.51 |
| macwinner | is one of the tools planning on being deprecated? | 16:04.45 |
| chrisl | No | 16:04.52 |
| | macwinner: Unless you need pro proofing quality color (or support for Postscript), mupdf is the tool you want to use | 16:05.50 |
| fredross-perry | Hi gang. I have basic Gradle build going. No files moved, works in AS as well as command-line. | 16:05.55 |
| Robin_Watts | fredross-perry: Excellent! | 16:06.15 |
| chrisl | macwinner: and as you are displaying in a web browser, I'd suggest you don't need hi-fi color | 16:06.32 |
| macwinner | so with anti-aliasing flags, they pretty much look the same? reason I'm asking is because this pdf-image library I found looks like exactly what i need. but it uses imagemagick+ghsotscript. I remember messing around with ghostscript about 2 years ago and deciding on mudraw because mudraw seemed to output nicer images.. but that could just be beccaues I wasn't setting the right flags on ghostscript | 16:06.44 |
| fredross-perry | I think I should investigate how to make the four builds that are currently done into targets. | 16:06.47 |
| chrisl | macwinner: the mupdf anti-aliasing is better than Ghostscript's | 16:07.37 |
| fredross-perry | Also, as folks suspected, direct support for ndk is a little sketchy. Iâm doing what others ave suggested, which is to have gradle run ndk-build directly, thereby using the .mk files we already have. | 16:08.15 |
| macwinner | is it better because it has saner defaults? or just overall better | 16:08.17 |
| chrisl | macwinner: it's mainly better because it's directly supported by the mupdf rendering code, whereas it's a bit tacked on in Ghostscript | 16:09.10 |
| lewistg | Hello. I am new to ghostscript but am trying to do a color profile conversion. My question is posted on SO (http://stackoverflow.com/questions/31173009/convert-srgb-pdf-to-a-different-rgb-color-profile?noredirect=1#comment50361846_31173009). If any of you would have any insight, I would appreciate it. | 16:09.45 |
| macwinner | alrighty.. thanks again. I peaked at the pdf-image source code, and it doesn't have a hard dependency to ghostscript.. I can plug in mudraw instead | 16:09.46 |
| fredross-perry | Robin_Watts: (or anyone), what do we do about debugging JNI code? | 16:11.20 |
| Robin_Watts | fredross-perry: printf :) | 16:11.28 |
| | or I have used visualgdb in the past. | 16:11.37 |
| | which uses ndk-gdb behind the scenes I believe. | 16:11.46 |
| fredross-perry | ok, thatâs simple. Does anyone have a way to step thru JNI code? | 16:12.17 |
| Robin_Watts | visualgdb :) | 16:12.32 |
| | debugging both java and JNI code at the same time, can supposedly be done by a mixture of eclipse (for the java) and visualgdb for the native stuff, but if you really want to do it, I suspect the thing to do is to get the alpha Android Studio. | 16:13.47 |
| fredross-perry | does that require some build support? | 16:14.08 |
| Robin_Watts | fredross-perry: I honestly have no clue. | 16:14.41 |
| fredross-perry | have you tried it? | 16:14.46 |
| Robin_Watts | I have not. | 16:14.50 |
| fredross-perry | AS aplha that is | 16:14.53 |
| | all righty | 16:15.01 |
| Robin_Watts | I haven't done any android stuff for a while (though I am just starting again now with SOT) | 16:15.19 |
| fredross-perry | Gradle aso includes a lint step, which turned up a bunch of stuff, which should be looked at I suppose. Iâve got it turned off for now. | 16:23.15 |
| kens | lewistg The presence of a colour profile is no guarantee that a PDF file actually *uses* that PDF. I have no idea what 'identify' actually does | 16:26.28 |
| | lewistg don't use -dNOCACHE< as the documentaton explains that's for debugging purposes only. WHy are you setting that parameter ? | 16:27.58 |
| lewistg | kens: Okay. Do you know if what we are doing is possible? If it is, what combination of parameters would you suggest? | 16:32.08 |
| kens | lewistg I don't really know what you are trying to achieve. | 16:32.32 |
| | Your command line requests conversion to RGB, and that's what I get here, the output file continas no ICC prfiole at all. | 16:33.18 |
| lewistg | kens: Sorry. Maybe the end goal is not super clear. We have a pdf (usually with an sRGB profile embedded) that we would like to convert to a different RGB profile that we specify from an ICC file. | 16:34.13 |
| Robin_Watts | lewistg: Urm... In your SO question you use: | 16:34.28 |
| lewistg | So, we would like that specified ICC file to be embedded when we are all said and done. | 16:34.29 |
| kens | Well, that *should* be possible, but I'm not the colour expert | 16:34.32 |
| Robin_Watts | -sOutputFile=input.pdf \ | 16:34.37 |
| | output.pdf | 16:34.39 |
| chrisl | I would not trust identify for checking your output | 16:34.59 |
| Robin_Watts | i.e. you name input.pdf as the output file, and output.pdf as the input one. | 16:35.00 |
| kens | Robin_Watts : confusing, but not illegal :-) | 16:35.17 |
| Robin_Watts | Is it possible that you are running the conversion the wrong way, and hence output.pdf is the original file, so you would be seeing the ICC profile in that? | 16:35.34 |
| lewistg | Sorry typo. | 16:35.41 |
| kens | Note that the 'input.pdf' file attached to that question doesn't have any ICCBased colour spaces, so it isn't using an ICC profile | 16:36.00 |
| | I believe that, by correctly specifying the ICC colour management, it shoudl be possible to end up with a colour specified in the required ICCBased colour space, and if you leave ColorConversionStrategy at LeaveColorUnchanged, that's what will get written to the output. | 16:37.53 |
| | But I haven't tried to do this ever | 16:38.00 |
| | SO I cannot say for sure it is possible | 16:38.10 |
| | Its also not required. | 16:38.16 |
| chrisl | FWIW, *every* PDF I run identify on, it reports the same ICC pofile ("Description: Artifex Software sRGB ICC Profile") - even those I *know* have no profiles in them | 16:39.16 |
| kens | The whole point of the ICCBased space is that a conforming Color Management System knows how to interpret the colour values. It doesn't matter if you specify 0.5 0.5 0.5 in AppleRGB, but are actually prting to SWOP | 16:39.18 |
| kens | is puzzled how 'identify' can come up with that, if there's no ICC profile in the PDF file..... | 16:39.58 |
| chrisl | Don't know, don't plan to try to find out. | 16:41.30 |
| kens | I wonder if the 'original' file is also a Ghostscript-produced PDF file, and the real problem is that idenitfy is simply spouting nonsense and claiming that both PDF files have an sRGB profile, when in fact *neither* do. | 16:43.32 |
| | Anyway, time to go, night all | 16:43.59 |
| lewistg | kens: Thanks for your feedback and time. | 16:44.17 |
| henrys | Robin_Watts: cmyk_to_rgba has 63356 - k, a typo? | 17:20.54 |
| Robin_Watts | henrys: oops,yes. | 17:23.41 |
| henrys | in the same file s/figure out of/figure out if/ | 17:24.18 |
| | Robin_Watts: ^^^ | 17:25.17 |
| | chris and kens for the logs con-way is black listed until we get a support reponse | 17:26.21 |
| | impressive Robin_Watts good work in a short time nice | 17:27.39 |
| | Robin_Watts: 4K on the stack for blatter? I guess that's okay but... | 17:30.03 |
| chrisl | henrys: er, eh? "con-way"? | 17:30.55 |
| Robin_Watts | sep blatter doesn't get out of bed for less than 4K. | 17:31.46 |
| henrys | chrisl: http://bugs.ghostscript.com/show_bug.cgi?id=695979 | 17:32.45 |
| chrisl | henrys: ah. gotcha - totally forgot about that | 17:33.52 |
| henrys | chrisl: no problem I got miles to pursue them again... | 17:34.28 |
| Robin_Watts | henrys: Fixed versions online if you want to check them over. Otherwise I'll push 'em. | 17:36.46 |
| | oh, balls. the separations stuff had already gone to master. | 17:37.36 |
| | Let me rejig that as a fix. | 17:37.44 |
| henrys | Robin_Watts: go ahead an push unless mvrhel needs to look | 17:38.21 |
| Robin_Watts | I'm happy to push and then fix any problems later. Up to him... mvrhel? | 17:39.38 |
| mvrhel_laptop | sorry I was out | 17:58.18 |
| | reading logs | 17:58.20 |
| | Robin_Watts: so what do you need me to do? if anything? | 18:01.38 |
| | Robin_Watts: when are you leaving? | 18:01.50 |
| | I am trying to wrap up some stuff in gsview before I started the separation stuff | 18:02.08 |
| | I almost have gsview back together | 18:02.15 |
| Robin_Watts | mvrhel_laptop: I have the mupdf changes for gproof on robin/master. I was wondering if you wanted to look them over before I committed. | 18:02.25 |
| mvrhel_laptop | Robin_Watts: oh let me take a quick look | 18:02.35 |
| Robin_Watts | Henry has looked them over, so the "must be reviewed" requirement for mupdf has been achieved. | 18:03.00 |
| | mvrhel: There is no huge hurry on this. I'm not on holiday for another 3 weeks. | 18:03.39 |
| | being called for food. bbl. | 18:03.50 |
| mvrhel_laptop | Robin_Watts: I took a look. I don't see any issues. Nicely done. | 18:09.42 |
| | this weather here is crazy | 18:11.28 |
| | we have been in the 90s for a week and it is staying that way for awhile it appears. we usually only have a couple days the whole summer get that warm | 18:11.58 |
| | no ac here wither | 18:12.23 |
| | either | 18:12.25 |
| | luckily it does cool off at night | 18:12.45 |
| Robin_Watts | mvrhel_laptop: Thanks! | 18:45.35 |
| mvrhel_laptop | np | 18:45.41 |
| | Forward 1 day (to 2015/07/03)>>> | |
IRC Logs