| | <<<Back 1 day (to 2016/02/29) | 20160301 |
| Robin_Watts | kent3116: 1 is certainly possible. See doc/example.c | 00:03.13 |
| | 2 is possible (depending on exactly what you want to feed to your printer) | 00:03.35 |
| | 3 is not currently possible. | 00:03.45 |
| | At least not without a lot of programming. | 00:03.51 |
| kent3116 | Oh bugger on #3 :( | 00:08.12 |
| | I've looked at the Sudama project - which handles the printing. | 00:09.22 |
| sebras | tor8: utf8len on sebras/master fixed immedate comments on sebras/unicode have a local patch for html context struct in progress. | 00:11.05 |
| Robin_Watts | kent3116: It's on our roadmap, but we aren't there yet. | 00:24.47 |
| kent3116 | cool - any idea on when ? (ie. are we talking 1.9 2.0 or 2.7 ? | 00:26.56 |
| Robin_Watts | 1.9 is due out in march. | 00:29.59 |
| | It won't be done by then. | 00:30.02 |
| | The september release, maybe, but we won't promise it. | 00:30.20 |
| kent3116 | Okay - at least I know it's not soon so I need to find an alternative approach. | 00:33.21 |
| | BTW: it's 1st March already (for me anyway) | 00:34.01 |
| | And more importantly - not to waste time trying to figure out how to do it with mupdf | 00:34.50 |
| | Morning. I have a couple of questions regarding using the mupdf library | 08:19.38 |
| kens | kent3116 : You're a bit early, feel free to ask your questions and someone will read the logs when they come online | 08:20.12 |
| | Ot if you can stick around a couple of hours someone will be here by then | 08:20.28 |
| kent3116 | Sorry - what time is it currently ? | 08:20.29 |
| kens | Its 8:20 am here in the UK | 08:20.39 |
| kent3116 | Okay - it's 9:20pm here in NZ | 08:20.54 |
| kens | But Robin and Tor (who is in Sweden) start and finish later | 08:21.10 |
| | OK so if you put your questoin, then one of them will answer later and you can read the reply in our logs | 08:21.36 |
| | The channel message has the URL for the logs in it. | 08:21.47 |
| kent3116 | Yes - I was speaking to them earlier today. I assumed they had finished by now. | 08:21.55 |
| kens | Yes I read the logs as well, RObin was up past midnight our time still answering | 08:22.17 |
| kent3116 | dedicated ! | 08:22.40 |
| kens | Mad :-) | 08:22.45 |
| | Seriously, we work hours to suit ourselves, mostly. | 08:23.04 |
| kent3116 | Okay - questions: | 08:23.12 |
| kens | So RIobin *will* be along, but not for a few hours | 08:23.18 |
| kent3116 | 1) When I compile the Samatra example project - the app size is about 7Mb in total. When I compiled, my project went from 2mb up to 14Mb in size. And so far, all I've done is follow the example.c code. | 08:24.27 |
| kens | Ah I thnk I can answer that one | 08:24.47 |
| kent3116 | cool - please do. | 08:25.03 |
| kens | Its a difference in the fonts, MuPDF uses a quite extensive font for substitution | 08:25.08 |
| | SumatraPDF doesn't. | 08:25.19 |
| | SO a large part of that difference will be the font data | 08:25.37 |
| kent3116 | okay - so I can do the same by removing the font data as well ? | 08:25.51 |
| | and if so - how ? | 08:26.01 |
| kens | You're getting ourside my knowledge, but..... | 08:26.08 |
| | If you do that then you will need to supply a different substitute font, otherwise PDF files which don't include fonts (and there are a lot of these) won't be able to render the text | 08:26.42 |
| | You'll probably want to see what Tor has to say on that score as well. | 08:27.37 |
| kent3116 | that makes sense. Okay, I'll leave this one open for Tor. | 08:27.56 |
| kens | If you can limit the languages you want to support then that will allow you to use a simpler font | 08:28.21 |
| kent3116 | Question 2: I want to get a page as a PNG image stream. Is there a native way to do this ? Or, do I get as a BMP image and convert to PNG myself ? | 08:28.38 |
| kens | I believe the current fallback one supports lots of languages, including the CJKV family | 08:28.41 |
| kent3116 | I just need english support | 08:28.52 |
| kens | Then you can probably use something simpler,but I can't help you with how | 08:29.11 |
| chrisl | Even with "just English", leaving out the CID substitute may well cause files not to display properly | 08:29.58 |
| kens | Yeah but you could use a Latin substitute CID which would at least be smaller | 08:30.23 |
| kent3116 | Great - If I can figure out how to swap for a Latin substitute - then I can test and if it breaks, live with the larger size. | 08:32.33 |
| | Next: a page as a PNG image ? | 08:32.43 |
| kens | Sorry, no idea | 08:32.50 |
| chrisl | On the Makefile based build, I'd start with using "make XCFLAGS="-DNOCJK", but I don't know how that translates into the VS project | 08:33.20 |
| kent3116 | for the mupdf project ? | 08:33.52 |
| chrisl | Yes | 08:33.58 |
| | for question 2: the normal mutool executable can output png to stdout, with "mutool draw -o - -F png my.pdf" so that should be doable | 08:37.09 |
| kent3116 | Great - it's down to 7Mb in size now :) | 08:38.08 |
| chrisl | Sumatra has a diverged a *lot* from the canonical mupdf project | 08:39.08 |
| kent3116 | Okay - the output wasn't quite what I expected - but I can see that it's a PNG image. | 08:47.40 |
| chrisl | What were you expecting? | 08:48.20 |
| kent3116 | It's okay, the -o - output it to the command line. I replace with a p%d.png and it saved to file - which is what I was expecting in the first place. I just didn't read the help. | 08:51.10 |
| chrisl | You said you wanted a "PNG image stream"........ | 08:52.14 |
| kent3116 | I know - I got what I wanted - I just was expecting the command line to output a file - and I'd then pull it apart to just get the stream. You gave me exactly what I asked for :) | 08:59.12 |
| chrisl | If you poke around in the source/tools/mudraw.c that contains all the gubbins for writing PNG (and other formats) | 09:00.28 |
| kent3116 | Yup - looking now. | 09:01.46 |
| Robin_Watts | tor: For the logs: http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=d8b1db49ee72718a3a61d9ac1bb04886ecac2341&project=mujstest | 09:54.29 |
| tor8 | Robin_Watts: most curious... but hm, I thought I'd already changed ft_width to use the FT_Get_Advance call and not load the full glyph | 10:55.26 |
| Robin_Watts | It's only the mujstest one, not the mupdf one. | 10:55.56 |
| tor8 | I know, which is the most curious case | 10:56.05 |
| | kent3116: if you are sure you will *never* need any foreign language support, you can strip the binary size by omitting all the fallback fonts and encoding tables | 10:57.22 |
| | if you add -DNOCJK and -DTOFU to the compiler flags (this is for the latest code in git, older versions don't have the TOFU option) | 10:58.17 |
| Robin_Watts | tor8: 4 commits on robin/master (plus the one you looked at yesterday) | 13:26.54 |
| tor8 | Robin_Watts: all LGTM. there's also one fix on tor/master, but I haven't looked into why mujstest fails and if it actually fixes it. | 14:05.52 |
| Robin_Watts | Urgh. 5068 diffs with my changes. | 14:42.38 |
| | Oh, from previous clusterpush. Ignore that then. | 14:42.52 |
| | tor8: The "Use FT_Get_Advance" one? | 14:44.05 |
| | That's got some stray debug code in it. | 14:44.10 |
| tor8 | ah, oops | 14:45.06 |
| | Robin_Watts: doing the pdf object api implementation in mutool run first... | 14:45.49 |
| HenryStiles | marcosw: how can I use the cluster to test how code changes effect output size for the devices pxlcolor, pxlmono? Is it best to just give a patch to you? | 15:10.52 |
| kens | I htnk you will have to, its a big reason I didn't try to test my own patch | 15:11.14 |
| | I'm curious to know how that will work out, I seem to recall Robin tripping over some problems with copy_mono and the pattern accumulator | 15:12.42 |
| | If marcosw does wake up, could he test my patch too ? | 15:14.22 |
| HenryStiles | I'll just put marcos on the bug and ask him to test both patches or tell us how to. | 15:14.53 |
| kens | That would be good, I'm certain my patch needs a decent test, for output size with normal text if nothing else | 15:15.27 |
| HenryStiles | kens: looking at all the crap in these devices - I really wonder how long it would take to just extract the pcl/xl parser from ghostscript and write the corresponding commands for each pcl/xl command and have a perfectly reasonable solution. | 15:19.40 |
| | corresponding pdf commands that is. | 15:20.08 |
| kens | Ah! | 15:20.13 |
| | Was rereading that in confusion :-) | 15:20.21 |
| | I guess the problem is that there aren't direct equivalents for some stuff, and you still get left with the font creation. Plus our existing solution does all sorts of clever configurable stuff, which that wouldn't do (PDF/A, PDF/X colour management, font subsetting, font flattening, etc etc) | 15:21.40 |
| | And of course ROPS still wouldn't work, but we might be able to get closer that way | 15:21.57 |
| | Morning mvrhel_laptop | 15:23.56 |
| mvrhel_laptop | morning kens | 15:25.16 |
| kens | Michael, I was wondering about this request to get black text from RGB input with pdfwrite, would you have some time this week to discuss it ? | 15:25.47 |
| | In person that is :-) | 15:25.58 |
| mvrhel_laptop | kens sure sounds good | 15:26.34 |
| kens | Great, if you can bring along anything you think migh be useful (ICC profiles or whatever), I can make a test file | 15:27.14 |
| HenryStiles | kens: right but some stuff - the font business could probably be yanked right out of the ghostscript, but a lot of stuff would be difficult. If we were starting from the beginning of PCL -> PDF and we knew how much time would be spent I am not sure ... but we've invested most of the time already | 15:27.54 |
| mvrhel_laptop | I will start packing the ICC profiles in my suitcase | 15:27.59 |
| kens | :-) | 15:28.06 |
| HenryStiles | mvrhel_laptop, Robin_Watts : do you guys want to meet Thursday morning ? | 15:28.33 |
| Robin_Watts | HenryStiles: Ah, so you are going to the show too ? | 15:29.01 |
| HenryStiles | you're the only 2 going early? or is paul coming too? | 15:29.01 |
| Robin_Watts | paul too. | 15:29.06 |
| rayjj | kens: you can check the dev->graphics_type_tag and force black then | 15:29.08 |
| kens | rayjj that's not the problem really, it smore complicated than that. I *know* its text already, ths is pdfwrite remember | 15:29.33 |
| rayjj | are we having the meeting here or on #artifex | 15:29.38 |
| marcosw | no meeting today because of the upcoming staff meeting? | 15:29.43 |
| kens | Henry said no meeting :) | 15:29.47 |
| | last week I thnk | 15:29.53 |
| Robin_Watts | If there are 4 of us, it may be worth ubering it rather than barting. | 15:29.59 |
| rayjj | oh, that makes sense | 15:30.11 |
| mvrhel_laptop | HenryStiles: I don't arrive until late morning on Thursday. So I will see you all at the show in the early afternoon | 15:30.31 |
| marcosw | what time are you getting to the show on Thursday? I'm planning on coming by as well. | 15:31.04 |
| mvrhel_laptop | Let me check my flight | 15:31.25 |
| Robin_Watts | marcosw: My credit card got charged yesterday for my Carbon Flyer. Which probably means it'll arrive at your house next week :( | 15:32.38 |
| marcosw | bad timing. | 15:32.50 |
| | I do have a small package from you, I think from Canada. | 15:33.06 |
| mvrhel_laptop | looks like my flight arrives 11:18. I probably wont be getting to the show until 1 I would imagine | 15:33.16 |
| Robin_Watts | oh, right, the monitor detect killer. | 15:33.24 |
| mvrhel_laptop | at best | 15:33.25 |
| marcosw | I plan on getting there at noon, though there is some question of badges. | 15:34.14 |
| mvrhel_laptop | I would imagine you pick them up there, but reg. could be closed that late in the show | 15:34.52 |
| Robin_Watts | marcosw: We were all sent pre-registratrion links, right? | 15:34.57 |
| mvrhel_laptop | yes | 15:35.04 |
| Robin_Watts | rayjj: I have one outstanding bug I'd like to get closed before the meeting, and that's the one with the diffs caused by enabling the 'special' downscaler. | 15:36.13 |
| rayjj | Robin_Watts: OK, what can I do to help ? | 15:36.54 |
| Robin_Watts | We'd talked about this before. I changed the code so that rather than keeping the minimum value, it kept an average value and the minimum, and only chose the minimum if it differed a lot. | 15:37.41 |
| marcosw | I do not recall receiving a registration link; when was it sent? | 15:37.52 |
| Robin_Watts | But that still has problems, especially with halftoned input. | 15:38.09 |
| rayjj | Robin_Watts: right | 15:38.23 |
| Robin_Watts | marcosw: 15th January ish I think. | 15:38.51 |
| | rayjj: So I tried something else on top of that. | 15:39.14 |
| | I only use the special downscaler if we're not downscaling by more than a factor of 8. | 15:39.33 |
| HenryStiles | marcosw: subject: Your registration confirmation for RSA Conference 2016 | 15:39.44 |
| rayjj | Robin_Watts: seems like a rather frail/arbitrary assumption | 15:40.27 |
| Robin_Watts | rayjj: Indeed. | 15:40.49 |
| rayjj | Robin_Watts: like "this is what I need to get past the regression testing" | 15:40.53 |
| marcosw | HenryStiles: no such email | 15:40.54 |
| rayjj | Robin_Watts: iirc, this all stems from doing interpolation of masks ? | 15:41.38 |
| Robin_Watts | Well, my logic was that if we're downscaling that much, then any single pixel cannot make more than 1/256th of a difference in a color value. | 15:41.51 |
| | i.e. each pixel is basically insignificant in the overall sum. | 15:42.33 |
| | but I'm not convinced it's correct. | 15:42.50 |
| rayjj | that's sort of why i thought we needed separate anti-dropout vs. interpolation | 15:43.09 |
| Robin_Watts | It's not interpolation of masks, no. | 15:43.10 |
| | There were 2 problems that I tackled within a couple of days of one another that collided. | 15:43.42 |
| | The first was interpolation of masks (cos otherwise they look really ratty). | 15:44.00 |
| rayjj | some customers want anti-dropout, others want interpolation for image smoothing | 15:44.11 |
| Robin_Watts | The second was to grid fit images within pattern cells to avoid white lines. | 15:44.29 |
| rayjj | triggering the "special" downscaler when interpolating was a kloodge I regret | 15:45.07 |
| Robin_Watts | Unfortunately that second one meant that when downscaling halftone patterns, we could flip-flop from solid to blank due to the tiny changes. | 15:45.26 |
| | so I kicked on interpolation, and we get much better results. | 15:45.39 |
| | The problem with that is that the special downscaler kicks in, and that (for haltoned photos etc) can produce big color shifts. | 15:46.13 |
| rayjj | Robin_Watts: so, the grid fit caused the issue with halftone downscaling, right' | 15:46.15 |
| Robin_Watts | Yes. | 15:46.23 |
| | How could we sensibly separate the antidropout and interpolation stuff? | 15:46.55 |
| rayjj | Robin_Watts: so doing "real" interpolation when downscaling would solve the interference from the "special" downscale, right | 15:47.53 |
| Robin_Watts | rayjj: It would. | 15:48.06 |
| | (Although arguably there are cases where we'd want to be using the antidropout when downscaling into pattern cells.) | 15:48.42 |
| rayjj | Robin_Watts: rather than trigger the anti-dropout on interpolation, have a separate control for that, probably in the device | 15:48.56 |
| | the anti-dropout was a specific request from a large customer (531) | 15:49.39 |
| | prior to that, everyone lived with the "center of pixel" rule when downscaling | 15:50.19 |
| | that's why it's only triggered for devices with < 4 bits per pixel | 15:51.40 |
| Robin_Watts | rayjj: So you're suggesting that we frob the image enum stuff so that it only chooses the anti-dropout scaler if the device requests it? | 15:55.50 |
| mvrhel_laptop | brb | 15:56.49 |
| rayjj | Robin_Watts: right | 15:57.24 |
| | since for the most part, just interpolation works better | 15:57.52 |
| Robin_Watts | Surely that'll just mask the problem for all but that particular device? | 15:58.03 |
| | which means people using that device will see these problems and no one else will. | 15:58.16 |
| rayjj | Robin_Watts: yeah, but that customer is aware of the "darkening" issue that happens and was using "-dDOINTERPOLATE" on files from a particular source to work around the dropout | 16:00.36 |
| | they didn't use interpolation in general since they mostly didn't want the performance hit | 16:01.41 |
| | so we can tell Phil that instead of -dDOINTERPOLATE use something else | 16:03.08 |
| Robin_Watts | rayjj: OK. | 16:04.52 |
| | -dANTIDROPOUT_IMAGE_DOWNSCALER | 16:05.09 |
| | rayjj: OK, will ponder on that. Thanks. | 16:07.00 |
| rayjj | Robin_Watts: yeah, and either a new device flag for that (maybe in color_info) | 16:09.13 |
| | or overload an existing flag (in the gs tradition of avoiding adding to structures that bites us in the but later ;-) ) | 16:10.10 |
| | s/but later/butt later/ | 16:10.36 |
| Robin_Watts | rayjj: Urm... we already have a gxdso_interpolate_antidropout that we work on... | 16:15.55 |
| | And the default implementation is for that to only say "yes" if we are halftoning. | 16:16.37 |
| | Probably the right thing to do is to make the default say "no", and to move the responsibility for saying "yes" into the customers device. | 16:17.03 |
| kens | Seems reasonable to me | 16:17.14 |
| rayjj | Robin_Watts: I was sleeping back when you added that :-) | 16:17.35 |
| | Robin_Watts: that sounds like a good idea | 16:17.48 |
| Robin_Watts | Which means it's not quite as simple for the customer as specifying "-dANTIDROPOUT" or whatever, but it's neater and doesn't clutter the rest of the code. | 16:18.12 |
| rayjj | Robin_Watts: how do you feel about implementing the spec_op based on a device parameter in some device as an example? | 16:21.32 |
| | say, TIFF for example ? | 16:21.41 |
| | this customer uses a device that closely mirrors the TIFF device, and often uses the TIFF device to report problems | 16:22.35 |
| Robin_Watts | rayjj: I'm just pondering that some people might want to have the -dANTIDROPOUT option in other devices, so maybe implementing that is sensible. | 16:23.09 |
| rayjj | Robin_Watts: I suspect that it is fairly rare. It's not well documented (since it is such a kloodge) so only those that have complained about dropout have been told to use -dDOINTERPOLATE | 16:24.26 |
| Robin_Watts | so I'm looking for an existing option that's similar.... | 16:24.34 |
| | DOINTERPOLATE and NOINTERPOLATE involve messing in the PS startup code, so they are bad things for me to copy. | 16:25.06 |
| rayjj | Robin_Watts: agreed. | 16:25.17 |
| | Robin_Watts: option that's similar in what way ? | 16:25.30 |
| Robin_Watts | An option that works for all devices. | 16:26.33 |
| | and sets a 'global', effectively. | 16:26.48 |
| rayjj | GrayToK is one, I think | 16:26.58 |
| Robin_Watts | Perfect! | 16:27.17 |
| | Thanks. | 16:27.19 |
| rayjj | but it's hidden away in mvrhel's icc_struct | 16:27.26 |
| | Robin_Watts: another example is the *AlphaBits tucked in the color_info struct | 16:28.54 |
| | Robin_Watts: there's a lot of other random special purpose (device type specific) stuff in the color_info, so polluting that further doesn't concern me overmuch | 16:31.36 |
| Robin_Watts | ok. | 16:31.42 |
| rayjj | Robin_Watts: I think there is something wrong with mupdf cmyk processing -- I am seeing horrible performance | 16:33.46 |
| | that's on the Pi | 16:34.26 |
| | Robin_Watts: for example, j9 with RGB is 14.6 ppm, but with cmyk it drops to 1.2 ppm (600 dpi) -B938 for rgb, -B698 for cmyk, but that can't make that much difference | 16:37.18 |
| Robin_Watts | rayjj: Urm... it wouldn't surprise me that for cmyk we do a lot of back and forth rgb -> cmyk conversion. | 16:37.52 |
| rayjj | even PLRM goes down from 37ppm to 1.9ppm | 16:38.02 |
| | and that is mostly all black text, and *NO* transparency at all | 16:38.24 |
| Robin_Watts | rayjj: yeah. I'd have to have a look. | 16:38.36 |
| | Maybe miss out cmyk numbers for now for mupdf ? | 16:38.48 |
| rayjj | Robin_Watts: yeah, I'll leave those "TBD" | 16:39.13 |
| | besides, that way I don't have to wait for it to finish :-) | 16:39.40 |
| tor8 | Robin_Watts: http://fpaste.org/331763/50376145/ | 16:39.50 |
| | it works! | 16:39.54 |
| Robin_Watts | tor8: Nice. | 16:40.18 |
| tor8 | the java version won't be quite as nice... the automatic type conversion between javascript and pdf objects was neat | 16:40.44 |
| HenryStiles | rayjj: we are down to 2 customer bugs... 0 is sooo close. | 16:40.58 |
| Robin_Watts | tor8: Except... new mupdf.PDFDocument() seems nasty. | 16:41.02 |
| tor8 | Robin_Watts: what would you recommend? new mupdf.PDF() or new PDFDocument() ? | 16:41.22 |
| Robin_Watts | new mupdf.Document(PDF) ? | 16:41.34 |
| tor8 | this is pdf_create_document, not fz_new_document | 16:42.00 |
| | to create a blank new pdf | 16:42.06 |
| | if you want to edit, it's pdf = new mupdf.Document("foo.pdf").toPDF() | 16:42.53 |
| Robin_Watts | Loading an existing document should go through mupdf.document, and we should get a PDF specific interface to that document by... that. | 16:43.01 |
| | So it would seem nicest if we went through mupdf.Document to create new documents too. | 16:43.26 |
| | new mupdf.Document(format) | 16:43.38 |
| | so if we ever support creating XPS or JPEG etc, we could do new mupdf.Document("XPS") or whatever. | 16:43.56 |
| tor8 | possibly. maybe later, when we support more than PDF? | 16:44.13 |
| Robin_Watts | tor8: Sure. | 16:44.34 |
| tor8 | when we have fz_new_empty_document(format) ... it's worth thinking about for next year :) | 16:45.09 |
| Robin_Watts | Well, implementing an fz_new_empty_document(format) that throws an error on format != PDF and calls the appropriate code for PDF is not hard. | 16:46.17 |
| tor8 | true. | 16:46.30 |
| Robin_Watts | and it signals our intent for the API. | 16:46.46 |
| tor8 | agreed. | 16:46.57 |
| mvrhel_laptop | tor8: is this in golden now? | 16:51.42 |
| tor8 | mvrhel_laptop: no, but soon | 16:51.59 |
| mvrhel_laptop | cool. | 16:52.06 |
| tor8 | mvrhel_laptop: it's on tor/master if you want to play with it | 16:53.16 |
| mvrhel_laptop | tor8: ok. I will take a look | 16:53.29 |
| rayjj | HenryStiles: I have no qualms about closing 696339 since the workaround solves the customer issue. The only reason I didn't close it was because it runs slower with larger BufferSpace | 16:53.41 |
| | and that's a low priority issue | 16:53.59 |
| | HenryStiles: but bug 696257 is harder | 16:54.32 |
| | HenryStiles: I went ahead and took the customer # off of bug 696339, and updated the description to the actual remaining issue. | 17:02.36 |
| Robin_Watts | rayjj: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=c4a77c721ab2341f2f4617ab55f1f690dc72ac5b | 17:07.29 |
| HenryStiles | rayjj: yeah that last one does look nasty | 17:12.31 |
| Robin_Watts | tor8: 1 fix on robin/master | 17:13.54 |
| HenryStiles | rayjj: did anyone check what acrobat does when the file is rendered at 600 dpi to tiff? I didn't see that in the report | 17:15.25 |
| rayjj | HenryStiles: which file ? | 17:16.02 |
| kens | The type 3 image. But I doubt its a problem with Acrobat, its the wy we implement it that causes a problem | 17:16.27 |
| rayjj | Robin_Watts: LGTM (the antidropout changes) | 17:16.30 |
| Robin_Watts | rayjj: Thanks. Just waiting for some final tests, then will push. | 17:16.53 |
| | And I think that'll be me done before I fly. | 17:17.06 |
| kens | See you on Thursday evening then, enjoy the show | 17:17.33 |
| rayjj | HenryStiles: I doubt Acrobat has any issues with the Image w/ Mask since this case is quite simple (mask and image are the same format and orientation) | 17:17.52 |
| HenryStiles | rayjj: yeah probably so | 17:18.20 |
| kens | HenryStiles : FWIW when I try saing the file for bug #696257 to a 600 dpi TIFF it i unable to do so 'The image is too wide to output'. Of course it is a huge page | 17:23.58 |
| | 300 dpi works and is reasonably quick | 17:24.56 |
| | Bight all | 17:25.56 |
| rayjj | good bight kens ;-) | 17:26.37 |
| HenryStiles | rayjj: it does seem a rather important issue with our dependence on wide format customers. Surprised it hasn't come up before, of course it is a very large image | 17:28.05 |
| rayjj | HenryStiles: yes, but images with masks are fairly unusual | 17:32.55 |
| HenryStiles | rayjj: I was just curious and looked, just bumpiin up tile_clip_buffer_request seems to print the file okay, does that break something else, I don't see any comments in the code to indicate that. | 18:42.41 |
| tor8 | Robin_Watts: LGTM. | 18:52.36 |
| Robin_Watts | tor8: Thanks. | 19:00.00 |
| kent3116 | Tor: Thanks for the two flags. In the Sumatra project, he's added NOCJKFONT to the project under Preprocessor Definitions | 19:08.17 |
| | I'm assuming this is the same as -DNOCJK ? | 19:08.42 |
| aashkar | hello all :) | 19:15.49 |
| | i need some help importing mupdf android code to android studio and not eclipse | 19:16.17 |
| | can somebody help me doing this please? | 19:16.35 |
| | it would be much appreciated | 19:16.46 |
| tor8 | aashkar: we only use the command line to build for android. | 19:16.54 |
| | so I'm afraid you're on your own. | 19:17.07 |
| aashkar | but do you have any idea whether its even possible to use android studio? because i succeeded to do it in eclipse but not in android studio | 19:17.51 |
| tor8 | I have no idea. Does it use ndk-build and ant build files? | 19:18.11 |
| aashkar | i tried to use ndk-build and then import it as a project | 19:18.39 |
| tor8 | if not, it should be fairly easy to set up a new build. we don't do anything fancy. | 19:18.40 |
| Robin_Watts | aashkar: until recently android studio was in flux for native builds. | 19:18.51 |
| | I understand that that has been resolved now, but we haven't gotten round to looking at that yet. | 19:19.10 |
| | It is on our list. | 19:19.15 |
| kent3116 | tor8: I asked a question about getting a page as a PNG image stream - I realised overnight that I may be asking the question the wrong way. Ultimately, I want a PNG image in an unsigned char * buffer to pass back. | 19:19.43 |
| Robin_Watts | But as Tor says, it's a standard ndk-build then ant process, so it shouldn't be hard. | 19:19.44 |
| | kent3116: Hi | 19:20.22 |
| kent3116 | I've been digging through the example in the mudraw.c code - which outputs it as a stream to stdio | 19:20.28 |
| aashkar | aha, ok got it, ill try again, thanks a lot | 19:20.32 |
| kent3116 | Hi Robin. | 19:20.33 |
| Robin_Watts | mudraw.c shows how to get stuff out as pngs, as you've found. | 19:20.43 |
| tor8 | kent3116: fz_write_pixmap_as_png will write a PNG to a fz_output. if you create a fz_output that writes to a fz_buffer, you can then get the bytes from the fz_buffer | 19:21.19 |
| Robin_Watts | the functions do things like: fz_write_png_header() , fz_write_png_band etc | 19:21.32 |
| | What tor said. | 19:22.03 |
| Robin_Watts | reboots. | 19:22.23 |
| kent3116 | Yup - I found them. So, just redirect the output to my own output and store in memory. I've done this before, I'll just need to find the code. | 19:23.13 |
| NCS_One | hi | 19:42.34 |
| 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. | 19:42.34 |
| NCS_One | any link about printer pdf interpreters? | 19:42.59 |
| Robin_Watts | NCS_One: I don't understand the question. | 19:46.08 |
| | This channel is for people using Ghostscript (or MuPDF). | 19:46.24 |
| | Ghostscript is a Postscript interpreter (with PDF, XPS etc support). | 19:46.44 |
| | And yes, it ships in *some* printers. | 19:46.50 |
| NCS_One | Robin_Watts: right, any links about those printers tha ship with ghostscript? | 19:47.25 |
| Robin_Watts | commercial restrictions apply to what we can say. But artifex.com has a partial customer list. | 19:47.59 |
| NCS_One | Robin_Watts: thanks | 19:53.39 |
| | Robin_Watts: off-topic: I need to print some documents and they need to look the same no matter the printer DPIs. What format you recommend? | 19:54.40 |
| Robin_Watts | NCS One: PDF. | 19:56.12 |
| NCS_One | thanks again | 19:57.43 |
| tor8 | Robin_Watts: a handful of commits on tor/master (ignore the WIP ones) | 20:29.15 |
| Robin_Watts | pdf_drop_document change is going to need changes in android/ios/jni too, right? | 20:50.26 |
| | maybe not | 20:54.43 |
| tor8 | Robin_Watts: I hope not... | 20:55.25 |
| Robin_Watts | grep didn't find it. | 20:55.38 |
| | tor8: All look plausible. | 20:56.43 |
| tor8 | Robin_Watts: cool, thanks. | 20:58.04 |
| | now for the boring bit ... doing the same in Java :/ | 20:58.35 |
| | Robin_Watts: gah. how to differentiate new Document("PDF") from new Document(filename).... | 21:30.17 |
| | no such thing as enums in javascript | 21:30.45 |
| Robin_Watts | new Document(int) and have constant values defined? | 23:02.13 |
| tor8 | that won't sit well with fz_register_document_handlers | 23:02.40 |
| Robin_Watts | tor8: Have the int be 'PDF0' ? | 23:04.11 |
| | and have that value be part of the struct that fz_register_document_handler registers? | 23:04.33 |
| tor8 | or have a global function loadDocument instead of new Document for the filename case | 23:05.35 |
| | that'll be ugly for java though | 23:05.48 |
| | Robin_Watts: http://fpaste.org/331963/45687489/ ... and with mvrhel's resource stuff added in | 23:28.33 |
| Robin_Watts | nice. I'm off to bed in a mo. | 23:29.14 |
| mvrhel_laptop | tor8: cool! | 23:39.02 |
| | Forward 1 day (to 2016/03/02)>>> | |
IRC Logs