| | <<<Back 1 day (to 2014/05/26) | 2014/05/27 |
| kens | Hmm tehre's a fundamental problem with the XPS interpreter, pdfwrite and non-Latin languages. The XPS interpreter sets teh font type to 42, and then uses glyphs outside the range 0-255. When encoding the output font, pdfwrite can't find the non-Latin glyphs in the Encoding, so it effectively fails. | 08:03.21 |
| chrisl | Well, really, the problem is that the graphics lib doesn't have a "truetype" font type...... | 08:06.34 |
| kens | Yes, though I think if the font type were 11, and we were passing multi-byte glyph IDs this would work. | 08:07.18 |
| chrisl | Hmmm, can we use a "bare" type 11 like that?? | 08:08.55 |
| kens | I'm not sure, but I don't fancy rewriting the XPS interpreter to handle this | 08:09.30 |
| | Its a similar (but different) problem to Werner's glyphshow | 08:09.51 |
| | Essentially I'm getting collisions in the name space | 08:10.21 |
| chrisl | It shouldn't be a huge problem to create a type 0 font with an idenity cmap..... | 08:10.23 |
| kens | With a type 42 descendant ? | 08:10.46 |
| chrisl | No, type 11 | 08:10.55 |
| kens | Yeah I meant 11 | 08:11.04 |
| | I think we would need to handle all fonts that way in XPS | 08:11.25 |
| | There are only TrueType fonts in XPS, and we can't know in advance what glyphs are used | 08:11.48 |
| chrisl | Actually, with a a type 11, you might be fine using the glyphshow approach, which would be okay with the "bare" type 11 | 08:12.20 |
| kens | Hmm, looks like that would require quite a lot of change sin the XPS interpreter | 08:12.47 |
| | It calls gs_text_process directly | 08:13.01 |
| chrisl | what should it call? | 08:13.25 |
| kens | Going the glypshow route is 'different', I don't remember exactly how. Possibly there is no difference, as we end up using TEXT_FROM_GLYPHS insterad of TEXT_FROM_SINGLE_GLYPH (which is hwo glypshow works) | 08:14.28 |
| chrisl | You can always open a bug, and assign it to me, and I'll look at it when I have time | 08:15.21 |
| kens | I'll keep playing for now, its related to Werner's problem | 08:15.40 |
| chrisl | Could Werner's problem be addressed by forcing a new subset font? | 08:16.27 |
| kens | Technically yes, I think | 08:16.45 |
| | But the problem occurs in 2 parts separated by a lot of other code operations, and I'm not certaineither can tell without the other what the problem is, andtehre's no way to communicate between the 2 | 08:17.28 |
| | In isolation each does what it should (and tehre are valid code paths that go through these), its only incombination there's a problem | 08:17.54 |
| chrisl | Hmm, well, other solutions seem even more convoluted...... | 08:18.04 |
| kens | In essence step 1 would need to detect a problem and start a new font, but we don't detect the problem until we reach step 2, by which time its too late to start a new font.... | 08:18.38 |
| | Basically pdfwrite doesn't handle glyphshow very well, which is not surprising given that you can't do it in PDF and itsa normally a fairly rare occurence | 08:19.26 |
| | OK I *might* be able to sort Werner's problem, I definitely can't do anything with the XPS intrerpreter as long as it persists in using a Type 42 font. This is because we assume you can't use more than 255 glyphs from a 'regular' font, so we don't have the capacity in the pdfwrite structures to carry around multiple subsets for these fonts. | 08:41.51 |
| | I'll have a go at Werener's problem and see if any more light penetrates | 08:42.28 |
| jhabjan | hi, there is some issue with hidden layers and the ghostscript and it's display device when pdf file is opened via "(visible_invisible_layers.pdf) (r) file pdfopen begin" | 08:53.35 |
| | this cannot be reproduced via command line | 08:54.12 |
| kens | Hard to see how running form the command line could be different | 08:54.55 |
| | Presumably you are sending that PostScript to Ghostscritp from the command line ? | 08:55.22 |
| jhabjan | well, I did check the pdf via GSView... and it suffers from a same problem | 08:55.24 |
| kens | AFAIK GSView uses the command line | 08:55.39 |
| | But it also does all kinds of other stuff, including redefining resoruces | 08:56.08 |
| jhabjan | well, i thinkg GSView also calls 'gsapi_run_string' | 08:56.18 |
| kens | Don't know, maybe it does under some conditions, it doesn't for all cases though | 08:56.38 |
| jhabjan | The file: https://www.dropbox.com/s/9esexkk7qzb4cic/visible_invisible_layers.pdf | 08:56.57 |
| | when opened via command line, second layer is not shown ( which is ok, as it's invisible ) | 08:57.22 |
| | when opened in GSView, the second layer is shown | 08:57.45 |
| kens | Well, whenI try your PostScript I et an 'undefined in pdfopen' error | 08:59.20 |
| jhabjan | In Ghostscript.NET I open PDF in a same way GSView does. | 08:59.32 |
| kens | OK you have to open the dictionary 'pdfdict' before you can use pdfopen, anything else you haven't mentioned ? | 09:04.45 |
| jhabjan | you can take a look at here: http://pastebin.com/FRcbffgV | 09:05.12 |
| kens | You appear to be running another dictionary called GS_PDF_Procset | 09:06.41 |
| | OK well you haven't initialised CumulativePageCOunt | 09:07.15 |
| | THough that won't make a difference here | 09:07.22 |
| | I don't see any code to render the page there | 09:08.08 |
| tor8 | kens: gxps also does type1 fonts (for opentypes with CFF data) | 09:08.39 |
| | but I assume the same assumption of only using 255 chars applies there too | 09:08.54 |
| kens | Yes, all basic font types can only handle 255 glyphs | 09:09.09 |
| tor8 | yeah, I think you'd need to rewrite to the equivalent of a Type2 CIDFont for the TTFs? | 09:09.50 |
| kens | Because the XPS interpreter uses TEXT_FROM_GLYPHS pdfwrite essentially treats it as a PostScript 'glyphshow' operation, I think that's the only way to get that from PostScript | 09:09.53 |
| | yor8 yes, some kind of CIDFOnt would be needed. | 09:10.09 |
| tor8 | kens: yeah, glyphshow is the only way is ps to access the glyphs directly bypassing the encoding | 09:10.21 |
| kens | Or a Type 0 (OCF) but that would be hard | 09:10.28 |
| | tor8 yes, which is why these two problems are related, but different. | 09:11.00 |
| tor8 | kens: xpsttf.c and xpscff.c are the bits that create the font structures, I don't think you would need to change anything else except those two | 09:11.10 |
| kens | I cna possibly solve the collision problem, but there's nothing I cna do if the XPS interpreter actually does use more than 255 glyphs. Or so I think at the moment, that may not be entirely true. THi sis all pretty hideous. | 09:11.42 |
| tor8 | the xpscff.c file has a lot of crap code to parse CFFs though, not sure if Alex finished the CFF-parser-in-C that doesn't depend on postscript | 09:11.53 |
| kens | Didn't Chris do that ? | 09:12.12 |
| jhabjan | kens: http://pastebin.com/5qRYp04Y | 09:12.29 |
| | kens: at the bottom, there is showpage | 09:12.36 |
| tor8 | my memory is vague, maybe that was chris. anyway, the font code in xps is hideous and should be rewritten from scratch at the first best opportunity :) | 09:12.43 |
| kens | jhabjan : this will probably be a lot easier for me to look at if you just collect the PostScript you are sending to GS and give it to me, rather than me leafing through lots of .NET stuff which I don;t understand | 09:13.16 |
| jhabjan | but.. if it will be easier for you in C, GSView does a same, and in GSView this problem can be reproduced. | 09:13.35 |
| kens | tor8 possibly true, but how much do we really care ? | 09:13.36 |
| | jhabjan : it would be a lot easier in PostScript. | 09:13.49 |
| tor8 | kens: enough not to just 'rm -rf gxps' ;) | 09:14.13 |
| kens | jhabjan : the basic point is that you aren't supposed to meddle with these procedures. When I modify the PDF interpreter I don't expect that anyone except us is going to call these routines, so the only effort I make is to ensure that *our* code behaves as expectged. The introduction of CumulativePageCount broke GSview for instasnce. | 09:15.08 |
| | tor8 yeah, but.... This only matters for pdfwrite..... | 09:15.28 |
| tor8 | kens: that's the only use for gxps I imagine has any traction though... | 09:15.52 |
| kens | jhabjan : just collect together the PostScript sequence you are sending to GS, and put that all in a text file. Then feed that file to GS, does hte problem occur ?> | 09:16.14 |
| jhabjan | kens: http://pastebin.com/9L1jiCtR | 09:17.18 |
| kens | and does hte problem occur ? | 09:17.44 |
| jhabjan | kens: yes, it behaves a same | 09:19.32 |
| kens | One of the first things I would do is move the setpagedevice *before* you open teh PDF file and do all the setup, as setpagedevice resets lots of stuff. | 09:19.42 |
| jhabjan | kens: the thing is that i need to use setpagedevice before each page is shown | 09:20.30 |
| | kens: this way zoom-in and zoom-out is implemented | 09:20.49 |
| kens | You may well need to reset the PDF file then. | 09:21.17 |
| jhabjan | kens: for test, I removed page setup completely, so now I don't even use setpagedevice....but the problem remains | 09:23.35 |
| kens | I was speculating more generally. | 09:23.53 |
| | It can't be affecting this case | 09:24.06 |
| | Your test file can be reduced to : | 09:26.13 |
| | %!PS | 09:26.13 |
| | (/temp/layers.pdf) (r) file | 09:26.13 |
| | runpdfbegin | 09:26.13 |
| | 1 pdfgetpage /Page exch store | 09:26.13 |
| | Page pdfshowpage_init pdfshowpage_finish | 09:26.13 |
| jhabjan | ok, i tested your reduced postscript.. | 09:27.45 |
| | it shows hidden layer anyway | 09:27.53 |
| kens | Here's an even more reduced version: | 09:27.59 |
| | %!PS | 09:27.59 |
| | (/temp/layers.pdf) (r) file | 09:27.59 |
| | runpdfbegin | 09:27.59 |
| | 1 pdfgetpage | 09:27.59 |
| | pdfshowpage | 09:28.00 |
| | ANd yes, I know it does, that's the point. | 09:28.10 |
| | back in a minute | 09:29.13 |
| jhabjan | ok, no worries... any suggestion how I could set some flag to discard hidden layers (if any) ? | 09:31.09 |
| kens | Clearly it *is* normally set up to do so, so there is something in the initialisationthat you aren't doing, because you are going 'behind the scenes' and running internal code. | 09:31.55 |
| | OK hte problem is you aren't executing 'process_trailer_attrs | 09:32.48 |
| | In there you will find a comment : | 09:33.17 |
| | % Initialize OC groups | 09:33.27 |
| | Trailer /Root knownoget { | 09:33.27 |
| | % By default, OCGs are 'on'; mark only 'off' OCGs. | 09:33.27 |
| | % If, contrary to the spec, BaseState is OFF, mark all OCGs | 09:33.27 |
| | % and unmark ON ones. Bug 691491. | 09:33.27 |
| | SO if you don;t run that code, then optional content groups will be left unmarked and always processed. | 09:33.51 |
| | This code works: | 09:34.40 |
| | %!PS | 09:34.40 |
| | (/temp/layers.pdf) (r) file | 09:34.40 |
| | runpdfbegin | 09:34.40 |
| | process_trailer_attrs | 09:34.40 |
| | 1 pdfgetpage | 09:34.41 |
| | pdfshowpage | 09:34.41 |
| jhabjan | kens: brilliant | 09:35.13 |
| | thank you very much | 09:35.28 |
| kens | NP | 09:35.32 |
| | I still don't really recommend this though. | 09:35.44 |
| jhabjan | I understand | 09:35.56 |
| | no worries | 09:36.03 |
| kens | I am hoping, eventually,to rework the PDF interpreter to make it easier to draw individual pages, but its a long term project. | 09:36.39 |
| jhabjan | the thing is that there are a lot of users using Ghostscript.NET... and at this point, it's hard to change something and not to mess up the logic.. | 09:37.22 |
| kens | LOL you shold try working on teh Ghostscript PDF interpreter...... | 09:37.43 |
| | Its like playing whack-a-mole | 09:37.51 |
| jhabjan | :) yep, I figured that out... :) and I also know that if you change some internal procedures that Ghostscript.NET could easily break.. | 09:39.12 |
| | that bit I did not think about when I started writing Ghostscript.NET | 09:40.18 |
| kens | Sadly there is as yet no defined API to use | 09:40.48 |
| | One day, I hope..... | 09:40.54 |
| tkamppeter | Robin_Watts, hi | 10:26.39 |
| Robin_Watts | tkampeter: (For the logs) Sorry, was running. back now. | 11:26.54 |
| hmrc87 | Hi is it possible within ghostscript to do the imagemagick-command "pdf:use-cropbox=true"? | 11:30.27 |
| Robin_Watts | hmrc87: interesting nick :/ | 11:32.14 |
| | There is a -dUseCropBox param to gs. | 11:33.05 |
| | If you run imagemagick with the appropriate flag, it will tell you exactly what gs command it uses. | 11:33.34 |
| | "-debug All" I think. | 11:38.30 |
| kens | I'd bet the ImageMagick command simply turns into a -dUseCropBox there are also -dUseTrimBox -dUseBleedBox and -dUseArtBox | 12:04.39 |
| | In teh absence of any of the flags, or if the requested Box is not present in the file, we use the MediaBox | 12:05.42 |
| | Hmm, well I may have a fix for Werner..... I'm not completely sure I follow what the code is doing, so this counts as hackery of the first order, but it seems to be OK with his test file. Time for a cluster run | 12:26.52 |
| tor8 | Robin_Watts: a few commits on tor/master | 12:33.48 |
| kens | Crumbs, my hackery works for the XPS file as well O.O | 12:36.06 |
| hmrc87 | Thank you for your help, I used dUseCropBox | 12:46.10 |
| kens | You're welcome | 12:47.39 |
| hmrc87 | Is there an option to optimize Textrendering when converting PDF to JPEG | 13:02.30 |
| chrisl | What do you mean by "optimize"? | 13:02.59 |
| kens | Almost certainly the sanswer is no. Don't use JPEG for content with sharp edges | 13:03.03 |
| hmrc87 | I think Photoshop is doing a way better job compared to Standard Settings in gs | 13:03.06 |
| tor8 | hmrc87: don't use JPEG, text in JPEG looks crap | 13:03.06 |
| | but if you must, increase the 'quality' setting | 13:03.25 |
| hmrc87 | The problem is: I'm stuck with JPG for our Outputengine :/ | 13:03.25 |
| tor8 | hmrc87: if you're rendering text, strongly consider using PNG instead | 13:03.42 |
| hmrc87 | ah ok I try increasing the jpeg-quality Setting | 13:03.47 |
| kens | You can incfrease the JPEG quality at the expense of compression, that's abou tit | 13:03.51 |
| chrisl | Depends what "optimize" means..... | 13:04.14 |
| tor8 | chrisl: "This web page is optimized for 800x600." ;) | 13:04.34 |
| chrisl | tor8: well, I would previously have taken it to mean "make sharper", but based on the discussion of the other day, it might mean "make fuzzier"...... | 13:05.35 |
| lokesh | hii | 13:08.02 |
| | i was trying to look into mupdg android code | 13:08.16 |
| | pdf | 13:08.28 |
| | ?? | 13:08.29 |
| | is anybody ol | 13:08.35 |
| sebras | lokesh: there are several mupdf devs around, feel free to ask questions. | 13:08.51 |
| lokesh | mupdf 1.4 | 13:09.08 |
| | for android | 13:09.13 |
| | we are unble to create .so file | 13:09.21 |
| | can you help me with that | 13:09.26 |
| tor8 | lokesh: follow the ReadMe.txt instructions to the letter | 13:09.52 |
| sebras | lokesh: platform/android/ReadMe.txt | 13:10.12 |
| tor8 | sebras: if you got a minute, there are a few minor commits to review on tor/master (all affecting the x11 viewer) | 13:10.29 |
| sebras | tor8: I'll have a look. | 13:10.42 |
| kens | ROFL tor's bug purge has shown up in Marcos' reporrt "Closed bugs : 66" | 13:11.16 |
| lokesh | tried that | 13:11.51 |
| tor8 | kens: what, ONLY 66? I thought I'd closed way more than that :) | 13:11.52 |
| lokesh | afeter evrything it says some files are missing | 13:12.05 |
| kens | Maybe some came in last weeks report..... | 13:12.07 |
| tor8 | kens: yeah, I've been at it for a few weeks | 13:12.21 |
| kens | We still have 660 bugs though :-( | 13:12.48 |
| lokesh | <sebras> ::::: tried readme but still some files are missing | 13:12.57 |
| | it says | 13:13.00 |
| tor8 | "some files are missing" is not a very helpful error message | 13:13.33 |
| | which files, and in which step? | 13:13.41 |
| lokesh | sure just min i will copy the log | 13:14.25 |
| | and paste it here | 13:14.30 |
| sebras | lokesh: if you get a long error message or you want to provide a log paste it at pastebin.com | 13:14.34 |
| tor8 | lokesh: use pastebin.com if it's a long copy-paste | 13:14.39 |
| sebras | lokesh: and post the link. | 13:14.39 |
| lokesh | "Compile thumb : mupdf <= mupdf.c jni/mupdf.c: In function 'get_globals': jni/mupdf.c:254:28: warning: cast to pointer from integer of different size [-Wi nt-to-pointer-cast] jni/mupdf.c: In function 'Java_com_artifex_mupdfdemo_MuPDFCore_openFile': jni/mupdf.c:335:9: warning: cast from pointer to integer of different size [-Wpo inter-to-int-cast] jni/mupdf.c: In function 'Java_com_artifex_mupdfdemo_MuPDFCore_openBuffer': jni/mup | 13:14.47 |
| | this is the error | 13:14.57 |
| tor8 | that's a warning, not an error | 13:15.09 |
| lokesh | but still .so file is no generated | 13:15.24 |
| tor8 | if there was an error, it is truncated. use pastebin. | 13:15.31 |
| lokesh | pastebin ?? | 13:16.08 |
| tor8 | http://pastebin.com/ | 13:16.18 |
| sebras | is slower at typing than tor8. | 13:16.26 |
| lokesh | ha ha | 13:16.51 |
| | any idea why the .so file is no generated | 13:17.47 |
| tor8 | lokesh: like I said, paste the error mesasge into pastebin and copy the link here so we can read it. | 13:18.44 |
| lokesh | sure | 13:18.58 |
| | http://pastebin.com/embed_js.php?i=U3tn9MHf | 13:20.29 |
| | this is the log | 13:20.41 |
| | tor8:: got the link | 13:21.30 |
| | ? | 13:22.05 |
| kens | Patience..... | 13:22.13 |
| | Give people time to read what you pasted, and be aware we are all busy on other tasks | 13:22.31 |
| lokesh | thanks | 13:22.43 |
| tor8 | lokesh: hm, that looks odd. let me see if I can reproduce it. please give me a couple of minutes. | 13:23.23 |
| kens | breaks the 40 bug barrier again | 13:24.34 |
| lokesh | sure | 13:25.42 |
| tor8 | lokesh: it works on a clean build for me | 13:26.29 |
| | lokesh: which version of the code are you using? a fresh git checkout? | 13:27.19 |
| henrys | kens: in which direction? :-) | 13:27.36 |
| lokesh | no i just downloaded it form mupdf.com | 13:27.38 |
| kens | henrys, the right way, down to 39 :-D | 13:27.53 |
| lokesh | can you give me repository link | 13:28.09 |
| tor8 | lokesh: the command to clone from git is right on the front page on mupdf.com | 13:28.34 |
| lokesh | chekout link from git??? | 13:28.39 |
| | sure will use that | 13:28.46 |
| tor8 | lokesh: git clone --recursive git://git.ghostscript.com/mupdf.git | 13:28.53 |
| lokesh | thanx | 13:29.05 |
| hmrc87 | So ImageMagick is using an additional converting step to PNGALPHA while converting from PDF to JPG, that's why plain PDF->JPG with GS looks not as good | 13:40.46 |
| chrisl | So, like I said, you want fuzzy text, then..... | 13:41.16 |
| | -dTextAlphaBits=4 | 13:41.28 |
| hmrc87 | I want smooth text ^^ | 13:42.10 |
| chrisl | One man's smooth is another man's fuzzy..... | 13:42.35 |
| | But -dTextAlphaBits=4 is what you want | 13:42.50 |
| tor8 | kens: one reason to upgrade to Win8 ... I've heard they've dropped the cleartype color fringing (at least from parts of it) | 13:43.19 |
| kens | Ooooh, tempting, but not yet quite tempting enough I fear | 13:43.35 |
| tor8 | the metro tiles and internet explorer don't use cleartype, not sure about other desktop applications | 13:43.53 |
| kens | Oh, I bet they still do :-( | 13:44.07 |
| tor8 | and I don't fancy installing it myself, even tempting as lack of cleartype is | 13:44.10 |
| kens | I can always turn off cleartype :-) | 13:44.24 |
| tor8 | yeah, but windows 7 font rendering without cleartype is even more atrocious :( | 13:44.52 |
| Robin_Watts | hmrc87: Any conversion that goes anywhere near JPEG will give you awful text. | 13:45.00 |
| kens | Sadly this is true | 13:45.04 |
| | I do have cleartype turned on, but carefully tweaked to suit me | 13:45.22 |
| | I'm sure many people woudl dislike my settings | 13:45.32 |
| chrisl | Robin_Watts: the text problems with JPEG are much reduced if it's antialiased.... | 13:45.57 |
| kens | Yes, because it avoids the high frequencies | 13:46.10 |
| | By making the text fuzzy | 13:46.17 |
| chrisl | :-) Exactly | 13:46.24 |
| Robin_Watts | it reduces the high frequencies, but you'll still get extra blur in there due to the quantisation in the DCT. | 13:46.48 |
| kens | woujdl rather have nice crisp readable text | 13:46.48 |
| Robin_Watts | jpeg is just wrong for applications involving text. | 13:47.06 |
| kens | Robin_Watts : that's true, but many people find the blurring more acceptable that way round | 13:47.10 |
| tor8 | kens: bitmap fonts. it's what I use for my text editors. | 13:47.11 |
| chrisl | Apparently some people like blur in their text...... | 13:47.20 |
| kens | And yes, JPEG is the wrong answer for anything except photograhpic images, the clue is in the name..... | 13:47.43 |
| tor8 | if only they'd invented grayscale bitmap fonts before going all "oooh! scalable!" then "oh rats, it looks crap. ooh! hinting!" | 13:47.55 |
| | and then "oh noes, now it looks even worse..." | 13:48.07 |
| Robin_Watts | tor8: Acorn did. | 13:48.19 |
| kens | and 'look, I can make a font!' | 13:48.25 |
| tor8 | Robin_Watts: a shame the idea didn't catch on :( | 13:48.39 |
| chrisl | To me, "optimizing text" has always previously meant "make it more legible", and I rarely find anti-aliasing results in more legible text..... | 13:48.47 |
| kens | Oh seems I currently have ClearType turnewd off :-) | 13:48.54 |
| tor8 | still, in the next 10 years if the 200+dpi screens catch on, antialiased vector fonts aren't all that bad | 13:49.00 |
| | my biggest gripe is that nobody who does antialiased text bothers with proper subpixel accurate positioning... | 13:49.51 |
| chrisl | I just don't like hazy edges on glyphs | 13:50.15 |
| tor8 | if you're going to have blur, at least make it nice and even. but no, that's too difficult... | 13:50.17 |
| Robin_Watts | tor8: It took us long enough to get right. | 13:50.30 |
| | :) | 13:50.32 |
| tor8 | so now we have blur *and* odd gaps between letters | 13:50.34 |
| | Robin_Watts: only for type3 fonts ;) | 13:50.40 |
| | and upside down text :) | 13:50.53 |
| Robin_Watts | I'm still not convinced we get it right in all cases :( | 13:51.03 |
| tor8 | Robin_Watts: for all fonts, or just the type3s? | 13:51.27 |
| Robin_Watts | For type3's, I think. | 13:51.41 |
| tor8 | chrisl: that would explain why you still like nedit :) | 13:51.46 |
| | Robin_Watts: yeah. I'm not 100% convinced there either. | 13:51.55 |
| Robin_Watts | I thought that Michael had a case that went wrong in gsview at the last staff meeting. | 13:52.02 |
| tor8 | but a lot of type 3 fonts are oddly constructed | 13:52.05 |
| chrisl | tor8: quite possibly..... | 13:52.22 |
| tor8 | kens: http://www.fixedsysexcelsior.com/ a truetype that only works in one size, but has zero anti-aliasing at that size. | 13:54.30 |
| kens | :-) | 13:55.09 |
| chrisl | What a pointless waste of a TTF.... might as well go back to X11 fonts.... | 13:55.17 |
| tor8 | chrisl: yeah, but what do you do when MacOSX and windows don't support bitmap fonts anymore? | 13:55.38 |
| chrisl | tor8: I thought Windows at least still supported bitmap fonts | 13:57.00 |
| tor8 | chrisl: I'm not sure how good unicode support is with them though | 13:58.07 |
| chrisl | Probably non-existent.... | 13:58.24 |
| kens | fixedsys excelsior supports Ogham :-) | 13:58.26 |
| henrys | unless somebody feels a meeting is needed let's just spend the time reviewing the agenda and making sure that is up to date. Miles added some requests to the SOT section I didn't completely grok so those are just copy pasted. You cans email changes or post them here and I'll update the document. | 14:03.21 |
| tor8 | henrys: any news on the URW fonts? | 14:07.14 |
| henrys | tor8:no but I'll update the agenda to the current status and we'll discuss it. | 14:10.01 |
| tor8 | henrys: robin and I discussed doing a premature 1.5 release, there were a handful of fairly serious bugs that made their way into 1.4 | 14:10.32 |
| | might want to put that on the agenda as well | 14:10.44 |
| henrys | tor8:okay | 14:10.59 |
| jogux_mac | hi all | 14:11.21 |
| tor8 | one potential buffer overflow bug, and one that could corrupt files we save | 14:11.27 |
| Robin_Watts | and a big slowdown. | 14:11.36 |
| | henrys: Is it OK for me to share the workflowy URL with Joseph/Pete? Can't see why not, but... | 14:12.36 |
| henrys | Robin_Watts: sure | 14:13.26 |
| Robin_Watts | henrys: On the agenda under SOT... | 14:14.41 |
| | the font metrics stuff is done. | 14:14.46 |
| | #mia should be #miah | 14:16.48 |
| | #mace should now be #joseph | 14:16.56 |
| jogux_mac | thinks it might be good to generally review the SO UI. there's a few places I think it could be relatively easily improved. | 14:17.19 |
| kens | chrisl you applied a fix in bug #695227 but didn't close the bug,was that deliberate ? | 14:18.48 |
| tkamppeter | Robin_Watts, hi | 14:20.19 |
| Robin_Watts | tkamppeter: Hi. | 14:20.27 |
| chrisl | kens: mistake, I think | 14:21.05 |
| kens | Shall I close it ? | 14:21.11 |
| chrisl | I'm just doing it now | 14:21.24 |
| kens | OK thanks | 14:21.27 |
| tkamppeter | Robin_Watts, to continue the work of yesterday, I have tried (after a hint of Mike Sweet who I have asked via e-Mail) to convert the PDF to tiff. 8-bit CMYK works perfectly and 16-bit CMYK gives wrong colors, but this time much more wrong than with PWG Raster, consistently wrong for images and text/vector, so can be that GS has a bug or perhaps even that tiff and cups backends have different bugs. | 14:24.10 |
| Robin_Watts | tkamppeter: It strikes me that we should be able to construct a very simple test file to show this problem. Just a red square on an otherwise blank page. | 14:25.22 |
| tkamppeter | Robin_Watts, another question: does the data type gx_color_index have enough size to be able to carry 16-bit CMYK (64 bits)? Is this independent of the architecture (I am on Intel 64-bit). | 14:25.58 |
| Robin_Watts | tkamppeter: Yes. | 14:26.11 |
| | It would need to be a 64 bit type. | 14:26.19 |
| tkamppeter | Robin_Watts, I have also tested CityMap.pdf with the CUPS backend and there 16-bit CMYK is correct. We probably must somehow find out which color space is the text/vector part of launch_leaflet.pdf. | 14:28.00 |
| Robin_Watts | Different archs cope differently well with 64bit data types, but often 32bit arch can cope. | 14:28.09 |
| | tkamppeter: Really? My memory of CityMap.pdf is that it's largely text/vectors. | 14:28.47 |
| | tkamppeter: Can you open a bug with the example file, and the command lines for 16bit tiff and 16bit cups output please? | 14:29.34 |
| tkamppeter | Robin_Watts, I thin what is wrongly colored in the resulting file is not wrongly colored because it is vector, but because it is a special color space. | 14:30.35 |
| Robin_Watts | Ok, we can find that out by looking at the example file. | 14:31.02 |
| tkamppeter | Probably the images in launch_leaflet.pdf are another color space than the text/vector part. | 14:31.15 |
| Robin_Watts | indeed. | 14:31.37 |
| | but the images are correct, right? | 14:31.52 |
| | Henrys: For the coming staff meeting, Joseph has suggested that if we do GhostDocs first, he and pete may be able to join in remotely. | 14:32.27 |
| tkamppeter | Robin_Watts, as 16-bit CMYK TIFF CityMap.pdf comes out the same way wrong as launch_leaflet.pdf, so I bet on that in the TIFF case we have another bug than in the CUPS case. | 14:32.29 |
| Robin_Watts | tkamppeter: Indeed. | 14:32.39 |
| tkamppeter | Robin_Watts, all images are correct in launch_leaflet.pdf with the CUPS backend. | 14:33.06 |
| kens | THere's a /Separation Black colour space,and a shading using it | 14:33.14 |
| | That's the only non-device space | 14:33.48 |
| | All others are Gray, CMYK or Indexed CMYK | 14:33.56 |
| Robin_Watts | henrys: So, it turns out that apple have been inconsiderate and scheduled WWDC at the same time as our staff meeting. | 14:35.22 |
| | which means Joseph will be unavailable pretty much all monday. | 14:35.39 |
| | He might be back about 3pm SF time. | 14:35.47 |
| marcosw | morning | 14:35.55 |
| Robin_Watts | So possibly we should do gs and mupdf first, then ghostdocs last. | 14:36.19 |
| jogux_mac | robin_watts: well, I already made plans to join a beer+pizza+keynote party essentially | 14:36.40 |
| Robin_Watts | That way if we have any questions for joseph/pete we can either pull them in at the end of mondays meeting (if it's not too late in the UK) or at the start of tuesdays. | 14:36.46 |
| jogux_mac | Tuiesday I'd be fine all day until 3pm SF, or a bit later if necessary. | 14:37.00 |
| henrys | write the code, change the world he ought not miss that ;-) | 14:37.23 |
| pedro_pc | too | 14:37.27 |
| Robin_Watts | jogux_mac: If the meeting goes on to 3pm on tuesday, I think we'll all be killing ourselves. | 14:37.28 |
| | We can take a run at most stuff on monday, and make a list of awkward questions for you on Tuesday. | 14:38.49 |
| jogux_mac | robin: okay, so I reckon that makes any time Tuesday sane for SO then, whether it's us joining via skype if internet works, or via actual phones if that doesn't work out too expensive :) | 14:39.02 |
| Robin_Watts | You understand that because you won't be in the room, it'll all be your fault, right? :) | 14:39.03 |
| jogux_mac | okay, that works. | 14:39.07 |
| | if you can make a list of awkward questions to send to us by end Monday that even gives us a little time to research them :-) | 14:39.30 |
| Robin_Watts | will do. | 14:39.48 |
| henrys | pedro_pc, jogux_mac Also, if you have anything for the agenda let me know | 14:40.08 |
| jogux_mac | henrys : nothing currently springs to mind, but if it does I'll let you know. | 14:40.53 |
| henrys | marcosw: we agreed to just review the agenda for the meeting | 14:40.56 |
| Robin_Watts | marcosw: Could we have a MuPDF 1.4 option on bugzilla please? | 14:41.18 |
| | and possibly a 1.5 too :) | 14:41.22 |
| jogux_mac | henrys: we should maybe give you a SO update now anyway? | 14:41.23 |
| pedro_pc | henrys: sure. I guess with SO it would be good to figure out scope & direction for SO once we get out of this startup effort | 14:41.41 |
| marcosw | Robin_Watts: will do both 1.4 & 1.5. | 14:42.40 |
| Robin_Watts | Ta. | 14:43.11 |
| henrys | jogux_mac: that would be helpful. | 14:43.43 |
| rayjj | sorry I'm late and can''t participate much. I have to take the kids to school today | 14:44.23 |
| | but it looks like nothing has come up that I have comments on | 14:44.48 |
| kens | rayjj : henrys says just review the staff meeting agenda | 14:45.04 |
| | no IRC meeting today | 14:45.11 |
| jogux_mac | hernrys: so you may have seen on skype group, we think we're getting close to the non-Good app store releases with the rebranding / random fixes. only real major issue remaining (iirc) is giving the apps a good shakedown on real devices. | 14:45.25 |
| rayjj | kens: thanks. I'm still plowing thru the logs | 14:45.50 |
| henrys | pedro_pc: I think it's going to be pretty much customer driven sorted on revenue. There might be a case for UI work it does look a bit dated | 14:45.52 |
| kens | rayjj : you can ignore anythig I said ;-) | 14:46.16 |
| pedro_pc | henrys: cool - I think the UI could do with some sanitisation as its very gimmicky | 14:46.50 |
| jogux_mac | henrys: I'm back in the UK now; time I could spend over last 2 weeks was a bit limited but I did manage to make some good progress on ATS which is getting more useful, and has spotted a number of real looking bugs that have now been fixed, and I hope to have something sane-ish for ATS VMs to send back to Marcos in 1-2 weeks or so, so we can switch to running it on his (hopefully beefier) machines. | 14:47.19 |
| rayjj | kens: I did have a question about that encoding issue. Why not use the PDFDocEncoding as much as possible ? | 14:47.43 |
| kens | rayjj : doesn't work | 14:47.54 |
| rayjj | kens: OK. | 14:48.03 |
| pedro_pc | henrys: on the Good apps, Paul has the iOS app running with the caveat that there are some odd app-switches going on when trasferring files, and also that we're not currently 100% sure what exactly needs tested... | 14:48.32 |
| jogux_mac | henrys : oh, and pre-app-store update release we probably want to sort out what we're doing wrt to forums, so users have a place other than reviews to rant if we break something... | 14:48.43 |
| Robin_Watts | henrys: We have the font changes in, and all the bug fixes (from the release branch) are mapped down to master and pass tests etc. | 14:49.04 |
| kens | More accurately, I'd have to do a lot of rewriting, and it wouldn't gain us anything over whaqt we havenoew | 14:49.12 |
| Robin_Watts | so we actually have (I hope) a sensible place to start real development work from. | 14:49.18 |
| henrys | jogux_mac: I proposed discourse.org on the agenda. A few recommended it as well. | 14:50.11 |
| pedro_pc | on android we're pretty close to the iOS level of functionality but I'm having to do more of the 'optional' 1.6 SDK changes to get the app to behave nicely (partly just down to the way our app is put together) | 14:50.27 |
| Robin_Watts | henrys: Is the new website guy sorting that out? Or should we be? | 14:51.52 |
| henrys | Robin_Watts: we'll put a name on it at the meeting. | 14:52.22 |
| Robin_Watts | ok. | 14:52.44 |
| henrys | where is there documentation about ATS - is there something in "epage-docs"? | 14:53.16 |
| Robin_Watts | There is some documentation on the old twiki. | 14:54.31 |
| | henrys: First you need to set up an ssh tunnel as described here: http://twiki.ghostscript.com/do/view/GhostDocs/AutomatedTest | 14:55.36 |
| | That will also tell you where to get a proxy.pac from that you feed to your browser. | 14:55.55 |
| | That will redirect intranet.picsel.com through the ssh tunnel. | 14:56.07 |
| | Then you can read: http://intranet.picsel.com/twiki/bin/view/Projects/ATS | 14:56.16 |
| henrys | Robin_Watts: when can we move that stuff? | 14:56.52 |
| | I guess it will go to marcosw along with the ats | 14:57.10 |
| Robin_Watts | exactly. | 14:57.15 |
| | But the plan is that even then we will still use the ssh tunnel. | 14:57.29 |
| jogux_mac | henrys : I'm trying to santise ATS / get it working a bit more, it then will send VMs for everything back to marcos, yep. another week or two maybe. | 14:57.39 |
| Robin_Watts | That way all the proprietary stuff is kept secure. | 14:57.58 |
| | It'll just be a tunnel into marcosw's garage rather than into Josephs office. | 14:58.20 |
| paulgardiner_lap | Is there anything we can do to ensure that, should we ever need to set up ATS from scratch again, we'd be able to avoid a repeat of the same hell? | 14:59.06 |
| jogux_mac | paulgardiner: yes - I'm adding more stuff into git | 14:59.22 |
| Robin_Watts | paulgardiner_lap: I was just pondering that ATS is still a nightmare of complexity. | 14:59.32 |
| | I don't know how feasible it would be to strip out stuff that we really don't need to simplify it further. | 15:00.12 |
| pedro_pc | there are also docs in ats/docs in CVS which describe some of the architecture too, but I guess we're more interested in operational docs at present? | 15:01.06 |
| jogux_mac | paulgardiner: I may possibly resinstall some stuff from scratch before I send it back to marcos | 15:02.55 |
| | but not sure yet. part of the complexity is not ATS, but due to how the linux machines that underly it were configured (eg. the presenance of the ldap server on picsel's mail machine is assumed by the machines, but not by ATS, and similar with the main nfs fileserver and intranet) | 15:04.01 |
| Robin_Watts | When we got ATS from the liquidators, it was relying on doing builds on a very old version of debian (etch). | 15:04.17 |
| paulgardiner_lap | I suppose we achieve a lot by making sure we take good care of backing up the VMs, but I was just wondering if it was possible to script their creation... assuming the VMs are a big part of it which maybe they aren't | 15:04.21 |
| Robin_Watts | Joseph has pretty much got it so we can ditch that and just use a moderately old version (wheezy). | 15:04.41 |
| jogux_mac | wheezy is actually current I believe :-) | 15:04.54 |
| Robin_Watts | oh, wow, ok. | 15:05.02 |
| pedro_pc | yeah, still old though ;) | 15:05.30 |
| jogux_mac | wheezy's replacement isn't scheduled for release for another 6 months or so. | 15:05.30 |
| | one major piece of ATS I still haven't tackled yet is the windows build clients, as they weren't working at all in the version we got from the admins :( | 15:10.37 |
| marcosw | clearly isn't the fastest stick in the bunch, he just figured out where the debian release names are from. | 15:13.09 |
| jogux_mac | marcos: :) | 15:13.52 |
| pedro_pc | still can't believe that movie is old enough for even one debian version ;) | 15:17.26 |
| henrys | have a quick errand bbiab | 15:18.17 |
| tor8 | Robin_Watts: there's a handful of commits on tor/master for when you have a moment free | 15:19.41 |
| Robin_Watts | To be fair the new release will be named after a character only introduced in the second sequel. | 15:20.42 |
| | kens: ping. | 15:23.09 |
| kens | pong Robin_Watts | 15:23.16 |
| Robin_Watts | Bug 695116 | 15:23.32 |
| kens | Umm let me look | 15:23.40 |
| | Oh yeah | 15:23.50 |
| | I remember it now | 15:23.54 |
| Robin_Watts | This is the one about the jpeg in the PDF with a height of 0. | 15:23.56 |
| kens | And the odd marker yes | 15:24.03 |
| Robin_Watts | right. | 15:24.08 |
| | so the fix we have in mupdf for this is that when we open a jpeg stream, we check for the header saying '0' and put in the value specified in the PDF file. | 15:24.44 |
| kens | OK... | 15:24.51 |
| Robin_Watts | Then the jpeg lib reads that value and it's happy. | 15:24.58 |
| kens | I guess you want us to do that in GS too | 15:25.02 |
| Robin_Watts | I was just looking at doing that in GS. | 15:25.13 |
| kens | I'd assume we pass in the Height to the image operator from the PDF interpreter | 15:25.38 |
| Robin_Watts | I think we have an opportunity to do it (in gs_jpeg_create_decompress) | 15:25.44 |
| kens | Sounds reasonable but let me look | 15:25.55 |
| Robin_Watts | but I need to get the Height, as you say, from the PDF interpreter. | 15:25.56 |
| kens | which file is that ? | 15:26.00 |
| Robin_Watts | sjpegd.c | 15:26.14 |
| kens | OK 1 sec | 15:26.18 |
| | Oh right at the top of the file :-) | 15:26.55 |
| | OK, so you would need to put the image height in the stream_DCT_state | 15:27.15 |
| Robin_Watts | right. | 15:27.22 |
| kens | Doesn't seem onerous | 15:27.32 |
| Robin_Watts | It's getting the height from the PDF interpreter that I am unclear on. | 15:28.04 |
| kens | You don't get it from the PDF itnerpreter,you get it from teh 'image' operator | 15:28.19 |
| Robin_Watts | We're under zDCTD here. | 15:28.34 |
| kens | The PDF interpreter will create a dictionary with /Height in it | 15:28.35 |
| | Yes, so you need to get the Height in zimage and add it into the DCT state, just a second while I set a break | 15:29.01 |
| | Actually it might be set up elsewhere | 15:29.24 |
| chrisl | Width and height should be in the image enumerator, I thought | 15:29.37 |
| Robin_Watts | zimage doesn't get called. | 15:29.38 |
| kens | So I see, maybe its a differnt type of image | 15:29.49 |
| | I cna never keep these straight | 15:30.00 |
| | zimage1 maybe | 15:30.42 |
| | Nope | 15:31.06 |
| Robin_Watts | ok, so zDCTD will get called first. | 15:31.08 |
| | Then zimage1 | 15:31.11 |
| kens | Ah, that's not so good | 15:31.17 |
| | We won't have the Height until we get to zimage | 15:31.29 |
| Robin_Watts | That's fine, it's still early enough. | 15:32.13 |
| kens | OK | 15:32.35 |
| Robin_Watts | well, zimage is called before image_file_continue is, and it's in image_file_continue that I need to have done the fiddling. | 15:34.18 |
| kens | Oh, well you should be good in that case, the image enumerator should have the height I think, and you get to the 'continue' no matter what image type it is (I think) | 15:35.02 |
| tkamppeter | Robin_Watts, I would like to submit a bug but bugs.ghostscript.com is down. | 15:35.10 |
| Robin_Watts | I can do the fiddling in image_file_continue (or rather in gs_jpeg_read_header which is called from it), but do I have the image enumerator in image_file_continue ? | 15:35.24 |
| kens | worked for me 1 minute ago | 15:35.25 |
| Robin_Watts | tkamppeter: Is it? | 15:35.41 |
| kens | Still seems to be OK | 15:35.43 |
| Robin_Watts | works for me too. | 15:35.51 |
| chrisl | Seems fine to me too | 15:35.51 |
| kens | Robin_Watts : one moment | 15:35.53 |
| Robin_Watts | kens: thanks. | 15:35.58 |
| kens | Robin_Watts : in image_file_continue, penum->height | 15:36.40 |
| chrisl | I think I said that..... | 15:36.53 |
| kens | COuld be, I kind of got lost | 15:37.02 |
| chrisl | And it's Height | 15:37.11 |
| kens | its height in the code here | 15:37.24 |
| Robin_Watts | penum->height is indeed in image_file_continue | 15:37.49 |
| | but by the time I get down to stream specific stuff, I don't have penum any more :( | 15:38.05 |
| chrisl | Hmm, so not a gx_image_enum_s then...... | 15:38.08 |
| kens | no its a gs_image_enum | 15:38.19 |
| | Robin_Watts : I feared that might be true | 15:38.33 |
| chrisl | Well, no, streams aren't images.... | 15:38.39 |
| kens | exactly | 15:38.45 |
| chrisl | You'll have to add a new value to the dct state | 15:39.07 |
| kens | chrisl yes, but where to set it | 15:39.18 |
| Robin_Watts | chrisl: I have done that. The question is when can I set it. | 15:39.23 |
| | kens types faster :) | 15:39.28 |
| kens | At the time we set up the DCT state we don't know hte height | 15:39.33 |
| tkamppeter | Robin_Watts, probably something is blocking here. Perhaps I should try from my hotel room and in the worst case next week when I am back home. Or should I send you an e-mail so that you can post. | 15:39.38 |
| kens | When we know the height, we don't have the stream easily available | 15:39.50 |
| Robin_Watts | tkamppeter: Send me an email, sure. | 15:39.51 |
| chrisl | Perhaps people should just get their PDFs right...... | 15:40.13 |
| kens | Well it is technically legal (dumb, biut.....) | 15:40.29 |
| tkamppeter | Now it has posted it but lost the description, I will add the description as a second iteration (comment) now. | 15:40.54 |
| chrisl | I didn't think it was baseline JPEG, I guess it is..... | 15:40.55 |
| kens | actually we do have the stream available in image_file_continue | 15:41.20 |
| chrisl | Do we have a "proper" way to know it's DCTD? | 15:41.48 |
| kens | I htink not, ecause it could be a pipeline (ascii85 then DCT for instance) | 15:42.12 |
| chrisl | True, yes | 15:42.21 |
| kens | So we would have to walk the pipeline looking to see if any of the filters was DCT | 15:42.35 |
| tkamppeter | Description is there, sorry, loaded very slowly. | 15:42.52 |
| Robin_Watts | Could we shoehorn the Height into the dictionary passed to zDCTD? | 15:44.20 |
| kens | chrisl iin this case there is at least a SubFileDecode before we get to the DCT | 15:44.26 |
| | Robin_Watts : I don't think so no | 15:44.36 |
| Robin_Watts | didn't sound like a nice idea :) | 15:44.51 |
| kens | We create the DCT filter *before* we make that dictioanry then add that (using a SubFileDcode filter) to the dictionary we pass to image as the /DataSource entry | 15:45.09 |
| chrisl | Oh, yuck, struct gs_image_enum_s is defined in gsimage.c..... | 15:47.14 |
| kens | Of course..... | 15:47.25 |
| marcosw | bbiaw | 15:47.31 |
| kens | And then probably defined elsewhere too when someone needed it | 15:47.41 |
| chrisl | It's typedef'ed to gs_image_enum in gsimage.h | 15:48.06 |
| kens | It may be possible to deal with this in image setup | 15:48.09 |
| | by looking at the data source and walking the pipeline looking for DCT filters | 15:48.26 |
| | Its a bit hideous though | 15:48.47 |
| chrisl | Could we parse the image dictionary a bit earlier? | 15:50.00 |
| kens | image_setup seems like hte earliest possible place, unless you mean in the PDF interpreter ? | 15:50.35 |
| Robin_Watts | Could we extend the image sources with a new entry point? | 15:50.49 |
| | suggest_height or something ? | 15:51.01 |
| chrisl | Yeh, in the pdf interpreter - so have the dict when we create the filter(s) | 15:51.19 |
| kens | I'm not sure how that would help | 15:51.24 |
| Robin_Watts | stuff like ascii85 would pass it on. | 15:51.26 |
| kens | chrisl I'll look at the PDF interpreter | 15:51.34 |
| Robin_Watts | then we could call that from image_filter_continue | 15:52.21 |
| kens | That sounds like you are talking about the streams, not the images | 15:52.47 |
| Robin_Watts | I meant stream, sorry. | 15:52.57 |
| kens | and teh streams can be used on objects which are not images | 15:53.00 |
| chrisl | I think we have the dimensions when we create the filter chain..... | 15:53.08 |
| Robin_Watts | right, so for those they wouldn't implement it. | 15:53.18 |
| kens | I'm reluctant to add image-specific stuff to the streams | 15:53.19 |
| Robin_Watts | some streams need to handle predictions based on width etc, right? | 15:53.42 |
| | oh, that's probably in the dictionary it's passed at setup time. | 15:54.01 |
| kens | Indeed | 15:54.05 |
| | The stream creation deals with that | 15:54.12 |
| | let me look at what Chris is proposing | 15:54.22 |
| Robin_Watts | ok. | 15:54.27 |
| chrisl | kens: in pdf_draw.ps /makeimagekeys | 15:54.52 |
| kens | Its possible we could add a new entry to the DCT dictioanry | 15:54.57 |
| | chrisl that looks plausible | 15:55.26 |
| chrisl | The slight problem is that the filter setup is "hidden" in /resolvestream | 15:55.33 |
| kens | Hmmm | 15:55.39 |
| | There's special code for JPX though, so we can probably do 'something' ther | 15:56.02 |
| chrisl | Yeh, it means checking the array for DCT and doing 'something'..... | 15:56.34 |
| tkamppeter | Robin_Watts, I finally succeeded with Firefox instead of Chrome: http://bugs.ghostscript.com/show_bug.cgi?id=695264 | 15:56.44 |
| kens | I was thinking we could add a unique jey to the dictionary which contains the Height | 15:56.54 |
| Robin_Watts | tkamppeter: Thanks. | 15:57.06 |
| kens | s/jey/key | 15:57.07 |
| chrisl | kens: the stream dict?# | 15:57.21 |
| kens | Well, the dictionary we use to create the stream decoder | 15:57.35 |
| Robin_Watts | tkamppeter: Could you add the tiff command line too please? | 15:57.41 |
| chrisl | kens: yeh, in which case, I wouldn't bother doing anything specific to DCT, just stick the value in there, and use it in resolvestream if we hit a DCT decode | 15:58.27 |
| kens | Essentially what I was thinking, yes | 15:58.41 |
| | Then the DCT setup code can use the dict parameter | 15:58.56 |
| | If its present | 15:59.02 |
| chrisl | utters famous last words: "Yep, I reckon that should work...." | 16:00.45 |
| kens | Its the usual baling twine, but I think I can make it happen | 16:01.08 |
| | Robin_Watts : I'll look at it tomorrow if that's OK, I need to go and start dinner | 16:01.34 |
| Robin_Watts | kens: no worries. thanks! | 16:01.42 |
| chrisl | kens: the only other thing I can think of is inline images...... | 16:01.58 |
| kens | I'll get it as far as the stream decoder, and then you can add the magic there. THat way you won't have to look at PostScript or the horrors of the PDF interpreter | 16:02.09 |
| | chrisl an inline JPEG ? I suppose its possible...... | 16:02.24 |
| chrisl | IIRC, it is legal, yes | 16:02.42 |
| kens | But presumably we still need to set up a decoder, so the same trick should be possible | 16:02.48 |
| chrisl | Yeh, I just meant it might get called from somewhere else | 16:03.05 |
| kens | I can probably manufacture one to play with and see. | 16:03.20 |
| chrisl | Or just ignore it, and hope it never happens! | 16:03.34 |
| kens | I'd rather deal with it now.... | 16:03.44 |
| | I *think* it all goes through resolvestream anyway, but its wise ot be sure | 16:03.57 |
| | Have to go, goodnight all | 16:04.09 |
| chrisl | g'nite kens | 16:04.19 |
| henrys | Robin_Watts, paulgardiner did you see brad's email? | 19:30.36 |
| | marcosw_: maverick upgrade has been surprisingly uneventful | 19:36.33 |
| marcosw_ | henrys: that's good news; I've usually had good luck with Mac OS X upgrades, at least for the last 3 or 4 verisons. | 19:37.54 |
| | Forward 1 day (to 2014/05/28)>>> | |
IRC Logs