| | <<<Back 1 day (to 2015/04/08) | 20150409 |
| kens | Well for me 695916 does not render correctly on current master, when rendered to the Windows display device. I was cutting the file down yesterday, but its slow going, it decompresses to 320 Mb. | 07:01.02 |
| tor8 | chrisl: "plain text switch" reading comprehension fail... | 08:46.41 |
| | I wonder if the error isn't related to which font actually gets picked up, considering that it's using /Identity-H | 08:47.34 |
| | [<00310044>-13.3<0050>19.5<0048>-1.2<001D>-10.6<0003>]TJ in your cut down example, the <00310044> string looks like it could very easily go wrong | 08:48.08 |
| kens | Hmm, I'm not picking this up as a CIDFOnt at all, that's kind of bad | 08:49.18 |
| chrisl | tor8: it is related to the font subsitution. On linux we substitute a TTF, which ends up a CID Type 2, on Windows (by default) we fall back to using one of the URW Type 1 fonts | 08:49.19 |
| kens | Well, when txtwrite sees the text_process, the font type of the current font is type 1, so its NOT a CIDFont as far as txtwrite is concerned. | 08:50.45 |
| tor8 | the ToUnicode map looks complete enough though. I'm not sure whether that's used in txtwrite? | 08:50.53 |
| kens | I wonder what pdfwrite makes of it | 08:51.00 |
| | tor8 yes it is | 08:51.06 |
| chrisl | tor8: the problem is that with the Type 1 descendant, twtwrite is treating as a single byte font | 08:51.36 |
| kens | But if we process the font as a type 1, its 1 byte character codes, and the ToUnicode map has 2 byte codes | 08:51.37 |
| tor8 | kens: yeah, I vaguely remember talking about this when I added using a reversed ToUnicode map to handle this case of missing fonts with Identity encodings | 08:51.52 |
| | kens: that sounds like a plausible explanation, if the gs machinery loads up the substitute as a type1 where it's expecting a type42 | 08:52.37 |
| kens | tor8 I'm not at all sure what's happening yet. | 08:52.56 |
| | But when txtwrite sees the font, its not seeing it as a CIDFont/composite font at all | 08:53.17 |
| | Even the 'text_begin' routine isn't seeing it as a CIDFont | 08:53.51 |
| | And indeed pdfwrite is seeing the same thing | 08:55.40 |
| | Ah, but later pdfwrite sees a type 0, so it must be doing something clever | 08:56.41 |
| chrisl | kens: I think in txtwrite_process_plain_text() you'll have to call the font's next_char_glyph() method, and if the fstack.depth >= 0 , then call txtwrite_process_cmap_text() instead - or something like that...... | 08:56.47 |
| kens | chrisl possibly, I'm just going to track thorough pdfwrite and see how it deals with iut, apparently it does. | 08:57.17 |
| chrisl | That seems to be how the "normal" code differentiates, in these cases | 08:57.22 |
| | In fact, I think not using the next_char_glyph() method is not good, anyway | 08:58.19 |
| kens | Hmm, the first call is a stringwidth | 08:59.31 |
| | Odd. When I use pdfwrite there is one stringwidth followed by a text_begin with a type 0 font. WHen I use txtwrite there are 2 stringwidth calls, then a text_begin with a type 1 font | 09:01.58 |
| | It kind of looks like the PDF itnerpreter is dealing differently with the devices. | 09:02.28 |
| chrisl | I'd be surprised..... | 09:03.09 |
| kens | I wouldn't be necessarily | 09:03.58 |
| | Ah, it seems to be because there is no current point at the time the stringwidth executes, which txtwrite treats as an error. Instead it should set an arbitrary point (at least, that's what pdfwrite does) | 09:07.46 |
| chrisl | kens: the stringwidth is probably down to the scaling we do during subsitution | 09:17.25 |
| | You probably want to focus on the ashow call | 09:17.42 |
| kens | Possibly, its definitely screwing up the font handling, because txtwrite is returning an error code | 09:17.45 |
| | Resolving teh stringwidth problem means I now get a type 0 font in the text_process | 09:18.06 |
| | And teh result of txtwrite is now 'Name:' | 09:18.29 |
| chrisl | Yay! | 09:18.34 |
| kens | Which I think means its fixed | 09:18.36 |
| | So that's an oversight in the original txtwrite code, I should be handling stringwidth as a 'default' operation, if I do that, its all OK. | 09:19.19 |
| | I'll commit that in a minute | 09:19.25 |
| | Well, I like our text output *much* better than Acrobat's | 09:29.54 |
| chrisl | Acrobat's is pretty dumb | 09:31.46 |
| kens | Yeah and with this file it really shows. The fiueld names end up with the wriong field data next to them | 09:32.14 |
| | Whereas ours comes out nicely lined up | 09:32.33 |
| chrisl | As I said, Acrobat just dumps the contents of the text operators as they are encountered in the input. There's no spacial ordering at all | 09:33.12 |
| kens | I cna understand that, its simple and easy to do. But I think that anyone dealing with forms should vastly prefer ours. | 09:33.46 |
| | IUnstead of complaining that our output isn't the same as Acrobat. | 09:33.59 |
| chrisl | Hopefully, with the character codes sorted out, he'll go away...... | 09:34.46 |
| kens | Not for long probably. He definitely looks like a free-loader, want to bet they are planning to use GS to do automatic text extraction from medical forms ? | 09:35.40 |
| chrisl | Very likely - good luck doing that with the Adobe output! | 09:36.29 |
| kens | Exactly! | 09:36.36 |
| | I'm going to put a pointed reminder in the bug thread about the licencing. | 09:36.57 |
| chrisl | Anyway, if he does pop up again, hopefully it will be not really a bug, and we can let Ray reply to it again ;-) | 09:37.21 |
| kens | LOL | 09:37.31 |
| | I htought I was getting pretty pointed in my replies..... | 09:37.51 |
| chrisl | Well, I must admit, I was pretty p*ssed off when it turned out there really was a problem | 09:38.14 |
| kens | Well I can't claim the txtwrite device is terribly well tested. | 09:38.43 |
| chrisl | No, hence why I thought it worth looking at, rather than leaving to fester | 09:39.37 |
| kens | Yeah, thanks for looking, I would have got there myself eventually. I was worried the monster customer file would take longer to reduce than it did. | 09:40.40 |
| chrisl | It was a "pleasant" distraction from Windows installer and sprintf stuff..... | 09:41.30 |
| | Now I have to head out for some supplies - back in ~1/2 hour....... | 09:42.10 |
| kens | Well I think I may actually be back to the point I was last Thursdat, ready to tackle device subclassing again. I'll probably just about manage to get it rebuilt and another customer bug will pop up | 09:42.19 |
| sam__ | hi need to know anyways to speed up pdf to jpg conversion using ghostscript | 09:50.38 |
| kens | sam__ : Perhaps you shold first tell us why you think its slow | 09:51.13 |
| | As well as which version you are using, on which OS< and with what command line | 09:51.31 |
| sam__ | GPL Ghostscript 9.16 , OS RHEL , | 09:53.09 |
| kens | Good start, current code :-) | 09:53.25 |
| sam__ | basically i have two option either to use graphicsmagik or using gs directly but may be i'm using simple gs -sDEVICE=jpeg -sOutputFile=<output file> -dLastPage=1 <input file> | 09:54.52 |
| | my objective to get thumbnail image | 09:55.00 |
| kens | Well you haven't specified a resolution | 09:55.13 |
| | or image size | 09:55.19 |
| | Is there a reason you want JPEG ? JPEG compression will likely cuase visible artefacts in a thumbnail, have you considered PNG ? | 09:55.46 |
| | You could also (as I'm sure Robin_Watts will point out, use MuPDF instead, provided you only want to deal with PDF as an input | 09:56.30 |
| sam__ | yes png format will still do fr me but i can see a clear difference of speed when i generate from image file and from pdf file of same size | 09:56.52 |
| kens | Not sure what you mean there. | 09:57.13 |
| Robin_Watts | sam__: "When you generate from image file and from pdf file of same size" ? | 09:57.23 |
| kens | Perhaps you could put a file or tow publicly and we could look at those. | 09:57.47 |
| sam__ | I mean while providing input from pdf i takes more time | 09:58.12 |
| kens | PDF ahs to be interpreted and then rendered. If you start with an image file, you just save the image. Naturally that's faster | 09:58.43 |
| sam__ | k got the point | 09:59.31 |
| | so what prefereble to go with Graphicsmagik that internally delegates the job to ghostscript or go for ghostscript directly ,are there any performance benefit | 10:01.24 |
| kens | If you use Ghostscript directly it will be faster, provided you tell it to create the image at the size you want. Otherwise you will have to resize it ,and GS won't do that, you will need to use ImageMagick or similar | 10:02.14 |
| sam__ | are there any JAVA wrapper library for GS mine is a JAVA system I can spare the job of writing JNA/JNI implementation | 10:03.58 |
| kens | Hmm, there might be..... | 10:04.15 |
| | Have you googled ? | 10:04.22 |
| | *we* certainly don't supply any such thing | 10:04.32 |
| tor8 | Robin_Watts: I've also uploaded a source tarball for 1.7rc1 | 10:04.38 |
| kens | sam__ : THere's something called Ghost4J | 10:04.56 |
| sam__ | thanks buddy let me check that out | 10:05.22 |
| Robin_Watts | tor8: I had done that, I think. | 10:10.20 |
| kens | embarks on a hunt for roasted coffee beans | 10:11.08 |
| tor8 | Robin_Watts: "make tarball" on unix will assemble a clean tarball from git, regardless of how much junk is in your working directory | 10:12.34 |
| | but I already did that and uploaded it | 10:12.45 |
| Robin_Watts | tor8: I did a clean git clone, and removed the .git files from it. | 10:13.11 |
| tor8 | ah, I see you have one in downloads/archive just not on the downloads landing page | 10:13.14 |
| | Robin_Watts: that should be equivalent | 10:13.50 |
| Robin_Watts | Go with yours (as long as it has all the submodules stuff in etc) | 10:14.02 |
| tor8 | as long as you don't end up with windows line endings :) | 10:14.11 |
| | Robin_Watts: it does. the 'make tarball' builds out of the box. | 10:14.34 |
| Robin_Watts | great. | 10:14.43 |
| tor8 | it's in scripts/archive.sh, with a lot of hackery to make 'git archive' recursive | 10:14.59 |
| | and give the output a proper version name automatically, etc | 10:15.11 |
| | Robin_Watts: ah, I think I see the problem. the symlink in downloads/ points to a non-existent file so it doesn't show up in the listing | 10:18.37 |
| | all fixed now | 10:18.52 |
| kens | MuPDF Stack Overflow question: | 10:30.43 |
| | http://stackoverflow.com/questions/29531400/mupdf-fit-to-screen-issue-android | 10:30.43 |
| Robin_Watts | Not touching that with a bargepole. | 10:31.23 |
| kens | I don't even know where to start | 10:31.45 |
| Robin_Watts | clearly, neither does he. | 10:32.23 |
| kens | He's not alone, the question references another question where a whole herd of them are milling around aimlessly | 10:32.54 |
| Robin_Watts | If he is so obviously incapable of neatly defining the question he wants to ask, he is going to be incapable of understanding any reply he might get. | 10:34.52 |
| paulgardiner | A bit odd. The referenced question says alter measureView. He says "I tried that but I think I also need to alter measureView". | 10:35.12 |
| kens | THis is not unusual on Stack Overflow..... | 10:35.13 |
| Robin_Watts | Ok, printing landscape pages via gsview does not work well. | 10:48.32 |
| paulgardiner | What is "fit to screen"? We currently look to be making the page as large as possible while still all being visible. | 10:52.07 |
| Robin_Watts | paulgardiner: Exactly. | 10:55.07 |
| | He's asking us to magically guess what he wants, and to produce some code that will do it for him. | 10:55.26 |
| | It's a can of worms, don't open it. | 10:55.35 |
| paulgardiner | There's one simple guess I could try | 10:55.52 |
| chrisl | There are sometimes two options: fit the page to the screen, or fit the marking operations to the screen - generally just means selecting the "box" from the PDF | 11:07.06 |
| Robin_Watts | chrisl: Or they might mean fit width. | 11:09.21 |
| | I went through this with someone on here at length a few weeks back. | 11:10.21 |
| | and just trying to get a straight answer about what he wanted was soul sapping. | 11:10.41 |
| chrisl | Oh, I agree, leave well alone - it's like trying to give a Ghostscript command line to relative of Kermit the Frog.... | 11:11.49 |
| Robin_Watts | tor8: Mail from customer last night has lead me to see that we (I) had the sense of the tests inverted in windows mupdf. | 11:16.49 |
| | commit on robin/master to fix it. | 11:16.54 |
| | The question is, is the behaviour of fz_meta sane, or should be alter it? | 11:17.15 |
| Robin_Watts | runs. | 11:17.45 |
| tor8 | Robin_Watts: fz_meta is in need of an API overhaul | 11:37.37 |
| | it's way too tricky to explain and use | 11:37.46 |
| | for starters I'd add a separate fz_has_permission call | 11:42.07 |
| | secondly, I'd make a specific metadata (title, author, etc) string -> string lookup, int fz_meta_data(doc, const char *key, char *value, int value_size) | 11:43.05 |
| | or fz_meta_info rather | 11:43.19 |
| | and I'd possibly use that for the 'crypt' and 'format' selectors as well | 11:43.47 |
| | or have separate functions for those as well | 11:43.58 |
| | or use a separate syntax for the FZ_META_INFO, maybe "info:author", "info:title" to go with "crypt" and "format" string selectors | 11:44.53 |
| | I really don't like the inout buffer for passing and reading keys for FZ_META_INFO | 11:45.51 |
| kens | Hmm, looks like a cluster network problem, how annoying | 12:34.26 |
| Robin_Watts | tor8: I kinda like the idea of offering friendly API functions that map down to fz_meta underneath. | 12:56.41 |
| kens | Robin_Watts : do you have any idea what's wrong with the cluster, or how to fix it ? | 12:57.30 |
| Robin_Watts | kens: I suspect AWS glitches. | 12:57.58 |
| | s/glitches/glitched/ | 12:58.08 |
| | it should restart itself after a few minutes. How long has it been down? | 12:58.22 |
| kens | Yeah, I guesses that, but it doens't seem to want to recover | 12:58.27 |
| | : Robin_Watts Not exactly sure, several minutes htough | 12:58.43 |
| Robin_Watts | clustermaster is still running. | 12:59.33 |
| kens | I guess I just need to wait longer then | 12:59.41 |
| Robin_Watts | have you tried clusterpush.pl abort ? | 13:00.22 |
| kens | Hmm, no I can try that now | 13:00.28 |
| | Or actually no I can't because I can't run Perl | 13:00.55 |
| Robin_Watts | ooh, something happened. | 13:00.56 |
| | It's restarted. | 13:01.06 |
| kens | I guess it recovered all by itself | 13:01.08 |
| kens | should have more patience | 13:01.23 |
| mvrhel_laptop | kens so 695916 does not render correctly for you? I tried ppmraw (marcosw command line) and tiff24nc and it looked fine | 15:40.53 |
| kens | mvrhel_laptop : No, using current master code, 32-bit debug build, the 'greenish' area is rendered incorrectly | 15:41.18 |
| mvrhel_laptop | oh 32 bit | 15:41.26 |
| | hmm let me try that | 15:41.31 |
| kens | Yeah I think I said that in the thread | 15:41.33 |
| | I have not tried 64 bit | 15:41.39 |
| | The Earth image is fine of course | 15:41.50 |
| marcosw | mvrhel_laptop: it fails on 64 bit for me. | 15:42.09 |
| kens | Also,I was using the Windows display device, I can try ppmraw | 15:42.19 |
| mvrhel_laptop | does it go away with a 64 bit builed? | 15:42.46 |
| kens | I have no tried | 15:42.56 |
| | I may have one, just a moment | 15:43.03 |
| | No, for me the relelase Windows 64-bit binary, going to display device renders the file incorrectly | 15:44.01 |
| mvrhel_laptop | ok this fails for 64 bit for me too | 15:44.54 |
| marcosw | valgrind does report an issue with uninitialised variables in gs_state_update_pdf14trans (gstrans.c:169) | 15:45.00 |
| mvrhel_laptop | weird that the other one rendered fine | 15:45.02 |
| kens | ppmraw doesn't work for me either | 15:45.15 |
| | If its an unitialised variable that could explain the variation | 15:45.38 |
| mvrhel_laptop | ye | 15:45.47 |
| | marcosw: can you add the valgrind report | 15:46.03 |
| | to the bug | 15:46.07 |
| marcosw | sure, itâs not very long (unsual for valgrind :-) ) | 15:46.21 |
| mvrhel_laptop | oh its just the above | 15:46.31 |
| kens | If you need to you can probably simplify the path, I stopped there because I would have had to go to ahnd-editing the PDF content stream after that | 15:46.32 |
| mvrhel_laptop | ok | 15:46.33 |
| | line 169 would be an odd one to have uninitialized parameters.... | 15:48.03 |
| kens | says 292 of gx_enum_image_being for me | 15:50.16 |
| | gs_state_update_pdf14trans is the ultimate parent isn't it ? | 15:50.35 |
| mvrhel_laptop | I am going to dump the transparency stack images as they are created to see if I can find where it is going wrong | 15:51.40 |
| | have not had to this in a while | 15:52.03 |
| kens | FWIW removing the overprint made no difference to the output | 16:01.14 |
| | OOps maybe not | 16:01.38 |
| | Ah, if I remove the /op instead of the /OP the problem does go away | 16:02.08 |
| mvrhel_laptop | so def an overprint issue | 16:03.06 |
| kens | I can, however, remove the image (manually) and the problem still exhibits | 16:03.10 |
| mvrhel_laptop | oh please do that | 16:03.19 |
| kens | So yes, its overprint and a page Group causing the problem | 16:03.24 |
| mvrhel_laptop | that has the soft mask in it | 16:03.27 |
| | transparency dump did not revel anything in particular | 16:03.48 |
| kens | mvrhel_laptop : Its easy, just look for Im0 in the onctent stream and replace /Im0 Do with spaces | 16:03.49 |
| mvrhel_laptop | ok | 16:04.02 |
| kens | Rather than me uploading a 4Mb fikle with practically no differences :-) | 16:04.22 |
| mvrhel_laptop | :) | 16:04.26 |
| kens | There's still a bunch of 'HiddenLayer' rubbish in here, look s like its all from Adobe Illustrator | 16:05.34 |
| rayjj | mvrhel_laptop: getting close on the transfer function fix. The file I created with the TR in the PDF works now. Now I have to fix the case where the default transfer function is non-identity | 16:06.13 |
| mvrhel_laptop_ | I have to step out for a bit. will beat on this more when I return. Thanks so much for cutting down the file kens | 16:08.35 |
| kens | NP, I'm off now too, got to move some furniture | 16:08.47 |
| mvrhel_laptop | rayjj that is great | 16:15.10 |
| rayjj | mvrhel_laptop: there is a comment in pdf14_cmap_rgb_direct_group (gdevp14.c ~line 5226) that mentions CIEcolor, CRD's and says "We will fix these issues with the ICC based color architecture" Can I get rid of that comment ? | 16:20.27 |
| mvrhel_laptop | rayjj yes | 16:25.25 |
| rayjj | mvrhel_laptop: thanks | 16:25.37 |
| | mvrhel_laptop: I'm inclined to do the "fix" first, separate from the "enhancements" for section 7.6.4 | 16:32.42 |
| mvrhel_laptop | rayjj yes | 17:00.31 |
| rayjj | mvrhel: (for the logs): please review the fix for bug 695904 on my repo | 17:57.27 |
| | mvrhel: This is just the fix for the customer issue, and does not alter the behavior w.r.t. the business of ignoring the xfer function under the condition discussed in 7.6.4 | 17:58.40 |
| | now I have to back port the fix to the customers older/odder code (mostly 9.06 based)... | 17:59.17 |
| fredross-perry | gsview - fixed two bugs (1) Linux: files not opened via command line. (2) all: files opened via command line have badly-sized window. | 18:29.34 |
| henrys | first batch of soylent ordered ;-) | 18:29.38 |
| fredross-perry | I hear itâs peoâ oops. Iâve said too much. | 18:30.02 |
| | mvrhel_laptop: any gsview feedback? | 18:31.07 |
| henrys | I already feed on this pond scum http://www.gardenoflife.com/Products-for-Life/Foundational-Nutrition/RAW-Meal.aspx ... this might actually be an improvement... | 18:31.39 |
| mvrhel_laptop | ok, so I have found where the overprint stuff is going wacky and it has to do with the attempt at simulating overprint of the spot colors | 23:26.18 |
| | when we dont really have that spot color | 23:26.28 |
| | something that I really think I should pull out of the code | 23:26.44 |
| | Forward 1 day (to 2015/04/10)>>> | |
IRC Logs