| | <<<Back 1 day (to 2013/10/22) | 2013/10/23 |
| sebras-work | feels very evil -- has reported 20+ translation related bugs for the webpages of my employers products. His colleagues back in .se must be happy... ;) | 07:39.06 |
| Robin_Watts | is moderately amazed to see that despite doing 6 commits yesterday, that none of them broke the build. | 11:40.40 |
| stanv | please help | 12:00.41 |
| | Font DejaVuSansMono is mapped to FAPI=FreeType | 12:01.25 |
| | 0 (\376\377\0001) 4096 0 Tform | 12:01.25 |
| | **** Error STANV reading a content stream. The page may be incomplete. | 12:01.25 |
| chrisl | stanv: all we can really tell from that is that you have an error - which you already know | 12:03.42 |
| Robin_Watts | stanv: Have you opened a bug, as you were asked to do when you last brought this up? | 12:04.27 |
| stanv | Robin_Watts: no | 12:04.40 |
| Robin_Watts | stanv: Then, can you guess what I'm going to suggest you do now? :) | 12:04.54 |
| stanv | Robin_Watts: I can't open bug, because I build PDF file byself. And I am afraid it is bad. | 12:05.26 |
| Robin_Watts | I don't see why that stops you opening a bug and attaching a file. | 12:05.59 |
| stanv | Robin_Watts: Okey, could you please give me URL | 12:06.21 |
| | ? | 12:06.23 |
| Robin_Watts | You might get told that we don't have time to look, but without having a file we cannot do anything. | 12:06.34 |
| | bugs.ghostscript.com | 12:06.41 |
| chrisl | stanv: FWIW, I don't recognise "Tform" as a PDF operator.... | 12:08.48 |
| stanv | chrisl: it is a DEBUG output from gs | 12:10.36 |
| | chrisl: please lookup for: https://dl.dropboxusercontent.com/u/9413602/Micha.pdf | 12:11.06 |
| | this is that file | 12:11.14 |
| | I'm trying to add font. | 12:11.24 |
| | And use this font from my form | 12:11.41 |
| | PDF form | 12:11.45 |
| | I have next object: | 12:12.30 |
| | 7 0 obj <</Type /Annot /Subtype /Widget /F 4 /Rect [276.6 587.7 512.7 613.1 ] /FT /Tx /P 1 0 R /T (job-title) /V (þÿ^@1^@s^D"^D^U^D!^D"^D^Q^D^P^D^]^D^]^D^U^D ) /DV (þÿ) /DR <</Font 6 0 R >> /DA (/stanv_font 14 Tf) /M (D:20131022162514) >> endobj^M | 12:12.30 |
| chrisl | Not a form, an annotation..... | 12:13.10 |
| Robin_Watts | Micha`: MuPDF says: warning: freetype load glyph (gid 65279): invalid argument | 12:14.37 |
| stanv | and for it I get: | 12:15.17 |
| | http://fpaste.org/48846/53050913/ | 12:15.17 |
| Robin_Watts | stanv: I think you've truncated the font or something. | 12:16.12 |
| chrisl | The real error from Ghostscript is: Error: /undefined in --.PDFexecform-- | 12:17.49 |
| stanv | chrisl: I don't have such message | 12:18.27 |
| chrisl | stanv: set -dPDFSTOPONERROR | 12:18.53 |
| stanv | chrisl: Give me please full command invocation example. | 12:19.54 |
| chrisl | ./gs -dPDFSTOPONERROR -dNODISPLAY ~/Downloads/Micha.pdf | 12:20.31 |
| stanv | chrisl: so,,, can you explain this error ? | 12:21.50 |
| | what it means ? | 12:22.03 |
| chrisl | An error has occurred executing the procedure .PDFexecform | 12:22.22 |
| kens | stanv1 you've been told, report a bug and someone will look into it | 12:22.28 |
| Robin_Watts | stanv: You might want to try using "mutool extract" (part of mupdf) to extract the font from your created file and checking if it's valid. | 12:30.17 |
| | Oh, gawd. 801 have added custom postscript operators too. | 12:33.29 |
| chrisl | That's not unusual. It's why I think we should have a "proper" API for adding custom operators | 12:34.22 |
| Robin_Watts | basically they seem to have a new operator to 'average' 2 numbers (I think that's a test :) ) | 12:34.56 |
| stanv | http://bugs.ghostscript.com/show_bug.cgi?id=694734 | 12:35.00 |
| | please help | 12:35.03 |
| Robin_Watts | and ones to 'put_params' and 'get_params'. | 12:35.08 |
| kens | stanv1 no attachment there | 12:35.32 |
| chrisl | We have operators to put_params and get_params.... | 12:35.36 |
| Robin_Watts | indeed. I'm trying to understand what they are doing now. | 12:35.54 |
| stanv | kens: done | 12:36.16 |
| chrisl | stanv: FWIW, the error seems to be coming from the font lacking a FontBBox (Note this is not the font object, but the font itself) | 12:36.49 |
| kens | Yes, we're trying to extract FontBBox and its undefined | 12:37.16 |
| chrisl | It's required for a base font, not sure about a composite font | 12:37.43 |
| kens | I think FontBBox is always required (in PostScript) | 12:38.06 |
| chrisl | I wonder how we don't get an error on definefont...... | 12:39.05 |
| kens | Possibly we don't cehck it before use | 12:39.24 |
| stanv1 | # mutool extract 9.pdf extracting image img-0004.png extracting font BAAAAA+DejaVuSansMono-Bold-0027.ttf extracting font CAAAAA+Chalkduster-0032.ttf extracting font DAAAAA+LiberationMono-0037.ttf | 12:39.45 |
| | warning: Unhandled font type | 12:39.45 |
| | extracting font DejaVuSansMono-0063.ttf | 12:39.45 |
| | Sorry, I was kicked out | 12:39.59 |
| | Did you say something important ? | 12:40.21 |
| kens | FontBBox is a required entry in font dictionaries, both for fonts and CIDFonts | 12:40.55 |
| | Its also required for all base fonts | 12:41.24 |
| chrisl | Yeh, if I hack around that, the file runs to completion | 12:41.54 |
| stanv1 | ah⦠fâ¦ck!!!! | 12:43.45 |
| | ((( | 12:43.47 |
| | I omitted it because I didn't know what is object type [x,x,x,x] | 12:44.36 |
| kens | Its an array | 12:44.44 |
| | Arrays *are* defined in the PDFRM | 12:44.54 |
| | The FontBBox is defined on page 456 of the 1.7 refrence manual and says "required, except for type 3 fonts" | 12:46.09 |
| | Its defined there as a 'rectangle' and that directs you tp section 3.8.4 where a 'rectangle' is defined | 12:46.43 |
| | page 161 of the 1.7 PDF reference manual | 12:47.08 |
| stanv1 | kens: I have a FontBBox in my dic: | 12:47.20 |
| | 63 0 obj <</Type /FontDescriptor /FontName /DejaVuSansMono /Flags 7 /ItalicAngle 0 /Ascent 759 /Descent -240 /CapHeight 759 /StemV 87 /FontBBox [-557 -374 717 1041 ] /AvgWidth 602 /Style <</Panose (^@^@^B^K^F ^C^H^D^B^B^D) >> /FontFile2 62 0 R >> endobj^M | 12:47.20 |
| kens | THat's a FontDescriptor | 12:47.33 |
| | ANd I don't think its the missing one anyway | 12:47.45 |
| stanv1 | kens: could you point object that must contain FontBBox ? | 12:48.26 |
| kens | But my Ghostscript is in pieces right now, as I'm working on colour | 12:48.37 |
| | stanv1 I suggest you ask chrisl | 12:48.51 |
| stanv1 | chrisl: what object should contain FontBBox ? | 12:49.10 |
| | )) | 12:49.12 |
| chrisl | stanv1: it's the Type0 font that is missing the FontBBox, but I'm not sure where that comes from..... | 12:49.31 |
| stanv1 | I'm confused | 12:50.32 |
| | ( | 12:50.32 |
| kens | They Type0 should be instantiated frmo the CIDFont | 12:51.42 |
| chrisl | Yes, and the CIDFont has a FontBBox, but the Type 0 doesn't - and Type 0 fonts fon't have a font descriptor | 12:52.42 |
| kens | A simpler example would have been nice, one font no forms etc.... | 12:53.29 |
| | BTW when I close the file in Acrobat it asks to 'save changes' so Acrobat is repairing the file, more evidence that it is broken | 12:54.01 |
| | THe repaired file is 200k bigger | 12:54.35 |
| chrisl | Eep, that's a heck of a change! | 12:54.49 |
| stanv1 | So, I construct wrong font resource description, do I ? | 12:55.00 |
| kens | chrisl its 300k when I deompress the files. Decompressed the files are > 4Mb | 12:55.34 |
| chrisl | I'm suspicious the code in /Tform is not correct for composite fonts...... | 12:55.52 |
| kens | Acrobat completely rewrites teh annotations, I forgot it would do that. I suspec that's where the infaltion is coming from | 12:56.27 |
| stanv1 | chrisl: I can fill form in Acrobat Pro⦠And it is okay. I have an example file. | 12:56.42 |
| chrisl | stanv1: that's probably Acrobat is completely regenerating the entire stream, and probably not much help | 12:57.23 |
| stanv1 | http://bugs.ghostscript.com/show_bug.cgi?id=694734 â please see attached file from Adobe. | 12:57.47 |
| chrisl | My take on this is that our code is wrong: either we need to copy the FontBBox from the descendant font to the Type0, or we need to handle the Type0 not having a FontBBox in /Tform | 13:00.42 |
| stanv1 | << /P {11 0 resolveR} /Type /Annot /DV (\376\377) /T (job-title) /M (D:20131022161634) /V (\376\377\0001\000s\004"\004\025\004!\004"\004\021\004\020\004\035\004\035\004\025\004 ) /Rect [276.6 587.7 512.7 613.1] /FT /Tx /F 4 /DA (/Arial 18 Tf 0.736 0 0 rg) /AP << /N {13 0 resolveR} >> /Subtype /Widget /DR << /Font {86 0 resolveR} >> >> | 13:00.45 |
| chrisl | Hmm, Arial? Where's DejaVuSansMono gone? | 13:01.32 |
| stanv1 | /Arial {63 0 resolveR} | 13:01.39 |
| | it is going a Adobe Example - working example | 13:02.00 |
| | %Resolving compressed object: [63 0] | 13:02.35 |
| | << /Name /Arial /BaseFont /Arial /Type /Font /LastChar 255 /Encoding {69 0 resolveR} /Widths [â¦] /FontDescriptor {70 0 resolveR} /FirstChar 0 /Subtype /TrueType >> | 13:02.35 |
| | %Resolving compressed object: [70 0] | 13:02.52 |
| | << /FontBBox [-665 -325 2000 1006] /XHeight 519 /Type /FontDescriptor /StemV 88 /FontFile2 {17 0 resolveR} /CapHeight 716 /Descent -325 /FontStretch /Normal /FontWeight 400 /Ascent 1006 /FontName /Arial /Flags 32 /ItalicAngle 0 /FontFamily (Arial) >> | 13:02.53 |
| chrisl | So Acrobat is using a font, not a CIDFont | 13:03.02 |
| stanv1 | soooo ? | 13:03.18 |
| chrisl | That's pretty useless, like I said it would be | 13:03.34 |
| stanv1 | What is the best solution for me ? | 13:03.43 |
| chrisl | Like I said, I think our code is wrong | 13:04.01 |
| kens | chrisl I might agree if Acrobat didn't think the file was broken | 13:04.21 |
| | Of course, its possible its a different problem, but it also completely rewrites the fonts | 13:04.37 |
| stanv1 | chrisl: is ther simple solution how to fix my code? | 13:05.12 |
| kens | Unfortunately it also adds Zapf Dingbats and Helvetica in the output file | 13:05.31 |
| chrisl | kens: Well, /Tform is clearly assuming that the currentfont contains a FontBBox, and that's not a valid assumption when dealing a Type0 in PDF | 13:05.48 |
| kens | The Acrobat 'fixed' file runs to completion | 13:08.14 |
| stanv1 | so⦠the problem is in ghoscript ? | 13:08.48 |
| chrisl | kens: but given the way Acrobat regenerates everything, that doesn't really tell us much | 13:08.50 |
| kens | chrisl true, but it still appears to use the font | 13:09.06 |
| | Hmm, but I wonder if it actually does use the font, since its only used in annotations, and Acrobat recreates those. | 13:10.15 |
| | Yes, it actually does use the font still, the /AP streams call for it | 13:10.55 |
| | Oh, interesting, and then immediately use DejaVuSansMono, so the font is unused | 13:11.24 |
| chrisl | kens: does it use CIDFont? I note there is a WinAnsii encoded version there | 13:11.35 |
| kens | chrisl did you save the file out of Acrobat to get it fixed ? | 13:13.51 |
| chrisl | Yeh | 13:14.03 |
| kens | OK then look at object 67 0 its a type 0 font, its used in an annotation ,and it works as far as I can tell | 13:14.22 |
| chrisl | Er, no 67 0 is a color space for me - possibly different Acrobat versions? | 13:16.00 |
| kens | Oh could be | 13:16.07 |
| stanv1 | I can open/close in Acrobat Reader XI in MacOsâ¦. if it helps... | 13:17.43 |
| | I prompts to save file,â¦. even I don't do any changes to it. | 13:18.08 |
| chrisl | kens: the Acrobat fixed file, for me, does not call /Tform | 13:18.26 |
| kens | stanv1 this is a sign that Acrobat repaired your broken file without telling you | 13:18.28 |
| stanv1 | But, I see filled form... | 13:18.32 |
| kens | chrisl well that's interesting. | 13:18.40 |
| stanv1 | If you wish I can give you saved file from AdobeReader. | 13:19.25 |
| kens | stanv1 I appreciate you want to help, the best thing you can do is leave us to discuss this | 13:19.57 |
| stanv1 | okay | 13:20.05 |
| kens | chrisl ah, of course, Tform is only called for annotations that don't have an appearance stream. | 13:20.27 |
| stanv1 | but, in any case,,, please let me know about your decision. | 13:20.28 |
| kens | since Acrobat rewrites the annotations with an appearnace stream, this does not happen. | 13:20.49 |
| chrisl | I assumed as much | 13:20.58 |
| kens | So it looks like its the Tform procedure which is assuming a font will have a FontBBox | 13:21.11 |
| chrisl | I think I said that above..... | 13:21.28 |
| kens | I have to work through these myself, sorry | 13:21.43 |
| | My head is filled with CIE colour spaces at the moment, need to flush the cache | 13:22.01 |
| chrisl | So, Type0 font objects in PDF don't have a font descriptor, so no where to define the FontBBox, so I reckon that's an invalid assumption | 13:22.57 |
| kens | So yes, it seems like we could derive the FontBBox from a descendant font, or assume some axmima | 13:23.04 |
| | maxima* | 13:23.17 |
| chrisl | kens: something like: http://pastebin.com/3SfCfW8U seems to work | 13:24.14 |
| | Except for the "1" being a "0".... | 13:24.38 |
| kens | I was thinking of checking teh fontType immediately rather than checking for FontBBox, but it allows us to create an error, yes | 13:25.01 |
| | yes FOntType should be 0 :-) | 13:25.14 |
| chrisl | Yes, I was testing "else" part just before I pasted it | 13:25.39 |
| kens | I wonder if we should just abort the appearance stream (with a warning) rather than throw an error | 13:25.53 |
| | But I guess the PDF itnerpreter will take care of it | 13:26.06 |
| | Looks fine to me if you want to commit that | 13:26.23 |
| chrisl | We effectively will just abort the stream unless you set PDFSTOPONERROR in which case, we want to throw an error | 13:26.49 |
| kens | Of course, that still doesn't explain what Acrobat finds objectionable, maybe it just doesn't like annotations without appearnace streams | 13:26.59 |
| | chrisl yes, that was what I was thinking when I said the PDF interpreter will take care of it :-) | 13:27.18 |
| chrisl | Dunno about Acrobat, but with that change above GS runs it without so much as a warning..... | 13:27.42 |
| kens | Oh, you probably want to check that the descendant font returns a FontBBox too ? | 13:28.15 |
| | Hmm maybe not | 13:28.27 |
| | THat'll just throw an error, which aborts it, so OK | 13:28.37 |
| chrisl | The descendant font *must* have a BBox, it's required | 13:28.50 |
| kens | chrisl, yes, and we never see broken files :-) | 13:29.04 |
| | Seriously, its an error, which is fine | 13:29.14 |
| | I'd say go ahead and commit that | 13:29.27 |
| chrisl | Yeh, I don't think inventing a BBox would be a good idea in this case | 13:29.35 |
| kens | No, it seems like a bad idea | 13:29.46 |
| kens | wanders back into the labyrinth of CIE colour spaces | 13:30.07 |
| stanv1 | ))) | 13:30.19 |
| | No ) | 13:30.21 |
| | Just say what is your decision) | 13:30.33 |
| chrisl | stanv1: I'm going to regression test my change, and if that shows no problems, I'll commit it | 13:31.03 |
| stanv1 | chrisl: how much time it takes ? | 13:31.36 |
| chrisl | 20 minutes or so | 13:31.46 |
| stanv1 | chrisl: could you please give me diff⦠I'll make a test on my machine | 13:32.17 |
| | But I am still worried about: | 13:34.32 |
| | mutool extract 9.pdf | 13:34.32 |
| | extracting font DAAAAA+LiberationMono-0037.ttf | 13:34.33 |
| | warning: Unhandled font type | 13:34.33 |
| | extracting font DejaVuSansMono-0063.ttf | 13:34.33 |
| chrisl | stanv1: here's the diff: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=ca33b81 | 13:37.16 |
| stanv1 | Excuse me | 13:44.07 |
| | )) | 13:44.08 |
| | BUT ) | 13:44.09 |
| | it works only for half | 13:44.20 |
| | )) | 13:44.20 |
| kens | Are you still getting an error ? | 13:44.50 |
| stanv1 | Now I see charactersâ¦.. but they are not same as coded in UTF16BE (filled form) | 13:45.03 |
| | no,,, I do not get any errors | 13:45.15 |
| kens | Then its working | 13:45.44 |
| | Encoding problems are a different thing altogether | 13:46.03 |
| | I would guess you don't have a relevant CMap composed with your CIDFont. | 13:46.28 |
| | I should point out that if you don't create an Appearance stream for annotations then you are at the mercy of the PDF consumer and how it chooses to create one. | 13:49.40 |
| chrisl | kens: some odd diffs in bmpcmp, would you take a look, please? | 13:57.44 |
| kens | OK 1 sec | 13:57.53 |
| | 12-07b can be discoutned, all the rest are the same input file | 13:59.27 |
| | Acrobat does display stuff, so I'm pretyy happy with a . | 14:00.17 |
| chrisl | Yes, I'm just trying to fathom how my change can have caused that - for my change to take effect, that file should have errored before! | 14:00.30 |
| kens | .notdef | 14:00.33 |
| | chrisl I would say so yes. | 14:00.42 |
| | let me try it | 14:00.52 |
| | (possibly it did error before) | 14:01.03 |
| chrisl | Well, then we wouldn't have a "before" bitmap to compare to | 14:01.34 |
| kens | Throws *lots* of errors for me | 14:01.37 |
| | But continues to completion | 14:01.45 |
| chrisl | Oh, of course, we don't test with PDFSTOPONERROR | 14:02.08 |
| kens | Nope :-) | 14:02.14 |
| | Its the same symptoms as stanv1 for me | 14:02.22 |
| chrisl | OKay, that's getting push now | 14:02.26 |
| stanv1 | )) maybe⦠but⦠cp | 14:03.44 |
| | I do not understand!!!!! | 14:04.46 |
| chrisl | You had an error, I've fixed your error | 14:05.10 |
| stanv1 | Now, I don't have error. | 14:05.39 |
| | But instead letters i see other symbols | 14:06.02 |
| kens | Your file contains annotatiosn which do not have a specific appearance. As a user-friendly gesture, Ghostscript will attempt to synthesize an appearance for certain kinds of annotations/form fields. The synthesis code was making an unjustified assumption, which has been corrected | 14:06.08 |
| | It looks to me like the synthesis code is assuming that the text will be in PDFDocEncoding, and its not expecting UTF, so you get incorrect textr | 14:06.46 |
| | That's a completely different problem. | 14:06.53 |
| stanv1 | kens: how do I fix it ? | 14:07.05 |
| kens | The most immediate way for you ti fix this is to put your text in PDFDocEncoding instead of UTF | 14:07.22 |
| | You can also raise a bug report (set to enhancement) to have the synthesis code handle UTF16 and someone will (eventually) look into it. | 14:07.59 |
| stanv1 | PDFDocEncoding ? | 14:08.20 |
| kens | Read teh PDF Reference Manual, its defined there | 14:08.32 |
| | Morning mvrhel_laptop | 14:10.53 |
| mvrhel_laptop | hi kens | 14:11.04 |
| | kens: ok I was wondering if the image was getting "remapped" to the color space range | 14:11.37 |
| | I don't see why that would be done in the spec though | 14:11.46 |
| kens | mvrhel_laptop : it is, but I cannot yet find any justification for it | 14:11.55 |
| mvrhel_laptop | ok | 14:12.07 |
| stanv1 | But my poppler says: | 14:12.26 |
| | //except a UTF16BE string | 14:12.26 |
| | void setContent(GooString* new_content); | 14:12.27 |
| | I can't put anything else but UTF16BE | 14:12.42 |
| mvrhel_laptop | have to get breakfast and take kids to school and car to shop so I will be a little late this morning | 14:12.54 |
| kens | By tracking through the code in another PostScript interpreter of my acquaintance I was able to see that it is doing the remapping to the RangeABC, but I don't (yet) see why this is done | 14:12.55 |
| mvrhel_laptop | ok. kens thansk. | 14:13.07 |
| kens | stanv1 then you are currently stuck | 14:13.07 |
| stanv1 | kens: maybe add appearence ? | 14:14.04 |
| | is it hard ? | 14:14.13 |
| | to do that ? | 14:14.19 |
| kens | stanv1 you can create your own appearance stream, certainly, yes its hard | 14:14.24 |
| | Especially since you do not seem to have any background in PDF, the appearance stream needs to be created using PDF syntax | 14:14.50 |
| stanv1 | I have poppler⦠it has void updateWidgetAppearance(); | 14:15.22 |
| | GooString* getDefaultAppearance() const { return defaultAppearance; } | 14:15.48 |
| | void setAppearanceState(const char *state); | 14:16.00 |
| Robin_Watts | stanv1: At the risk of getting drawn into this, which I really don't want to be... I suspect that when you call 'setContent' in poppler it is expecting you to pass a UTF16BE string in. | 14:18.18 |
| stanv1 | Robin_Watts: okay)) | 14:18.46 |
| Robin_Watts | It will then output that to the PDF file in the appropriate encoding for the font in use. | 14:18.47 |
| kens | No,no,no | 14:19.10 |
| stanv1 | I want to add you to facebook. | 14:19.13 |
| | )) | 14:19.13 |
| kens | text strings can only be in PDFDocEncoding, or UTF16BE | 14:19.25 |
| stanv1 | kens: soâ¦. soâ¦. | 14:19.57 |
| | ? | 14:19.59 |
| Robin_Watts | kens: right, but just because he passes a string to setContent in UTF16BE does not mean that poppler won't convert the string to PDFDocEncoding before outputting it, does it ? | 14:20.14 |
| stanv1 | Do I need appearance object ? | 14:20.22 |
| kens | Robin_Watts : why bother ? | 14:20.24 |
| | It has to be one or the other, so it doesn't matter which you set | 14:20.37 |
| Robin_Watts | one takes more space than the other? | 14:21.07 |
| | anyway, you're passing the content in as a stream of unicode values. | 14:21.25 |
| stanv1 | so⦠I need appearance object that says that my annotation is coded in UTF16BE. Right ? | 14:22.01 |
| kens | NO | 14:22.35 |
| | The Ghostscript appearance synthesizer does not handle UTF | 14:22.56 |
| Robin_Watts | If you are seeing the wrong glyphs come out, then it's probably a matter of the glyphs not being in the places in the font that poppler is expecting. | 14:23.00 |
| kens | So you need to code your /V as PDFDocEncoding, or supply an appearance stream | 14:23.12 |
| Robin_Watts | For instance, suppose the string is supposed to be "hello" and you actually see "abccd" | 14:23.35 |
| kens | Robin_Watts : no, its because the appearance synthesis code doesn't handle UTF, only PDFDocEncoding | 14:23.38 |
| stanv1 | kens: big thanks | 14:23.54 |
| Robin_Watts | kens: Oh, right, so his code looks right in other viewers? | 14:23.56 |
| kens | Well yes | 14:24.03 |
| | Especially Acrobat | 14:24.09 |
| Robin_Watts | then ignore me. | 14:24.11 |
| kens | Or rather, I assume its correct | 14:24.18 |
| Robin_Watts | I'd assumed that it was wrong in all viewers, not just wrong in gs. | 14:24.30 |
| stanv1 | kens: but acrobat shows right symbolsâ¦. butâ¦. | 14:24.36 |
| Robin_Watts | OK, so this is a bug in gs then (or at least a "limitation") | 14:24.53 |
| stanv1 | anyway⦠i go for PDFDocEncoding | 14:24.54 |
| kens | Acrobat handles UTF when synthesising appearances | 14:24.57 |
| | Robin_Watts : its a limitation, nto a bug, hence an enhamcement request is appropriate | 14:25.16 |
| stanv1 | kens: If you wish I can initiate new bug ) | 14:25.38 |
| kens | stanv1 up to you | 14:25.46 |
| Robin_Watts | It's a perfectly well formed input file, and we render it wrong. That sounds like a clear cut bug to me. | 14:26.24 |
| kens | Robin_Watts : there is no requirement to synthesise appearance streams | 14:26.46 |
| | Its an optional extra | 14:26.52 |
| Robin_Watts | but where we do so, we should probably do so correctly :) | 14:27.12 |
| kens | is really too busy to discuss this, I'm wrestling with CIE colour spaces and the PLRM. I'm happy to accept an enhancement request, bugsa will be downgraded to enhancements | 14:27.59 |
| chrisl | "Device dependent", so we define "correct" ;-) | 14:28.24 |
| stanv1 | Bye!! see you tomorrow . | 14:29.01 |
| kens | mvrhel_laptop : ping | 14:34.47 |
| Robin_Watts | mvrhel_laptop: Tiny change to gdevpsd.c on robin/master. If you're not offended, I'll push it. | 14:39.58 |
| mvrhel_laptop | kens: pong | 14:48.23 |
| | did you find it | 14:48.28 |
| kens | mvrhel_laptop : what version of Distiller did you use ? | 14:48.38 |
| | Using X the gradient is black for me | 14:48.53 |
| mvrhel_laptop | oh I am using 9 | 14:49.26 |
| | kens: that is interesting | 14:49.33 |
| kens | I sent you the PDF file that Distiller X produces. | 14:49.45 |
| mvrhel_laptop | oh great thanks | 14:49.51 |
| | kens: it looks the same | 14:50.46 |
| | at ves 9 | 14:50.54 |
| | did you send the right one? | 14:51.00 |
| kens | LOL OK what version of Acrobat are you opening it with ? | 14:51.00 |
| mvrhel_laptop | oh | 14:51.04 |
| kens | X shows a black gradient | 14:51.12 |
| mvrhel_laptop | vers 9 | 14:51.14 |
| kens | Try reader X or later | 14:51.23 |
| | Its set ot leaVE COLORS UNCHANGED, SO IT MAY BE A VIEWER THING | 14:51.50 |
| | oops caps lock sorry | 14:51.56 |
| mvrhel_laptop | oh | 14:51.58 |
| | it is the same as what we are getting now | 14:52.06 |
| | including the other gradients | 14:52.32 |
| | at least after my fix | 14:52.39 |
| kens | On page 15 you see a gradient at the top ? | 14:52.40 |
| mvrhel_laptop | no it is all black | 14:52.49 |
| | that is what I get after doing my fix for the bug | 14:52.55 |
| kens | Right, that's what I get in Acrobat X as well | 14:53.05 |
| | PDF file produced and consumed by Acrobat | 14:53.16 |
| mvrhel_laptop | ok. so I think I am good then with that | 14:53.28 |
| | do you agree? | 14:53.31 |
| | I also match the other gradients with green | 14:53.45 |
| kens | As far as I can see, the gradient *should* beblack, and that's what Acrobat produced for me, so yes | 14:53.51 |
| mvrhel_laptop | vers 9 has all monochrome | 14:53.51 |
| | for the ramps | 14:53.53 |
| | on that page | 14:54.09 |
| kens | Hmm I'm not sure they should all be monochomre, only the top one | 14:54.23 |
| mvrhel_laptop | well, with vers 9 all of them are monochrome. which surprised me | 14:54.42 |
| kens | I don't see that here iwth 9 | 14:55.00 |
| | The top 2 are black, the next 3 are grey | 14:55.12 |
| | HIVAL 1 def gs Dev_N_ciedef setcolorspace [- f -] F3 is purple to green | 14:55.25 |
| mvrhel_laptop | when I open the file you sent me with AR pro 9 page 15 has no color | 14:55.51 |
| kens | Really ? Just a moment | 14:56.07 |
| mvrhel_laptop | but with AR X it matches what I am getting with gs with my fix | 14:56.22 |
| kens | Acrobat 9 shows that page with colour for me | 14:56.38 |
| mvrhel_laptop | maybe I have a odd setting hold on | 14:57.05 |
| kens | Anyway I guess we don't really care what old versions of Acrobat do :-) | 14:57.12 |
| mvrhel_laptop | yes | 14:57.17 |
| kens | As far as I can tell from teh spec and the result of Acrobat, the 2 top gradients should be solid black (Dev_N_cieabc) | 14:57.46 |
| mvrhel_laptop | ok. that is what I thought | 14:58.09 |
| | thanks for helping with this kens | 14:58.19 |
| kens | No problem | 14:58.25 |
| mvrhel_laptop | Robin_Watts: if you fix fixed an issue I am fine with it | 14:58.28 |
| kens | I was serioulsy confused by the result with Jaws though | 14:58.38 |
| Robin_Watts | mvrhel_laptop: No, it doesn't change anything. | 14:58.40 |
| mvrhel_laptop | ? | 14:58.48 |
| | ok | 14:58.52 |
| | if it fixed a style issue that is fine too | 14:59.08 |
| | but that is changing something | 14:59.17 |
| Robin_Watts | It looks to me like there used to be some code in there that would set some #defines one way if we were using compressed colors, and another way if we were using planar colors. | 14:59.18 |
| mvrhel_laptop | oh you could chop out the compressed stuff probably | 14:59.37 |
| Robin_Watts | and the compressed colors stuff has all gone now. | 14:59.41 |
| mvrhel_laptop | yes | 14:59.43 |
| Robin_Watts | which has left us setting some #defines and then using those defines later. | 14:59.57 |
| | It's neater to just use the values and remove the #definery. | 15:00.07 |
| | It's a style change as you say. | 15:00.12 |
| mvrhel_laptop | ok. psd and tiff may both need this clean up | 15:00.13 |
| | tiffsep | 15:00.20 |
| Robin_Watts | I haven't looked in tiffsep. | 15:00.31 |
| mvrhel_laptop | I did those two in parallel when we did the move to planar | 15:00.47 |
| Robin_Watts | VS2005 is very crashy today :( | 15:00.51 |
| mvrhel_laptop | need to go | 15:00.55 |
| | bbiab | 15:00.56 |
| Robin_Watts | mvrhel_laptop: Right. I will look later. Thanks! | 15:01.02 |
| | chrisl: ping | 15:43.11 |
| | In devs.mak I need to build a utility file to go with 801s device. | 15:43.39 |
| chrisl | Robin_Watts: pong | 15:43.39 |
| Robin_Watts | Do I use DEVCCSHARED for that ? | 15:43.52 |
| | or just DEVCC ? | 15:44.05 |
| chrisl | This is a object file, not a standalone utility? | 15:44.43 |
| Robin_Watts | i.e. does DEVCCSHARED mean something to do with shared libraries? OR something to do with code shared between devices? | 15:44.51 |
| | it's an object file. | 15:44.54 |
| | The code for a particular compression type is in another file. | 15:45.14 |
| chrisl | You want DEVCC - DEVCCSHARED, IIRC, is for "dynamic" devices. | 15:46.12 |
| Robin_Watts | right. thanks. | 15:46.20 |
| ray_laptop | morning, all | 15:57.15 |
| Robin_Watts | morning | 15:57.20 |
| kens | Morning | 15:57.25 |
| ray_laptop | Robin_Watts: how's it going cleaning up the customer's code ? Have you run away screaming, or are you still demolishing it ? | 15:57.54 |
| Robin_Watts | It has just linked for the first time. | 15:58.04 |
| | I've removed the customers copy of all the devn code. | 15:58.22 |
| | so I think that counts as progress. | 15:58.32 |
| ray_laptop | Robin_Watts: yes, that's something. | 15:59.28 |
| | should make what remains more understandable | 15:59.47 |
| henrys | just fyi some folks can't get a bounty i.e. norbert so we do equivalent $ amount to a charity of their choice. In case you know somebody who wants to work but is not allowed to take money from us... | 16:00.42 |
| ray_laptop | chrisl: I saw you and Robin_Watts mentioning a better way for customers to add custom PS operators. I think that's a great idea | 16:01.11 |
| chrisl | ray_laptop: I think that would be useful, yes. Another interpreter of my acquaintance has that, and it was quite regularly used | 16:02.25 |
| Robin_Watts | ray_laptop: I can't see why they need this. | 16:03.11 |
| ray_laptop | Robin_Watts: (or anybody else). A potential customer wants to know if "mupdf on Windows supports printing" | 16:03.22 |
| Robin_Watts | ray_laptop: Depends what they mean. | 16:03.42 |
| | If they mean "can mupdf drive any standard windows printer" the answer is currently no. | 16:04.05 |
| kens | You can't create a printer DC and blit a bitmap to it ? | 16:04.28 |
| ray_laptop | They want to use mupdf to "view XPS content", not clear to me what they mean either. Possibly they want to print it from the viewer | 16:04.32 |
| kens | I know its inefficient, but.... | 16:04.36 |
| Robin_Watts | If they mean "can it drive specific models, or airprint etc" then the answer is yes. | 16:04.39 |
| | kens: Right, but we have no code to do that. | 16:04.47 |
| kens | OK, presumably it wouldn't be too hard to add | 16:05.02 |
| Robin_Watts | We'd need code to speak to the system to figure out resolution, and do the gui for number of copies, printer selection etc. | 16:05.23 |
| kens | I think all the copies and stuff is handled by the prtiner driver isn't it / You just need the resolution and colour depth | 16:05.46 |
| | And even then, only if you want to do a good job, you can shove a bitmap straight onto a DC as I recall | 16:06.07 |
| Robin_Watts | kens: Your gui needs to handle that, AIUI. | 16:06.08 |
| kens | Robin_Watts : Yes, but its all system stuff as I remember | 16:06.29 |
| | Unless you want custom stuff you just call the system ones | 16:06.38 |
| Robin_Watts | but yes, if they are prepared to do the hooking up, mupdf can certainly provide a bitmap. | 16:06.46 |
| | but we don't offer an out of the box printing solution. | 16:06.58 |
| kens | It has been a very long time though.... | 16:07.00 |
| ray_laptop | kens: and Robin_Watts : That's exactly the way GS drives windows printer with the mswinpr2 device. | 16:07.32 |
| kens | ray_laptop : yes | 16:07.41 |
| | But that only allows for the printer defaults I think (I could be wrong) so you have to set up the printer to the correct default state first. | 16:08.23 |
| ray_laptop | So having the mupdf "borrow" code from the gs device that gets the info needed for the bitmap would be fairly easy | 16:08.24 |
| | the mswinpr2 device brings up the print dialog | 16:08.52 |
| kens | OPK so the system one is easy to do I thought I remembered it being sim[ple | 16:09.14 |
| ray_laptop | by default. There is a way to suppress that, | 16:09.16 |
| Robin_Watts | ray_laptop: That's something that should probably happen in the context of a new viewer. | 16:09.16 |
| Robin_Watts | hides from mvrhel_laptop. | 16:09.32 |
| ray_laptop | Didn't mvrhel just do a new viewer, or is that only on Win 8 ? | 16:10.00 |
| | I told Scott to ask the customer what they mean by "can it print" | 16:10.52 |
| Robin_Watts | ray_laptop: mvrhel has done a Win8 viewer. | 16:11.26 |
| kens | suspects they wanit it to print via the windows print system | 16:11.28 |
| Robin_Watts | He is going to look at porting that back to Win-non-8, I believe. | 16:11.48 |
| ray_laptop | kens: possibly. And since they are starting with an XPS, can't we just stuff that to the printer pipeline ? | 16:12.03 |
| kens | ray_laptop : only on WIndows 7 and above I think | 16:12.18 |
| | I do have code to do that though | 16:12.27 |
| ray_laptop | kens: cool. | 16:12.43 |
| chrisl | XPS printing should work on Vista - as if anyone cares..... | 16:12.56 |
| kens | is embarrased to admit it was trivial to do | 16:13.02 |
| ray_laptop | so if henrys ever gets xpswrite working, we could use that to print from gs "high level" instead of bitmaps | 16:13.19 |
| Robin_Watts | ray_laptop: I can probably answer some of his questions based on that email. | 16:13.21 |
| kens | chrisl I think the printing system is broken there, the right bits weren't aded until 7 | 16:13.22 |
| | Ah I see he wants a GDI solution | 16:13.51 |
| Robin_Watts | Do we all get copied on support emails now? | 16:13.53 |
| kens | But if all he wants is XPS prtined, we can indeed just stuff the XPS down the windows piepline] | 16:14.12 |
| ray_laptop | Robin_Watts: I hadn't seen the email. I told Scott to cc us so the appropriate person could get answers. | 16:14.16 |
| chrisl | kens: so it was *supposed* to work on Vista, but was broken..... | 16:14.20 |
| Robin_Watts | ray_laptop: It's on support and tech now. | 16:14.27 |
| kens | chrisl, yep, pretty much | 16:14.27 |
| ray_laptop | Robin_Watts: but send answers to Scott and let him forward it | 16:14.37 |
| kens | It works, but not in a way that apps can use to push XPS files with | 16:14.41 |
| ray_laptop | Robin_Watts: everyone is supposed to be cc'ed on all support email AFAIK | 16:15.10 |
| Robin_Watts | ray_laptop: OK, so I'll just copy it to support rather than tech. scott has copied it to both. | 16:15.35 |
| henrys | ray_laptop:xps is a vector device and it works about as well as pswrite with the same problems. So good coverage and poor performance. | 16:20.10 |
| | xpswrite | 16:20.37 |
| Robin_Watts | henrys: We were discussing mupdf. The xpswrite device for mupdf is not advanced :) | 16:24.29 |
| henrys | sorry I was responding to ray_laptop's "if henrys ever gets xpswrite working â¦" comment which seemed to indicate he thought it was a raster device. | 16:27.16 |
| Robin_Watts | henrys: Oh, sorry. I missed that :( | 16:29.24 |
| ray_laptop | sorry. The boss called | 16:39.12 |
| | henrys: no, I knew it wasn't raster. I just didn't know how far along it was w.r.t. text, etc. | 16:39.51 |
| henrys | I can't release it until after the new year so I haven't fooled with it much. | 16:40.25 |
| ray_laptop | for pushing XPS through the windows print pipeline, it would be nice to have text not as bitmaps (as pswrite has), primarily to avoid having text be resolution locked | 16:41.37 |
| | henrys: I recall now the reason for not releasing until next year | 16:42.10 |
| | Robin_Watts: BTW, I checked and support goes to all the engineers and to Scott and to the artifex-support mailing list on ghostscript.com | 16:46.07 |
| Robin_Watts | ray_laptop: Cool. Well, I replied. | 16:46.28 |
| kens | Night all | 16:53.31 |
| ray_laptop | ISTR that we discussed moving from an Aug release to Sep -- was I asleep and dreaming that at the staff meeting ? | 17:44.49 |
| | It was because so many people take vacation just before the kids go back to school | 17:45.31 |
| Robin_Watts | ray_laptop: I think I shared the same dream. | 17:45.40 |
| ray_laptop | of course, that's not Robin's excuses -- he probably schedules his trips to coincide with releases on purpose ;-) | 17:46.22 |
| Robin_Watts | ray_laptop: But I do schedule my work to be finished before the releases :) | 17:47.00 |
| Robin_Watts | has no kids, but Helen does teach in a school. | 17:47.30 |
| | So I'm stuck to the same holiday schedules as everyone else :( | 17:47.47 |
| ray_laptop | Oh, this is interesting. I put a little PS snippet in a reply to a customer to copy stdin to stdout. I tested it (once) on Windows before doing it, and when I typed "test" it echoed "gest". I thought I had hit the wrong key. | 17:52.09 |
| | but I just ran it again, and it did it again. | 17:53.25 |
| | but now it's working as expected. :-/ | 17:54.23 |
| Robin_Watts | ray_laptop: Can you sanity check me for a moment? | 18:09.36 |
| | 801 has 2 devices one a cmyk one, and one a cmyk + 1 other colorant one. | 18:10.01 |
| | Neither is expected to work with additional spot colors, right? | 18:10.14 |
| | i.e. the device shouldn't allow extra spots colorants to be defined in a PDF file to actually come out as a separate components? | 18:11.03 |
| | Any such colorants should just be mixed down onto the starting components. | 18:11.17 |
| ray_laptop | Robin_Watts: sorry. I think that's how those devices work, yes. But I don't know if they will have other printer options also. Some inkjet manufacturers have models with multiple optional inks, or even coatings. | 19:19.20 |
| | Robin_Watts: I don't think we know enough about all of the product options or products that may be part of their offering. | 19:20.03 |
| | Robin_Watts: This is just their "evaluation" phase so they may have started with the CMYK+1 as an example just to evaluate multiple ink support | 19:20.51 |
| | Robin_Watts: AIUI devices can tell the graphics library what spot colors they have and a colorant that isn't available uses the tint transform (mvrhel: just in time). | 19:22.38 |
| mvrhel_laptop | internet troubles this morning | 19:22.57 |
| | ray_laptop: yes that is correct | 19:23.45 |
| ray_laptop | mvrhel_laptop: thanks | 19:23.58 |
| | Robin_Watts: so, if I understand what you are asking "Neither is expected to work with additional spot colors, right?", then these devices don't support more than 4 (or 5) colorants | 19:25.29 |
| | but I think the 5th colorant should be able to be accessed as a SpotColor as well as being painted by something out of their ICC profile | 19:26.34 |
| | It is permissible to have a device that has 5 or more colorants that doesn't allow the extra colorants to be accessed as SpotColors. This is common with inkjets that have orange and green inks to expand the gamut, but as devices are just CMYK (the ICC profile provides the extra colors) | 19:28.27 |
| | Robin_Watts: or even and RGB device that actually converts the sRGB to 6 colorants | 19:29.12 |
| mvrhel_laptop | Robin_Watts: so I fixed the winRT mupdf MT stuff. it works nicely now. I will get this committed later today and send you an email to review and push to golden i | 19:45.50 |
| | if you don't mind looking at it tomorrow | 19:46.16 |
| | I don't know how it ever worked before.... | 19:46.46 |
| ray_laptop | mvrhel_laptop: just to make sure I understand. You windows mupdf viewer is only for Windows 8, right ? | 19:47.43 |
| mvrhel_laptop | ray_laptop: yes | 19:47.58 |
| ray_laptop | OK. Thanks | 19:48.06 |
| mvrhel_laptop | after I fix a few more things then I will get the phone version working. then I will work on a desktop version that includes gs and mupdf to replace gsview | 19:48.35 |
| | that will work on general version of windows | 19:48.47 |
| ray_laptop | mvrhel_laptop: right. But not until 2014 :-) | 20:09.57 |
| | hmm I tried starting a regression run with: gs bmpcmp that usually queues both up, but this time the bmpcmp didn't make it. The previous one was still running. Maybe that confused that mess of perl code ? | 20:11.37 |
| | Also, not sure why the bmpcmp run rebuilds things. After all it's working in a user area and working from the previous run's differences. Shouldn't it use the same binaries ? | 20:13.01 |
| | I did a separate bmpcmp request and it is pending, now. | 20:13.46 |
| mlq | Hello! I am trying to use the fz_search_text_page function from the mupdf project, but since it does not work for me, I guess I am doing something wrong. I've extracted the code and uploaded it here: http://pastie.org/private/i08h645tuxdfhbu1cow - I would appreciate any help if anyone could point me in the right direction | 20:41.32 |
| | Ah, nevermind. I guess I've figured it out. Need more sleep. - Thanks for your time anyway :) | 20:51.58 |
| Robin_Watts | ray_laptop: For the logs; yes, that's what I am shooting for. | 23:00.11 |
| | mvrhel_laptop: Fab. | 23:00.30 |
| mvrhel_laptop | have a good night Robin_Watts | 23:00.57 |
| Robin_Watts | mvrhel_laptop: thanks. you too. | 23:01.12 |
| | Forward 1 day (to 2013/10/24)>>> | |
IRC Logs