| | <<<Back 1 day (to 2016/09/05) | 20160906 |
| winny | when downscaling images in a pdf, I am getting this error: Subsample filter does not support non-integer downsample factor (5.559406) -- is it possible to tell gs to pick the closest integer? | 00:26.11 |
| sebras_ | tor8/robin: a luminosity, device, jni and archive commits pending review on sebras/master. | 03:27.54 |
| | I forgot to test compile after the last round of changes. will do when I return home. | 04:36.12 |
| fnodeuser | you should enable HTTPS (TLS v1.2 only) for all your websites, and http connections should be redirected to https, it would be good also to start signing the source code releases and to start using xz instead of gz | 07:11.34 |
| irctc868 | Hi | 07:56.57 |
| 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. | 07:56.57 |
| irctc868 | The product works good for me, Thanks for this muPdf . | 07:58.26 |
| | I have one small Question | 07:58.43 |
| | I want to add a Small View like its Imageview or VideoView , Bind in some specific page on perticulat X,Y,Widthand Height. | 07:59.41 |
| | Is it possible for current muPdf code ? | 08:00.11 |
| Robin_Watts | irctc068: There is no support for that in the current code. | 08:25.06 |
| | But it would be a change that needed to happen purely in the Android layers, AIUI. | 08:25.24 |
| irctc771 | hi | 10:04.27 |
| 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. | 10:04.27 |
| Robin_Watts | irctc771: Hi. Don't wait for a response to a greeting before you ask questions, or you'll be here all day :) | 10:32.09 |
| tor8 | sebras: in the colorspace alpha-only commit. svg_dev_stroke_color is sending fill="none", I assume you wanted stroke="none"? | 11:36.00 |
| | sebras: JNI check arguments and throw. get_context() has weird line breaks. | 11:42.31 |
| | when NewStringUTF, does that not set an exception? | 11:43.01 |
| | jni_throw_null(env, "path is null"); I thought you wanted jni_throw_arg(env, "path argument may not be null") there? | 11:44.30 |
| | handle exceptions from JVM properly: to_ColorSpace does if (ExceptionCheck) throw_java(); if (!jobj) throw_java(); ... combine into one if-expression? | 11:57.22 |
| | delete local references to text span font: "jont"? | 12:02.18 |
| sebras | tor8: hm... about jni_throw_null() and NPEs in general. | 13:57.58 |
| | tor8: when I read the docs for that exception it seems like it is clearar to actually use illegal argument exception. | 13:58.23 |
| tor8 | sebras: yes, with an "argument 'foo' must not be null" message of sorts | 14:00.18 |
| sebras | tor8: but e.g. Boolean.compareTo() throws NPE upon a null argument. | 14:00.21 |
| | tor8: so it seems as if there is no clear consensus. | 14:00.36 |
| tor8 | I think, if you're going to mention an argument, using IAE rather than NPE would be nicer. | 14:01.57 |
| | an NPE comes from trying to dereference a null value, so would really happen at a lower level if mupdf was implemented 100% in java | 14:02.51 |
| sebras | tor8: hm... where in the xps spec does it say that you can even have the fill-attribute contain "none"? | 14:21.08 |
| | I remember having seen it, but now I can't find it again. | 14:21.31 |
| tor8 | sebras: this is svg though | 14:25.24 |
| sebras | tor8: it is quite possible that is the reason I cannot find anything useful in the specification... | 14:37.03 |
| | ?-) | 14:37.05 |
| | tor8: ok. so re: svg_dev_stroke_color()... the default value for fill is "black" while the default value for stroke is "none". | 14:42.11 |
| | so when there is no colorspace there is no need to print stroke="none". | 14:42.26 |
| | you still need to print fill="none" though as it otherwise would be filled black.. :-/ | 14:42.44 |
| tor8 | sebras: right. | 14:48.23 |
| | it just looked confusing :) | 14:48.32 |
| sebras | tor8: took me some time to sort out too (mostly because I was reading the wrong spec) | 14:51.48 |
| | tor8: and what where the weird line breaks in get_context()? | 14:52.23 |
| | tor8: oh.. the trailing } | 14:53.01 |
| | tor8: I have updated sebras/master according to your comments. LGTY? | 14:59.00 |
| tor8 | sebras: looking better. will give it another thorough review tomorrow. | 15:01.52 |
| sebras | tor8: ok. I attempted to separate concerns and make them easier to review. unfortunately I ended up with rather many commits. :-/ | 15:03.53 |
| | tor8: how is the PDFAnnotation skeleton coming along? should I be looking into that next? | 15:04.33 |
| | tor8: or you are busy working on that? | 15:04.53 |
| tor8 | sebras: I think you should be able to start working off the ideas in the WIP commits on tor/master | 15:05.50 |
| sebras | tor8: alright. | 15:06.21 |
| | tor8: what about my old patches for Path.bound and Path.transform for js? | 15:08.10 |
| | tor8: also the device hint flags for conditionally expanding ligatures and whitespace. | 15:09.33 |
| tor8 | path.transform should not be public | 15:10.01 |
| sebras | tor8: and the event handling from annotation widgets back into java-land. | 15:10.21 |
| | tor8: ok. why? | 15:11.10 |
| | tor8: protected? | 15:11.18 |
| tor8 | it's private, and should not exist for JNI either. paths should be create-once then immutable. | 15:11.34 |
| sebras | tor8: oh, so you'd accept a patch to remove Path.transform from the JNI rather than adding it to js, in that case. | 15:12.20 |
| tor8 | yes. | 15:12.27 |
| Robin_Watts | tor8: That's not in keeping with the C. | 15:12.33 |
| sebras | tor8: and then the separate patch for Path.bound would be ok..? | 15:12.34 |
| tor8 | yes, I guess that one could go in. | 15:12.45 |
| Robin_Watts | The C does NOT have immutable paths. | 15:12.47 |
| | With C you create a path, then transform it. | 15:13.43 |
| | We don't have a method to make us a new path from an old path with a transform applied. | 15:13.58 |
| tor8 | Robin_Watts: it's the usual use case. we have fz_transform_path used in *one* place (okay, two, since you added svg) where XPS creates it and then applies a post-creation transform | 15:14.00 |
| Robin_Watts | tor8: For device outputs, we may want it. | 15:14.39 |
| tor8 | Robin_Watts: the XPS code could just as well pre-transform the individual path control points; but the XPS path parsing code is a gnarly mess due to how the spec is written | 15:14.43 |
| Robin_Watts | (I was writing this bit of the book the other day :) ) | 15:14.48 |
| tor8 | Robin_Watts: then it should be a copy-path-with-applied-transform function that's public | 15:15.00 |
| Robin_Watts | tor8: Right, but we have no such function in MuPDF yet. | 15:15.18 |
| sebras | Robin_Watts: so this prompts us (err... me?) to write one? | 15:15.55 |
| tor8 | the svg device uses the existing fz_transform_path to transform the path when creating svg font glyphs | 15:16.08 |
| | fz_transform_path should, IMO, make a copy (and then we can have an internal fz_apply_transform_to_path function for use with XPS and the SVG font emission) | 15:18.00 |
| sebras | tor8: in the call to fz_outline_glyph() why are we passing fz_identify, if we want to shift it to some x/y coordinate later on? | 15:18.20 |
| tor8 | sebras: because we don't know how much to shift it until afterwards... | 15:18.41 |
| sebras | tor8: right. | 15:19.04 |
| tor8 | I wonder if we can get SVG to apply the shift by setting some transform="" attribute on the <path> tag instead | 15:19.40 |
| | Robin_Watts: I just don't want java programmers thinknig they can get away with transforming paths that reside in a display list | 15:20.47 |
| Robin_Watts | tor8: Sure, but we can test for that easily enough. | 15:21.07 |
| | If you try to transform a packed path it throws an exception. | 15:21.16 |
| | if you try to transform a path with a ref count of > 1 then we could do the same. | 15:21.30 |
| tor8 | and then we'll be inundated with stackoverflow questions asking why we get an exception :) | 15:21.40 |
| Robin_Watts | tor8: The documentation is clear on this :) | 15:21.53 |
| tor8 | well, in that case I guess I could live with Path.transform | 15:22.07 |
| | sebras: so I guess you're off the hook, that patch can go in... | 15:22.20 |
| sebras | ok. | 15:22.51 |
| | tor8: I'll stick it on sebras/master in that case. | 15:22.59 |
| tor8 | sebras: I'd hold off on the event callback thing. That is an area where I suspect I may need to rejig things. | 15:23.03 |
| sebras | tor8: right. | 15:23.22 |
| Robin_Watts | http://ghostscript.com/~robin/mupdf_explored.pdf | 15:23.23 |
| | ^ That's the latest version. | 15:23.32 |
| sebras | tor8: and the bitfields for expanding ligatures/whitespace? | 15:23.48 |
| tor8 | sebras: the expand ligature thing ... make them flags specialized for the stext-device. I don't think they belong with the generic device hints. | 15:24.13 |
| | and pass the flags in when creating the stext device | 15:24.23 |
| | though I'm not sure I understand why you'd want this behaviour | 15:24.51 |
| | if you want searchable text, you always want to expand the ligatures | 15:25.12 |
| | if you want raw text, the stext device is not what you want. | 15:25.27 |
| Robin_Watts | tor8: It's a question of what you want the output of the stext device for. | 15:25.50 |
| sebras | tor8: this relates to the tab infused text PDF that fred was mentioning. | 15:25.55 |
| tor8 | I've seen lots of people trying to use the stext structures to do more thorough analysis on the text | 15:26.03 |
| sebras | tor8: and I added an option to replace any unicode whitespace with a space character with variable width. | 15:26.20 |
| tor8 | where they'd be better off just going after the fz_device calls using fz_text | 15:26.28 |
| sebras | tor8: and then robin wanted to be able to conditionally turn these on/off. | 15:26.34 |
| sebras | reads. | 15:26.41 |
| tor8 | I would always turn them on. if you want that level of control, you're better off with a fz_device | 15:27.05 |
| Robin_Watts | I can't see what we gain by forcing people to write their own fz_device. | 15:27.34 |
| tor8 | maybe we should make a raw text device, which just gathers up the fz_text calls into a list | 15:27.36 |
| sebras | tor8: ligature expansion in stext is always on today. | 15:27.37 |
| Robin_Watts | Cos most people will not do that. | 15:27.43 |
| sebras | tor8: but nothing changes non-space whitespace into spaces at the moment. that was my suggestion of how to resolve the issues fred had. | 15:28.17 |
| Robin_Watts | having the stext device be able to enable/disable each step of it's processing would appear to cover the bases nicely. | 15:28.18 |
| tor8 | the stext devices loses a lot of information. for thorough analysis, you'll need the fz_font not just the fz_stext_style info which is all we keep | 15:29.15 |
| | it has looked to me like the people asking for this level of control are unhappy with the analysis stext-device does, and want to do some more analysis themselves | 15:29.50 |
| | in which case, they really ought to write a device of their own. but I can see your point in that being too intimidating. | 15:30.15 |
| | a list of fz_text objects + color + matrix on a page could do well enough? | 15:30.37 |
| | as a ready-made 'raw' text device | 15:30.48 |
| sebras | tor8: also I feel that the information we provide in stext does not match what fred wanted. (he wants to be able to match entire words in the text and then highlight succeeding words and ending on a certain word). | 15:30.59 |
| | tor8: maybe mupdf should cater to this use case? | 15:31.10 |
| tor8 | define 'match entire words' | 15:31.28 |
| sebras | tor8: whitespace delimited I think. | 15:31.45 |
| | tor8: whatever would feel a natural way to highlight text in an android app I probably his goal. :) | 15:32.09 |
| tor8 | for mouse-(well..touch I guess) selection? | 15:32.13 |
| sebras | tor8: yes. | 15:32.45 |
| | tor8: so basically he uses stext to extract the blocks/lines/spans and then looks for whitespace to delimit words and find the beginning and end words in that text flow. | 15:33.28 |
| | every word in between is highlighted. | 15:33.39 |
| tor8 | so he wants to subdivide the spans into words? | 15:34.10 |
| Robin_Watts | I would find it very annoying to only be able to select at the word level. | 15:34.12 |
| sebras | tor8: maybe the right approach is to supply a fz_text_selection_device? :) | 15:34.24 |
| Robin_Watts | Especially given that we guess where word breaks are in PDF :( | 15:34.30 |
| tor8 | Robin_Watts: with fat fingers on a clumsy touch screen, I think you're hoping for too much control :) | 15:34.34 |
| sebras | Robin_Watts: isn't that what fred does now..? | 15:34.38 |
| Robin_Watts | tor8: This is why you have selection handles generally on touchscreens. | 15:35.05 |
| sebras | tor8: actually my phone does normally support highlighting individual characters, but then it uses a caret with an offset hotspot to make it easier. | 15:35.29 |
| tor8 | sebras: we have fz_highlight_selection and fz_copy_selection for this very use case. | 15:35.41 |
| | why doesn't fred use those functions? or fix them if they're not to his liking. | 15:35.51 |
| | or is that level too generic, and he wants to get individual caret positions to snap to with selection handles? | 15:36.24 |
| sebras | tor8: he attempted to use fz_highlight_selection() but when when he fed in the rect for his selection the end result selected... too many words I think. | 15:37.27 |
| | I have a hard time remembering the issues (Robin do you remember?). | 15:37.45 |
| Robin_Watts | sebras: I never remember anything. | 15:38.06 |
| sebras | tor8: can you please explain your last question? I'm not sure I understand fully. | 15:38.41 |
| | tor8: I think fz_highlight_selection() is used when right clicking in the gl/x11 viewers. | 15:39.25 |
| | tor8: so it basically does block selection. | 15:39.32 |
| tor8 | like I said before, if a function almost does what you want but not quite, fix it rather than reimplement separately. | 15:39.32 |
| sebras | tor8: but fred wants traditional windows style selection where the selection mechanism knows about the concept of columns/blocks/lines/words. does that make sense? | 15:40.15 |
| tor8 | IMO block selection is the only reliable way to select stuff in PDF | 15:40.17 |
| | 90% of the time in more complicated PDF files, trying to do word processor style selection fails spectacularly and is worse than useless | 15:40.43 |
| | sebras: it makes sense, and he's free to fix fz_highlight_selection or split into two types of functions like fz_highlight_block_selection and fz_highlight_continuous_text_selection | 15:41.33 |
| sebras | tor8: well, fz_highlight_selection() relies upon stext anyway so the heuristics used there is the best that we can do (unless you write your own, smarter, stext-like fz_device). | 15:41.52 |
| tor8 | implementing that stuff in java just means nobody else (like iOS) can use that logic | 15:41.59 |
| sebras | tor8: this was back when you were on vacation. :) | 15:42.12 |
| tor8 | sebras: yes, so adding a continuous text selection function to go along with the block selection should be doable in C | 15:42.29 |
| sebras | tor8: indeed. so this is why I felt that stext or something should be changed. | 15:42.35 |
| tor8 | and then we wouldn't need to expose the whole guts of fz_stext_page and dependent classes | 15:42.44 |
| sebras | tor8: not for _this_ purpose anyway. | 15:43.03 |
| tor8 | I made these high level functions so that you wouldn't need to go digging through the fz_text_spans from java | 15:43.09 |
| | with the expectation than fred/mvrhel/whoever would expand as necessary | 15:43.26 |
| sebras | tor8: I know, I guess I failed in doing the right thing there. :-/ | 15:43.47 |
| | i.e. helping out in a constructive way. | 15:43.54 |
| Robin_Watts | I think it's important to allow the text spans to be accessed from java. | 15:44.58 |
| | We can't hope to foresee every use case, and to package up nice functions to make it simple. | 15:45.25 |
| sebras | tor8: but then we'd need to agree on what whitespace-delimited means. and whether we also delimit on punctuation. | 15:45.31 |
| Robin_Watts | So we need to offer the general case, IMAO. | 15:45.47 |
| sebras | tor8: hm.. maybe we can rely on unicode... classes. or whatever they are called. | 15:45.53 |
| tor8 | Robin_Watts: the stext structures aren't all that well designed, so not requiring people to use them for common cases would be good in the long run when we do figure out how they need to change. | 15:46.15 |
| | the way we access them is awkward at best | 15:46.29 |
| sebras | Robin_Watts: but mupdf core ought to cater for the most common use cases, and since this is our own app surely we should strive for making it easy. :) | 15:46.52 |
| Robin_Watts | The java methods for accessing them seem very natural. | 15:47.00 |
| tor8 | just look at fz_stext_char_at even needing to exist | 15:47.16 |
| | iterating over a stext with C is awkward and unnatural | 15:47.35 |
| Robin_Watts | sebras: Sure, have helper functions to wrap up common cases by all means, but we should never say that those common cases are the only way to work. | 15:47.51 |
| | tor8: Whereas it's entirely natural in java - it's just an array. | 15:48.08 |
| tor8 | Robin_Watts: the java code makes a copy of the arrays though, so in essence it's cheating. | 15:49.20 |
| Robin_Watts | tor8: That's the price you pay for naturalness. | 15:50.03 |
| tor8 | but it makes for a decent way to access it, but there's still no natural way to iterate over lines without spans getting in the way | 15:50.14 |
| | so text scanning algorithms like searching, creating highlights, etc, end up being more complicated | 15:50.38 |
| Robin_Watts | tor8: Well, if you want spans to be identified, it's unavoidable. | 15:51.07 |
| | We *could* push the style down into the char structure, and then lines would just be sets of chars | 15:51.49 |
| | and people would have to identify spans for themselves (by looking for runs of chars with the same styles) | 15:52.09 |
| sebras | tor8: one question that was raised back then was whether it would make sense for stext to provide finer granuality and attempt to split spans into "words" (using whatever whitespace/punctuation delimiting rules we decide are appropriate). | 15:52.18 |
| tor8 | or provide both, but store the chars in the line, and have the spans as an array with pointers into the array of chars in the line | 15:52.43 |
| Robin_Watts | but then you'd complain that we couldn't walk the entire flow of text without lines getting in the way :) | 15:52.47 |
| tor8 | or indexes | 15:52.48 |
| sebras | tor8: and vieweing the entire stext device as a helper function for common cases of course since it is mostly a bunch of heuristics. | 15:52.52 |
| tor8 | Robin_Watts: working a line at a time is more natural, but yes, a block at a time would probably be best in the long run | 15:53.17 |
| Robin_Watts | tor8: Whatever structure we pick will be imperfect in some cases. This is at least pretty simple and as compact as we could hope it could be. | 15:54.01 |
| tor8 | the problem is that we don't know what is a line and what is a paragraph or a list item, etc. | 15:54.16 |
| | so trying to do too much is not good either | 15:54.26 |
| | I'm a bit disappointed that fred wrote the TextSelector stuff in the mupdfdemo java code rather than getting that algorithm into the mupdf c core where iOS and the desktop viewers could use it. that's all. | 15:56.22 |
| Robin_Watts | tor8: I'm not convinced that's not the right place for it to be written. | 15:59.49 |
| sebras | Robin_Watts: but then shouldn't stext also be written in the app (instead of in the lib)? | 16:00.39 |
| Robin_Watts | sebras: The point is that the text selection code is something that licensees might want to tweak. | 16:01.14 |
| | Licensees are going to be much more amenable to tweaking some java code than to having to dive under the JNI blanket. | 16:01.42 |
| sebras | Robin_Watts: agreed. but doesn't that means that if the heuristics in stext are not quite right for them, they'd need to tweak those parts too? | 16:01.55 |
| Robin_Watts | sebras: Which is why I argued for the bits to control the heuristics. | 16:02.16 |
| sebras | Robin_Watts: I don't know, maybe they'd like to have the concept of... columns? or something. :) | 16:02.27 |
| Robin_Watts | sebras: Then they can manipulate the stext structures in java. | 16:04.37 |
| tor8 | since we added unicode/glyph cluster maps and separate fonts to a single fz_text object, | 16:04.47 |
| | the difference between sturctured text and raw fz_text is not that big | 16:05.01 |
| Robin_Watts | tor8: Well, the big difference is that structured text is reordered. | 16:05.24 |
| tor8 | having each viewer implement selection logic separately means no viewer will behave the same... | 16:05.30 |
| Robin_Watts | tor8: should android apps and ios apps behave identically? | 16:05.55 |
| tor8 | Robin_Watts: we might want to think about not having separate structures? | 16:06.00 |
| | for considering which text is selected when pointing to the same parts of the page, I'd think so. | 16:06.19 |
| tor8 | foods. | 16:06.45 |
| Robin_Watts | tor8: Having the stext device return just fz_text things? | 16:06.46 |
| | I can't see that working. | 16:06.51 |
| ray_laptop | mvrhel_laptop: I am looking the file Bug694437.pdf and I see it handling the SMask what looks like twice when it does the "x9 Do". First it does the begintransparencymask and processes the SMask image, but then it passes the SMask as OpacityMaskDict into an ImageType 103 (zimage3x) | 16:10.29 |
| sebras | sleeps. | 16:40.33 |
| jelly2_ | I am trying to make a PPD which produces postscript for interpretation by ghostscript but my output is always rotated for pages with landscape dimensions. | 17:01.10 |
| | Can I change my PPD such that it doesnât end up rotated? | 17:01.17 |
| | I am using the WDK sample PPD. | 17:01.23 |
| mvrhel_laptop | ray_laptop: Sorry I missed your comment | 18:08.22 |
| ray_laptop | mvrhel_laptop: that's OK. | 18:08.47 |
| mvrhel_laptop | Confused. Are you looking at bug 694437? | 18:10.25 |
| ray_laptop | mvrhel_laptop: as far as I can tell the SMask for an image is processed BEFORE we ever begin the zimage3x (ImageType 103). I don't think the image3x ever actualy uses the data | 18:10.38 |
| mvrhel_laptop | ray_laptop: ^^ | 18:10.39 |
| ray_laptop | mvrhel_laptop: I'm looking at the file from that bug comparefiles/Bug694437.pdf | 18:10.59 |
| mvrhel_laptop | this is not the customer bug? | 18:11.21 |
| ray_laptop | the SMask has a error in the Flate data, and with the is_big_mask wrong, it processes and mostly ignores the error. When I fix is_big_mask (which I inadvertently pushed) the image3x fails and the transparency group never gets 'composed' | 18:13.21 |
| | mvrhel_laptop: so it looks like the image3x code really doesn't do anything | 18:13.42 |
| | I never see the mask data being used to actually change the data that is written (when I use a fixed file) | 18:14.57 |
| | I suspect that the image3x code was originally supposed to apply the SMask but it was abandoned | 18:16.05 |
| mvrhel_laptop | ray_laptop: My understanding of that code was that it was used when the softmask was part of the source image | 18:16.27 |
| | But my memory may be faulty | 18:17.06 |
| | ray_laptop: I thought it was used for the JPEG2000 images that had the SMaskInData entry | 18:20.24 |
| | ray_laptop: so we would want to add some information about the matte in pdf14_buf_s | 18:36.38 |
| ray_laptop | mvrhel_laptop: we need that when we do the begintransparencymask, right ? | 18:37.55 |
| mvrhel_laptop | ray_laptop: Yes that would make sense | 18:38.15 |
| | We will need to pack this stuff through the clist etc | 18:38.30 |
| Robin_Watts | tor8: As I was writing docs the other day, I noticed an inconsistency. | 18:44.58 |
| ray_laptop | mvrhel_laptop: I am going to rip out the convoluted nonsense in doimage so that it only creates the image3x (type 103) when the device says it want "PreserveSMask" | 18:45.27 |
| Robin_Watts | We have fz_unshare_stroke_state which ensures that an fz_stroke_state is changeable. We don't have such a thing for fz_paths. | 18:45.41 |
| | I wonder if we should have an fz_unshare_path. | 18:46.01 |
| mvrhel_laptop | ray_laptop: Ok. You know that better than me. | 18:46.05 |
| ray_laptop | mvrhel_laptop: I'll get rid of the is_big_mask altogether since we really don't need it | 18:46.53 |
| | Forward 1 day (to 2016/09/07)>>> | |
IRC Logs