| | <<<Back 1 day (to 2015/02/01) | 20150202 |
| chrisl_away | /away] | 07:29.45 |
| kens | Question for Robin_Watts and Tor: | 08:08.47 |
| | http://stackoverflow.com/questions/28262240/building-mupdf-and-registering-document-handlers | 08:08.47 |
| | Oh and maybe Michael :-) | 08:08.58 |
| Robin_Watts | has answered. | 08:58.58 |
| | Thanks kens | 08:59.09 |
| kens | Ah thanks Robin_Watts | 08:59.16 |
| Robin_Watts | http://www.theregister.co.uk/2015/02/02/raspberry_pi_model_2/ | 09:44.31 |
| kens | Yep, I saw it already | 09:44.39 |
| | chrisl the GPF with ps2write and CFF fonts is currently unfixable. It seems we don't handle CFF fonts in ps2write at all. If we encounter one in the course of a job it 'looks like' (I haven't checked thoroughly) we fall back to a type 3 capture. But we can't do that if we are already capturing a type 3 font or something. THe code which fails is in gdevpdtt.c, pdf_make_font_resource() around line 45, where we return an errod if we don't permit CFF fonts. | 10:23.01 |
| | As far as I can see the only solution to this is to create a new handler in OPDFread.ps which can convert a CFF fotn into a Type 1, on the fly, and written in PostScript (!) | 10:23.54 |
| | chrisl that should have been line line 1418 | 10:26.37 |
| chrisl | kens: That's odd, I don't see how we get to a CFF from that Type 3 font..... | 10:30.38 |
| kens | I'm not at all sure, but we seem to be using a base font of Helvetica | 10:30.56 |
| | Type 0->Type 3->Type 1 | 10:31.07 |
| | Or type 2 in the last stage if we have CFF fonts | 10:31.25 |
| chrisl | Hmm, you must be seeing a different crash from me...... | 10:31.41 |
| kens | qTHis one is 100% reliable for me. | 10:31.58 |
| | And I can see why its wrong too | 10:32.06 |
| | I can prevent the crash by adding a specific check | 10:32.42 |
| chrisl | Which Type 3 is in force at the time? For me it was /Type3Font6 | 10:33.07 |
| kens | Yes, that's the one | 10:33.12 |
| chrisl | Er, it doesn't use another font...... | 10:34.06 |
| kens | THat's what I thought, but the code is pretty clear that it does, it uses Helvetica | 10:34.28 |
| | How, I don't understand | 10:34.36 |
| chrisl | I'm looking at the BuildChar | 10:34.46 |
| kens | Yes I did that too | 10:35.01 |
| chrisl | It's just line work | 10:35.06 |
| kens | I know, but somehow its ending up with a type 3 and tehn switching to a type 1 | 10:35.33 |
| | Does it intersperse with Helvetica ? | 10:35.53 |
| chrisl | Hmm, I see: around line 5142 in the test file | 10:36.03 |
| kens | Ah right | 10:36.33 |
| chrisl | But I really don't see how that would cause a problem | 10:36.39 |
| kens | The problem is that we abort the processing (can't handle the font) but the code in pdfwrite then tries to fall back to the 'default handling' | 10:37.08 |
| | WHich would normally render it to an image. | 10:37.25 |
| chrisl | But surely that should happen with a Type 1 as well? | 10:37.31 |
| kens | No, we can embed a type 1 in ps2write output, so it doesn't fail | 10:37.54 |
| chrisl | So, in ps2write the fonts in the FDepVector are handled totally separately? | 10:38.36 |
| kens | In failing we end up sort of 'halfway' through processing a type 3, so we use the wrong fallback and try to capture the type 2 as a type 3 | 10:38.36 |
| chrisl | I thought in ps2write composite fonts *always* degenerated to Type 3 | 10:39.12 |
| kens | I don't currently understand how the composite glyp[h processing works, it takes 2 or 3 days to wrap my head round it every time | 10:39.14 |
| | chrisl yes they do. | 10:39.27 |
| chrisl | So, we'll never embed a Type 1 in this case | 10:39.41 |
| kens | I think we do yes | 10:40.00 |
| | Its a type 3 which uses a type 1 | 10:40.15 |
| | I'd have to check though | 10:40.22 |
| | Its taken me long enough to debug to this point | 10:40.30 |
| chrisl | I thought in ps2write all Type 0 fonts were emitted as (possibly multiple) "flattened" Type 3 fonts - that's why we really want a ps3write | 10:42.04 |
| kens | Type 0 fonts are emitted that way, yes. But the fact that we emit a type 3 doesn't stop us emitting a type 3 which uses a type 1 | 10:42.36 |
| | Like a Quark font for instance | 10:42.45 |
| | I'd have to cut the file down a lot tofigure out exactly what's happening | 10:43.31 |
| chrisl | But this isn't a Type 3 that uses a Type 1, it's a Type 0 with a Type 1 and Type 3 in its descendants | 10:43.43 |
| kens | We do embed Type1Font1 in the otuput | 10:43.47 |
| | chrisl like I said, I'm not entirely sure how all this works. | 10:44.12 |
| | Its hideously complex and convoluted | 10:44.20 |
| | It will take me several days to figure out what's going on, precisely | 10:44.34 |
| chrisl | Yes, that'll be because Type1Font1 is used on its own, as well as part of the Type 0 | 10:44.46 |
| kens | Yes, that's why I'd have to reduce the file | 10:45.03 |
| | I cna put together a quick patch which will resolve the crash, I don't really waqnt to embark on this particular saga until we know if its going to be necessary | 10:46.10 |
| | Will resolve the crash *I* see..... | 10:46.24 |
| chrisl | It's almost certainly the same cause as the one I see | 10:47.55 |
| kens | If you want to try it, at line 3252 in gdevpdtt.c just after: | 10:48.46 |
| | if (code == gs_error_invalidfont) /* Bug 688370. */ | 10:48.46 |
| | return code; | 10:48.46 |
| | Add: | 10:48.46 |
| | if (code == gs_error_undefined && pte->current_font->FontType == ft_encrypted2) | 10:48.46 |
| | return code; | 10:48.47 |
| | grr, just a mo | 10:48.53 |
| | Add: | 10:49.15 |
| | " if (code == gs_error_undefined && pte->current_font->FontType == ft_encrypted2)" | 10:49.15 |
| | " /* Trying to make a CFF font for ps2write, which doesn't support CFF, abort now! */" | 10:49.15 |
| | " return code;" | 10:49.15 |
| chrisl | I'll wait until you commit it - it obviously needs fixed as you see a crash there. If it doesn't resolve the one I see, I'll track it down | 10:49.36 |
| kens | It throws an error and exits, which is at least cleaner than a crash | 10:49.39 |
| | chrisl ok | 10:49.57 |
| | Hmm, OK so that quick hack was a bad idea,it causes type 2's to abort instead of fallinb back to image data. I'll move the check inside the composite font processing. | 11:09.15 |
| | I htink I may actually have to spend the time to invstigate this more thoroughly, I have a sneaking suspicion quick hackery, even just to avoid a GPF isn't going to work.......... | 11:22.18 |
| | ROFL, "we need the SDK", reply: 'I sent you a PDF of how to use the SDK'...... | 11:40.23 |
| | chrisl commit 23aab341 should 'work around' the problem for now. At some point I'll need to try and fix it 'properly' | 11:54.21 |
| chrisl | kens: thanks, I'll try it in a bit - I'm kind of in the middle of something else...... | 11:55.56 |
| kens | Yeah, me too, that's why I don;t want to dive in and spend the next 2 weeks figuring this one out properly | 11:56.18 |
| | LOL Windows 10 on new Pi2: | 11:56.34 |
| | http://www.theregister.co.uk/2015/02/02/microsoft_eyes_slice_of_raspberry_pi_with_free_windows_10/ | 11:56.34 |
| jhabjan | good afternoon, someone reported me that Ghostscript.NET cannot handle some pdf... (display device). I did try to open that pdf by command line "gswin64 i1.pdf" and figured out that the pdf is not built properly. Can anyone please confirm my thoughts? The pdf download link is: https://www.dropbox.com/s/3ripof2fy7ee6v4/in1.pdf?dl=0 | 14:12.25 |
| kens | give me a minute | 14:16.40 |
| | Well, Acrobat opens up, but that's not conclusive | 14:17.38 |
| chrisl | Ghostscript gives rangecheck in setdash | 14:17.54 |
| kens | Current Ghostscript code renders it | 14:18.22 |
| | What problem do you see jhabjan ? | 14:18.31 |
| jhabjan | i used 9.15 | 14:18.33 |
| kens | I can try that too, just a moment | 14:18.45 |
| | FWIW GS does give warniogns on the file | 14:19.02 |
| | 'invalid annotation' | 14:19.12 |
| | Yes, 9.15 errors out on it | 14:19.51 |
| | A problem with setdash apparently | 14:20.00 |
| | resolving object 36 0 | 14:20.26 |
| jhabjan | ok, so there is nothing that can be done with versions 9.15 and prior about that.. right? | 14:20.28 |
| kens | Well we don't attempt to patch older versions, so no. | 14:21.10 |
| jhabjan | ok, no worries, thank you | 14:21.24 |
| kens | If you hang around I may be able to tell you what's wrong with the PDF | 14:21.47 |
| jhabjan | sure, ta | 14:21.55 |
| kens | I don't recall fixing this..... | 14:22.03 |
| chrisl | You did fix pdfwrite stuff to do with setdash..... | 14:22.27 |
| kens | Well, I have the memory of a goldfish, as we all know :-( | 14:23.30 |
| Robin_Watts | showoff. | 14:23.38 |
| chrisl | But that was prior to 9.15 I think: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=94c5ecff | 14:24.15 |
| kens | THe Border is given as [10 10 10 [0]] the [0] is the dash, we dont' like it for some reason | 14:24.44 |
| chrisl | kens: your ps2write "fix" resolves the crash I was seeing, too.... | 14:24.55 |
| kens | chrisl can't be that one :-) | 14:24.57 |
| | I suspect I changed something to execute an annotation inside a stopped context, which is why it now doesn't throw an error. | 14:25.21 |
| | chrisl, well at least it sounds like it was hte same problem. | 14:25.33 |
| jhabjan | btw.. gsapi_run_string doesn't return rangecheck error, it returns invalidexit (-8) | 14:26.22 |
| chrisl | kens: Well, the innards of the cos object were buggered for my crash, too. | 14:26.41 |
| | jhabjan: the rangecheck error will have been handled by the Postscript error handler | 14:27.05 |
| kens | jhabjan : I get an unrecoverable error, with a typecheck in 9.15 | 14:27.09 |
| | The problem is tha dash array. A single value says 'this many units on, then the same number off' | 14:27.33 |
| | So a value of [3] means draw 3 units, then leave 3 blank, then draw 3 more, then leave 3 blank... etc | 14:27.58 |
| jhabjan | got it | 14:28.13 |
| chrisl | Interesting, 9.10 gives the "Error: /rangecheck in --setdash--" I mentioned earlier..... | 14:28.13 |
| kens | A value of 0 simply doesn't make sense, that would be dra 0, then leave 0 blank then draw 0 etc | 14:28.20 |
| | chrisl sorry yes I get a rangecheck in setdash, but that then causes a furtehr error | 14:29.18 |
| | typecheck, and then an exit | 14:29.18 |
| | Ah, its because I was running with -dPDFDEBUG | 14:29.46 |
| | If I don;'t do that I just get the rangecheck | 14:29.55 |
| | Err, no, I do still get he typecheck and an unrecoverable exit | 14:30.15 |
| | But nayway,the reason it fails is because the dash parameter is nonsense | 14:30.27 |
| jhabjan | ok, thanks | 14:30.43 |
| kens | A solid line should be given by just [] | 14:31.20 |
| jhabjan | while I'm here.. I have one more question. SVG device is discontinued, right? | 14:34.50 |
| kens | Yes | 14:34.57 |
| jhabjan | ok | 14:35.01 |
| kens | It was never finished | 14:35.02 |
| | Didn't work terribly well | 14:35.09 |
| | And tehre are problems with fonts as I recall | 14:35.16 |
| jhabjan | no worries | 14:35.23 |
| | I just ask questions that people email me regarding Ghostscript.NET... most of them don't understand that the Ghostscript.NET is just a wrapper and asks questions that are related to native ghostscript library... | 14:37.43 |
| kens | Well,I do my best to answer questions on STack Overflow, you can always direct them there, or to here for GS questions | 14:38.19 |
| henrys | jhabjan: there is some support for svg output in MuPDF, further svg improvements we do will likely be in MuPDF, I don't know what sort of .NET api's are around in the wild. | 14:41.27 |
| jhabjan | n/p | 14:43.08 |
| | henrys: I wrote a wrapper for MuPDF in .NET .. not 100% completed yet and I still did not publish it | 14:44.31 |
| henrys | tor8, chrisl_away (for the logs) new urwfonts in my home directory Artifex_update_OTF.zip - we are to use these font for both GPL and commercial releases. | 15:38.45 |
| tor8 | henrys: fab, I'll take a look and see how well they fit what we asked for | 15:40.44 |
| rayjj | henrys: so those are the OTF's with the extra glyphs in all 136 (except for the symbol fonts) with CFF outlines, right ? | 15:54.54 |
| henrys | rayjj: no there are 3 fonts, we're building up more slowly than initially planned. | 15:55.50 |
| rayjj | henrys: I see. | 15:56.20 |
| tor8 | rayjj: from my initial examination, it's the OTFs we ordered for MuPDF (the base 12 times, helvetica, courier) with the character set matching microsoft's | 15:56.23 |
| | looking at Nimbus Roman No9 L Regular, it's got all the exact glyph set we asked for, and only 2 metrics mis-matches | 15:57.00 |
| henrys | rayjj: if the customer's email is not going out today I'd recommend a message today to them explaing what's going on... | 15:57.09 |
| rayjj | so it's three faces, in 4 styles each | 15:57.13 |
| henrys | tor8: sounds good | 15:58.25 |
| rayjj | henrys: I'll send you the draft for review. in reviewing the ATS memory utilization, the problem is that I used the 'standard' build and the memory usage for openjpeg is a killer on some files. Re-running with luratech. | 15:58.38 |
| henrys | rayjj: tomorrow at the meeting I"m going to pitch we just have this info ready all the time, part of the documentation that gets updated as needed. | 15:59.21 |
| rayjj | henrys: I assume that we don't care about openjpeg --that any customer will be using luratech. | 16:00.02 |
| henrys | rayjj: so having what you did be in an easily reproducible state would be best. | 16:00.25 |
| rayjj | henrys: the scripts I have on linux can be re-run, so we can crank through them on a regular basis | 16:00.36 |
| | henrys: exactly | 16:00.43 |
| henrys | I"d think we'd dispense with testing anything jbig2 or jpeg2000 so we can have the convenience of being able to generate the numbers on the GPL release. Do you have files you think should be included in the testing that use those codecs? | 16:01.56 |
| rayjj | henrys: Since we are talking to a "real world" customer, similar to cust 532, I ran the ATS and JEITA. The ATS is what includes JPX (JPEG2000) images. I don't think there are jbig2 images, and those aren't really a concern anyway | 16:03.36 |
| | henrys: Note that I did *not* run comparefiles since many of those are large format (from RIP customers) or other strange things that someone would generally not "print" | 16:05.03 |
| henrys | rayjj: if we want to put something in the documentation it would be great if anyone could reproduce it without permissions for test files and luratech. Don't you think? | 16:08.36 |
| rayjj | henrys: the scripts use a 'run.list' file with the list of files to test | 16:12.16 |
| | it's a simple 'for' with the params for the command line baked in. | 16:12.44 |
| henrys | rayjj: okay important to get that moving along to the customer first and we can talk about how to put it in the release tomorrow. | 16:13.50 |
| rayjj | henrys: in order to collect the clist sizes, we need a debug build and need to force compression of the clist so we get the compressed size as well as the raw | 16:13.58 |
| | and, for customers we will want to use the luratech build | 16:14.43 |
| henrys | henrys: can't that be fixed in the code - we do other performance ouput in production mode? | 16:15.04 |
| avih | tor8: hey :) have you read the backlog? | 16:15.44 |
| rayjj | henrys: yes, but I am just running the code as is. We'd need to make the memory clist compression threshold a parameter (not a bad idea anyway) and make the collection and printing of clist stats independent of DEBUG for -Z: | 16:16.59 |
| tor8 | avih: ah, no, not from yesterday | 16:17.01 |
| avih | tor8: in a nutshell, on linux with clang: | 16:17.24 |
| | $ build/mujs | 16:17.25 |
| | > var a = 1 | 16:17.25 |
| | > a | 16:17.25 |
| | 1 | 16:17.25 |
| | > var a = ["a","b"]; | 16:17.26 |
| | > a | 16:17.28 |
| | > | 16:17.30 |
| | > var a = [1,2,3,4]; | 16:17.32 |
| | > a | 16:17.34 |
| | ,0,1,2,3 | 16:17.37 |
| | > | 16:17.39 |
| | > a.length | 16:17.41 |
| | 5 | 16:17.43 |
| rayjj | avih: and a.length from var a = ["a","b"]; was 0 iirc | 16:18.15 |
| avih | yeah | 16:18.28 |
| tor8 | avih: huh. that's...not good | 16:19.24 |
| avih | yeah :) | 16:19.31 |
| | tor8: can you reproduce? when i rebuilt mujs with non strict, it still behaved weird (linux+clang), but my embed of mujs into mpv where i cross compile it on linux for windows, without strict mode, _seems_ to behave correctly, but then again, by the time it gets to run the user script it already automatically ran some built in scripts, so it might not be the same case. | 16:21.26 |
| | tor8: can you reproduce the log i just posted? | 16:21.35 |
| tor8 | avih: yes, I think I've tracked it down as well | 16:22.14 |
| avih | cool | 16:22.19 |
| tor8 | at least to the commit that broke it | 16:22.29 |
| avih | which was it btw? | 16:22.38 |
| tor8 | a change in how I compile array literals, to check for duplicate entries in strict mode | 16:22.44 |
| avih | k | 16:22.50 |
| tor8 | 44c0e12 strict mode: Check duplicate property names | 16:22.59 |
| | I've accidentally swapped key and value... | 16:24.38 |
| | avih: fix is live on both ghostscript.com and github. | 16:28.03 |
| avih | dinamic: ^ | 16:29.30 |
| | tor8: confirmed fixed at the scenario which was previously broken | 16:31.06 |
| | in both stricts and non strict modes | 16:32.12 |
| Mark__ | Does MuPdf have a full-screen presentation mode? If so, how do I invoke it? | 18:02.08 |
| Robin_Watts | Mark__: On Linux presumably? | 19:45.58 |
| mvrhel_laptop | bbiaw | 20:55.44 |
| | Forward 1 day (to 2015/02/03)>>> | |
IRC Logs