| | <<<Back 1 day (to 2012/08/28) | 2012/08/29 |
| svilayphiou | hi, I'm trying to merge pdf files and for some reasons some pages get reversed (turn 180 degress). thoses pages are the one where I used the mirror text frame option in scribus. that's very strange. Do you know anything about it? | 00:57.38 |
| Robin_Watts | svilayphiou: It's the wrong time of night to get an answer here. Your best bet is to open a bug on bugs.ghostscript.com and attach an example file there with the command line you are using. | 01:04.39 |
| | And our expert (kens) will probably look in a few hours time. | 01:05.12 |
| svilayphiou | Robin_Watts, thanks. I finally managed to get it work | 01:05.18 |
| | http://stackoverflow.com/questions/5943843/ghostscript-merge-of-pdfs-is-causing-orientation-to-flip | 01:05.21 |
| | Robin_Watts, do you think I should open a bug report still? | 01:05.36 |
| | I guess the software I used did specify wrong page orientation... if it is the case then it is more likely a bug there (?) | 01:06.22 |
| alexcher | svilayphiou: Try -dAutoRotatePages=/None | 01:08.22 |
| svilayphiou | alexcher, yep thanks. I followed the recipie on stackoverflow and it did solve the problem | 01:09.02 |
| | now it is time to sleep... 3am here :P | 01:09.17 |
| | thanks both of you | 01:09.23 |
| Guest97548 | hi guys! | 07:42.29 |
| kens | Good morning | 07:43.07 |
| Guest97548 | is anyone getting something like "Error: /undefined in pdf_check_password"? im getting this trying to open some pdf files in gs 9.06 | 07:43.13 |
| kens | No. | 07:43.21 |
| Guest97548 | these files seems to require pssword on some viewers | 07:43.40 |
| | on some these just throws error | 07:43.46 |
| kens | Encrypted files will need a password | 07:43.50 |
| Guest97548 | but in reader X it works without password! | 07:44.00 |
| kens | If you want to read tehm with Ghostscritp you will need to supply the password | 07:44.08 |
| Guest97548 | but there is none :( | 07:44.22 |
| kens | Guest97548 : there isn't a lto we can say without seeing the files | 07:44.28 |
| | Guest97548 : There may be no user password, doesn't mean the file has no password | 07:44.45 |
| | PDF files can have 2 | 07:44.54 |
| Guest97548 | i see, i think i can send it to you | 07:45.01 |
| | hang on | 07:45.03 |
| | should i send it to your email? or how? | 07:45.31 |
| kens | A public location is best, or you can open a bug report in our Bugzilla and attach it there | 07:45.52 |
| Guest97548 | can you reach this URL? https://e-book.fwf.ac.at/detail_object/o:60/ | 07:47.01 |
| kens | Yes | 07:47.22 |
| | I don't see a PDF there though | 07:47.42 |
| | I do se an ImageMagick error :-) | 07:47.53 |
| Guest97548 | ok here :) https://fedora.e-book.fwf.ac.at/fedora/get/o:60/bdef:Content/download | 07:48.05 |
| | that's actually the problem | 07:48.11 |
| kens | OK getting the file now | 07:48.19 |
| Guest97548 | image magic cannot create a thumb as the ghostscript fails to open it | 07:48.26 |
| kens | Yes its a secured file, using password security | 07:48.56 |
| | However, it has no User password | 07:49.05 |
| | It does have a creator password and is encrypted | 07:49.16 |
| | Let me look at teh docs a minute | 07:49.24 |
| Guest97548 | but you comes you can open it in X without anything? | 07:49.27 |
| | ok | 07:49.33 |
| kens | Because it has no User password you can open it | 07:49.38 |
| | The file is using a security handler which GS doesn't support | 07:51.11 |
| | (revision 6) | 07:51.22 |
| | I think that was recently added to the specification | 07:51.34 |
| Guest97548 | what does it mean for me? aha, so it will in the future? | 07:51.47 |
| kens | Just a minute | 07:52.52 |
| Guest97548 | sure | 07:53.02 |
| kens | OK well basically GS can't handle this kind oof security. I would suggest that yu open this ias a Ghostscritp bug, we obviously need to extend our support for this new kind of security handler | 07:55.43 |
| | The PDF interpreter maintainer is on teh East Coast of the US so he's not online right now | 07:56.10 |
| Guest97548 | ok, i will. thank you! | 07:56.26 |
| kens | No problem, thanks for brining it to our attention! | 07:56.38 |
| | For the logs and Alex, the Encrypt dictionary has a /V of 5, which is not documented in the PDF 1.7 reference. I'm assuming this is one of the 'supplements' which Adobe produced after turning the spec over to the ISO. I seem to remember Robin, tor & co discussing this for MuPDF. However, when I try to open the file using pdfdraw, I get a series of errors beginning 'encryption dictionary missing owner password'. | 08:02.18 |
| chrisl | kens: evince/poppler can't open the file either | 08:02.51 |
| kens | chrisl I can't find anything which can, except Acrobat X | 08:03.06 |
| | Acrobat 9 can't handle it. | 08:03.30 |
| chrisl | I guess we need to start paying attention to these supplements :-( | 08:03.36 |
| kens | It looks that way..... | 08:03.54 |
| sebras | kens: yes, this is actually described by the pdf 1.7 extensionlevel 8 specification which has not been released yet. | 08:54.47 |
| kens | Excellent, so Adobe products are writing PDF files to an unreleased specification :-( | 08:56.46 |
| | Why am I not surprised.... | 08:56.53 |
| sebras | kens: the encryption is based on AES256, SHA512 and a custom key stretching algorithm described on a webpage somewhere. | 08:57.04 |
| | kens: and starting with Acrobat X they produce encryption using this revision 6 format by default. | 08:57.39 |
| kens | Like I said, producing PDF files to an as yet unreleased specification, great plan | 08:58.04 |
| sebras | kens: I guess the intent on adobe's part is that this will become part of PDF 2.0 once ISO decides to release the spec, but it's not out yet (might be in draft form but ot publicly at least). | 08:58.20 |
| | well... everyone uses acroread.exe anyway, right? ;) | 08:58.44 |
| kens | sees another JPX fiasco looking.... | 08:58.44 |
| | s /looking/looming/ | 08:59.06 |
| sebras | was jpx held secret for a long time? I'm pretty ignorant about the history for jpx... | 08:59.14 |
| kens | Adobe released Acrobat against a draft of the spec, and one of the things changed between draft anmd release..... | 08:59.47 |
| sebras | aha, so releasing products against draft spec has worked well for adobe before. I see. | 09:02.14 |
| | well, no wonder they are trying again then... | 09:02.24 |
| kens | I guess its unlikely to be a problem this time, since its almost certain the ISO will ratify the Acrobat implementation | 09:02.42 |
| sebras | kens: http://esec-lab.sogeti.com/post/The-undocumented-password-validation-algorithm-of-Adobe-Reader-X | 09:02.44 |
| | kens: well, that doesn't prevent things from changing between now and the released spec on the other hand... | 09:03.11 |
| kens | No, but because its (in effect) Adobe's own spec this time, its not likely to be a problem. Last time it was the JOX spec which chagned, making Adobe's implementation the exact oppposite of what was in the spec.... It wasn't a huge problem, but.... | 09:04.07 |
| sebras | kens: a quote from that page seems interesting though "The previous implementation (single SHA-256 pass) is not available anymore in the latest version of Acrobat Pro X, so Adobe manifestly wants to get rid of it."... so I guess this means that they more or less replaced the old algorithm with this new one, which likely makes pdfs adhering to revision 6 encryption more common. | 09:05.14 |
| kens | Well it looks like all teh Adobe apps are producing files like this by default. Probably you can change it to an earlier version, but nobody ever bothers with that stuff. | 09:05.56 |
| | I wish this would bite Adobe in some way :-( | 09:06.11 |
| sebras | kens: whoa.. that pdf is messing up mupdf quite a bit: *** stack smashing detected *** | 09:24.42 |
| kens | Really ? It wouldn't open for me at all | 09:24.59 |
| | Complained about the security | 09:25.05 |
| sebras | kens: mupdf just crashes for me. | 09:25.21 |
| kens | I was using pdfdraw | 09:25.32 |
| | Didn't try MuPDF viewer appp | 09:25.40 |
| | Well, Acrobat X doesn't like my linearised PDF file, not even now I'm writing a hint stream.... | 09:26.41 |
| | I guess I'll start looking into that later. | 09:26.52 |
| | Off to ride a horse, bye all | 09:27.21 |
| sebras | kens: it's mudraw that fails for me. | 09:29.47 |
| paulgardiner | Robin_Watts: ping | 09:44.31 |
| Robin_Watts | pong | 09:44.49 |
| paulgardiner | New commit on paulg/forms, plus I've merged master again, if you have a moment | 09:45.31 |
| Robin_Watts | ok. | 09:45.41 |
| | had I pushed all those? | 09:46.51 |
| | I think you've merged with robin/master rather than golden/master ? | 09:47.28 |
| paulgardiner | Aaghh! I have. | 09:47.46 |
| | I'll sort it out | 09:47.51 |
| Robin_Watts | But that commit (the doc object one) seems plausible. | 09:48.48 |
| paulgardiner | Looks like there are two in fact | 09:50.03 |
| | Forms: avoid javascrpt action... | 09:50.23 |
| Robin_Watts | contstructor | 09:51.26 |
| | Is that a teacher you don't like? :) | 09:51.37 |
| paulgardiner | :-) Very nearly | 09:52.04 |
| Robin_Watts | ok, that looks good too. | 09:56.39 |
| paulgardiner | Great. ta | 09:56.47 |
| | I've redone the merge, but I better cluster test. I'll let you know when it finishes | 10:00.53 |
| | Robin_Watts: tests came back ok | 10:45.27 |
| kens | sebras (much delayed) I'm running mudraw from a reasonably fresh set of source on Windows, I'll look at the errors again | 12:09.01 |
| kens | realises he was using pdfdraw, not mudraw | 12:10.02 |
| Robin_Watts | paulgardiner: Pushed. | 12:11.13 |
| paulgardiner | Brill. Ta | 12:11.19 |
| dzx9_ru | Hello. | 12:20.57 |
| | I'm trying to build MuPDF for Windows. | 12:20.57 |
| | I'm using Visual Studio 2008. | 12:20.57 |
| | I created a new project and try to do it with the source MuPDF. | 12:20.57 |
| | I ran into several problems. | 12:20.57 |
| | The file "pdfapp.c" compiler error: | 12:20.57 |
| | fatal error C1853: 'Debug \ PdfReader.pch' precompiled header file is from a previous version of the compiler, or the precompiled header is C + + and you are using it from C (or vice versa) | 12:20.58 |
| | I renamed the file to "pdfapp.cpp", the problem disappeared. | 12:20.58 |
| | After this, the compiler gives strange error. | 12:20.59 |
| | For the string: | 12:20.59 |
| | static void pdfapp_showpage (pdfapp_t * app, int loadpage, int drawpage, int repaint); | 12:21.00 |
| | Error: | 12:21.00 |
| | error C2065: 'pdfapp_t': undeclared identifier c | 12:21.01 |
| | error C2065: 'app': undeclared identifier c | 12:21.01 |
| | error C2062: type 'int' unexpected | 12:21.02 |
| | Can anybody help me? | 12:21.02 |
| tor8 | dzx9_ru: 1) why don't you use the existing visual studio project? 2) it's C not C++, compiling as C++ is not very likely to work | 12:24.14 |
| sebras | kens: it changed name a while ago. :) | 12:28.35 |
| kens | sebras, yeah but i'm well behind the times | 12:31.56 |
| sebras | kens: though now we get som stack smashing. I'll look into it tonight. | 12:33.15 |
| dzx9_ru | 1) I'm trying to figure out how MuPDF interacts with the window. | 12:33.43 |
| | Look at the code from the site, I did not understand how MuPDF interacts with the window. | 12:33.43 |
| | To which item MuPDF displays page and how he knows that I have made click. | 12:33.43 |
| | 2)Is there a set in Visual Studio to compile in C? | 12:33.43 |
| Robin_Watts | dzx9_ru: Start Visual Studio. File => Open win32/mupdf.sln. Then Build solution. | 12:37.39 |
| dzx9_ru | Thank you, now try | 12:39.49 |
| chrisl | Robin_Watts, tor8: I noticed in one of his e-mail's Raed "Mudraw --> to rasterize Pdf by generating a bitmap" - but, IIRC, at least originally, they were only licensed to use mupdf for getting information about the file, not for rendered output. | 12:57.40 |
| tor8 | chrisl: hmm. I remember that being the case from early on, but I'm not sure what the current agreement is. better ping miles about it. | 13:02.06 |
| | chrisl: http://git.ghostscript.com/?p=user/tor/ghostpdl.git;a=summary the last four commits there are one way to bring the jbig2dec gits in sync | 13:02.49 |
| | but maybe we want to have the last one (the intermediate autohell files) in jbig2dec.git as well, or we should fix the gs build system. how does that work with libtiff for instance? I've noticed it reruns all of autoconf stuff for libtiff separately. | 13:03.49 |
| chrisl | tor8: we don't run autoconf, automake, autoheader etc for libtiff, we only run configure | 13:05.01 |
| tor8 | right. so, how come we need to run all of those for jbig2dec? I think it's a bit overkill. | 13:05.43 |
| | maybe we (ahem, I mean "you") could strip those down a bit. or ask sebras, he also knows autohell these days. | 13:06.24 |
| chrisl | Yeh, I have thought about that - we need to reduce it to just use autoconf - the problem is, the behaviour of (at least) autoheader doesn't follow the the "style" of the rest of autohell, *and* the output doesn't match the documentation, at least as I read it :-( | 13:07.56 |
| | Plus, it uses libtoolize, which I suspect we'd get complaints if we remove that | 13:08.39 |
| tor8 | chrisl: considering we can build it for mupdf without running the configure at all, I can't see it really matter | 13:08.40 |
| | then again, mupdf doesn't build it as a shared library | 13:08.57 |
| chrisl | Where do you get config.h and config_types.h? | 13:09.24 |
| tor8 | -DHAVE_STDINT_H | 13:09.47 |
| | all the config.h includes are guarded with HAVE_CONFIG_H in the jbig2dec source | 13:10.36 |
| chrisl | What the hell is the point of that?!?!? What a pile of crap :-( | 13:11.24 |
| tor8 | and all the config.h does is set up the int types | 13:11.34 |
| | all pointless crap we should zap, IMO | 13:11.43 |
| chrisl | config.h has a *lot* more than that in it | 13:12.21 |
| tor8 | oh, and vsnprintf for MSVC, but that's an easy ifdef in jbig2.h | 13:12.23 |
| | chrisl: none of which is used in the source | 13:12.55 |
| chrisl | Oh, what a waste of time and space | 13:13.27 |
| tor8 | indeed. shall we get rid of it? :) | 13:13.54 |
| | the one and only config flag is HAVE_LIBPNG which we could just as well zap from all but the command line tool | 13:14.29 |
| sebras | tor8: I'd rather not speak about that... | 13:15.06 |
| chrisl | Well, it means either rewriting the jbig2dec build almost completely and risking the wrath of the package maintainers, or handling in the Ghostscript build, and risking the two getting out of sync | 13:15.09 |
| dzx9_ru | I'm having an error linking. | 13:15.17 |
| | In the project properties (Project -> Properties -> C / C + + -> General -> Additional Include Directories) I put in the line. Just like in the master project: | 13:15.17 |
| | ".. \ fitz; .. \ pdf; .. \ xps; .. \ cbz" | 13:15.17 |
| | Add to project two files | 13:15.17 |
| | pdfapp.c | 13:15.17 |
| | pdfapp.h | 13:15.17 |
| | As in the master project from the site. | 13:15.17 |
| | Now the functions and variables from the file "pdfapp.h" and "pdfapp.c" can differentiate amongst the file "fitz.h" | 13:15.18 |
| | But the functions and variables in the file "fitz.h" do not see the files inside the directory "fitz", such as "base_context.c". | 13:15.18 |
| | And the compiler gives me the errors: | 13:15.19 |
| | error LNK2019: unresolved external symbol _fz_new_context referenced in function _WinMain @ 16 win_main.obj | 13:15.19 |
| | error LNK2019: unresolved external symbol _fz_invert_pixmap_rect referenced in function _pdfapp_invert pdfapp.ob | 13:15.20 |
| | ........ | 13:15.20 |
| | What am I doing wrong? | 13:15.21 |
| chrisl | tor8: I think I'd like to try to handle it all in the Ghostscript build, and let the jbig2dec build stuff rot | 13:16.38 |
| vtorri | chrisl, i can help with autotools | 13:23.10 |
| | i maintain a dozens in our project | 13:23.21 |
| chrisl | vtorri: we want to remove most of the autotools dependencies in jbig2dec | 13:23.36 |
| vtorri | ok | 13:23.40 |
| chrisl | My preference is to have Ghostscript's build do all the settings needed when we build jbig2dec inside Ghostscript, and basically ignore the jbig2dec stuff | 13:24.50 |
| paulgardiner | Confused! Seems to be a typo in pdf_to_num, but it would break loads of things, so I can't see how it can have been like that for long. Maybe I just don't understand. | 13:29.08 |
| sebras | paulgardiner: where's the typo? | 13:30.00 |
| paulgardiner | function pdf_to_num in pdf_object.c | 13:30.35 |
| sebras | yes, but where? | 13:31.01 |
| paulgardiner | I'd have thought it should have RESOLVE(obj) and then a test for PDF_INT, not PDF_INDIRECT | 13:31.13 |
| | It copies pdf_to_gen's form rather than pdf_to_dict's | 13:32.05 |
| | I'd better check it's the same on master. | 13:32.27 |
| sebras | paulgardiner: it is. :) | 13:32.32 |
| | paulgardiner: I checked paul/forms ;) | 13:32.43 |
| | so the idea is that pdf_to_num/pdf_to_gen retrieve the object number and generation number for an indirect reference. | 13:33.08 |
| | if you RESOLVE an object you load the object proper and ignore the fact that you're dealing with an indirect reference. | 13:33.43 |
| | but in this case we _want_ to read out things from the reference itself, we don't care about the object it points to. | 13:34.13 |
| | paulgardiner: does that make sense? | 13:34.19 |
| paulgardiner | I have a number object with value 6. I'm running pdf_to_num on it and get back 0 because it's type is PDF_INT. | 13:35.46 |
| sebras | paulgardiner: yes, that makes sense, because you have a number object, and not a indirect reference. | 13:36.22 |
| | ah, you're thinking about pdf_to_int(). :) | 13:36.48 |
| paulgardiner | Ah, so am I using the wrong call to turn an object into an int | 13:36.49 |
| sebras | yes. :) | 13:37.12 |
| paulgardiner | Oh right. I've been blissfully unaware of the distinction. Oops! | 13:37.33 |
| sebras | that might explain a segfault or two. ;) | 13:37.49 |
| paulgardiner | Oh, oh, oh. Stupid. Yeah gen and num. Im just suffering a brain fart | 13:38.35 |
| | What am I thinking! :-) | 13:38.48 |
| sebras | I'm not sure, but it would be wonderous world if function calls just automagically did what one wants. | 13:40.29 |
| chrisl | tor8: if we make config_types.h a "non-autotools file", I think we can cover all the jbig2dec build requirements with the Ghostscript configure script | 13:40.45 |
| paulgardiner | sebras: Well at least I don't seem to have made that confusion before today. Every other call to pdf_to_num in pdf_forms.c is involved with opening a stream. | 13:43.44 |
| chrisl | tor8: I just removed the section in Ghostscript's configure that runs the jbig2dec configure, pulled in jbig2dec.git (with no derived files) and GS still built just fine, with jbig2dec | 14:30.14 |
| tor8 | chrisl: so all we need to verify is that it still builds on win32? | 14:49.06 |
| Robin_Watts | aargh. lcms2 bites me again. | 14:52.00 |
| | cmsChangeBuffersFormat is a pain. | 14:52.21 |
| chrisl | tor8: I think the windows build totally ignores all the autohell derived files. I *think* we need to have a way to tell jbig2dec the endianness of the build, and it would be good to handle the non-HAVE_STDINT_H case | 14:53.35 |
| tor8 | os_types.h has a bunch of ifdef spaghetti that should cover all non-configure cases well enough | 14:55.11 |
| | chrisl: but I wonder how jbig2.h will work, it uses uint32_t etc without including os_types.h | 14:57.06 |
| | oh, right, it's a mess. I remember now, you have to make sure they are defined to include jbig2.h itself | 14:59.24 |
| | since os_types.h is a "private" header that doesn't get installed | 14:59.36 |
| chrisl | I don't think we really have to worry about all that for teh GS bulid | 15:00.29 |
| ray_laptop | mvrhel: I noticed yesterday that you didn't know whether or not I had commited the fix for the crash that I had looked into for you. It was commit bb15658b. "Fix clist probelms with copy_planes, writer and reader out of sync." | 15:00.32 |
| tor8 | chrisl: nope, but it would be nice to have it in better shape just in general | 15:00.50 |
| | chrisl: if the jbig2dec.git without derived files works, we can do the git-subtree merge and then it'll be easier to move patches across later | 15:01.37 |
| chrisl | tor8: It's all a little horrible - a typical example of "let's do things the 'right' way" and ending up in a horrid mess afterwards :-( | 15:02.16 |
| | tor8: at the moment, the only restriction we'd have is that I think we'd *have* to have stdint.h available - for example, it won't handle inttypes.h instead | 15:03.54 |
| mvrhel | ray_laptop: yes. thanks. when I updated that previous segv was fixed | 15:05.33 |
| tor8 | chrisl: the ifdef spaghetti in os_types.h doesn't make sense either | 15:05.50 |
| | chrisl: any systems we care about that don't have stdint.h available (that are not win32) | 15:06.16 |
| mvrhel | Robin_Watts: did he change the ability to update the buffer format in 2.4? | 15:06.39 |
| Robin_Watts | mvrhel: He's added a clever mechanism whereby you can provide 'transform factories'. | 15:07.12 |
| | so people can add optimised transforms for the common cases without changing lcms2 itself. | 15:07.34 |
| | so when you first set up a link, the factories that have been registered are asked "can you cope with a transform from X to Y with these flags"? | 15:08.07 |
| chrisl | tor8: actually, the "ifdef spaghetti in os_types.h" seems to cover us for (most?) non-HAVE_STDINT_H cases | 15:08.15 |
| Robin_Watts | so I wrote optimised transforms for the ones we used. | 15:08.30 |
| mvrhel | ok | 15:08.38 |
| Robin_Watts | but then, if you call cmsChangeBuffersFormat, the transform factories aren't consulted. | 15:08.53 |
| | Which means you can't pickle in the pack/unpack routines (which is a shame, cos that can save a lot of time). | 15:09.14 |
| | and in his current code, he doesn't even provide pack/unpack routines for transform factories. | 15:10.11 |
| | So basically, transform factories can't be used with cmsChangeBuffersFormat. | 15:10.24 |
| ray_laptop | alexcher: I saw the SEGV bug. I'll look at it later today (sending a fix off to cust 532) | 15:10.29 |
| Robin_Watts | mvrhel: I'm constructing an email to him now about it, which is helping me sort out my thoughts into something more comprehensible. | 15:10.55 |
| ray_laptop | Robin_Watts: sounds like it would be useful to be able to 'touch the data only once' | 15:11.14 |
| | did I miss anything yesterday (other than the entire meeting) ? | 15:11.59 |
| Robin_Watts | ray_laptop: Currently the transform code is a loop of the form: unpack the data into a buffer, check if it's the same unpacked data as last time, in which case just use the previous result. if it's not the same data, do an optional gamut check. Transform the data. Pack the data back into the output. Rinse and repeat. | 15:12.55 |
| | unpack and pack are both function calls. | 15:13.08 |
| | which for something that might just be a load/store of a 16bit value is painful. | 15:13.29 |
| ray_laptop | Robin_Watts: sounds like it should be on a full buffer | 15:14.34 |
| Robin_Watts | ray_laptop: It's 1 sample value per call (so CMYK is 1 call for all 4 channels) | 15:15.22 |
| | Doing more would be potentially too memory ineffcient. | 15:16.03 |
| ray_laptop | I thought we used lcms(2) to transform full buffers (usually image raster lines). Internally it does the processing sample at a time ? | 15:16.36 |
| Robin_Watts | Yes. | 15:17.07 |
| | but it kinda has to. | 15:17.22 |
| ray_laptop | doing a function call for every sample seems like something a C++ programmer would do, but not in the guts of an engine | 15:17.59 |
| Robin_Watts | ray_laptop: Right. And that's what I'm trying to avoid with my optimisations, but I'm being frustrated by cmsChangeBuffersFormat. | 15:18.59 |
| ray_laptop | Robin_Watts: 'has to' in the current implementation, yes, but color transformation of buffers (IMHO) should be optimized | 15:19.02 |
| Robin_Watts | In the general case, it has to (cos we can't have all the possible cases coped with without it - there are simply too many formats). | 15:19.35 |
| ray_laptop | Robin_Watts: that's what I understood from your statement. | 15:19.43 |
| | Robin_Watts: I agree that using unpack/pack for less common formats is OK, but 8 and 16 bits per sample in and out ought to be optimized to avoid function calls and work efficiently | 15:21.15 |
| | so that's 4 'special cases' -- not to bad | 15:21.53 |
| Robin_Watts | ray_laptop: Right. Except even avoiding it for 8 or 16 bit cases explodes into many many cases. (coping with 1,3,4 channels in and 1,3,4 channels out, in 8 or 16 bits in or out is 3*3*2*2=36 cases) | 15:22.32 |
| | Then you've got cached or not, gamut or not, float or not... | 15:22.56 |
| | My approach to all this is to have a template header file that we can include repeatedly with different #defines and it generates the routines for us. | 15:23.38 |
| | So we can pick the ones we want to offer. | 15:23.49 |
| ray_laptop | Robin_Watts: float is not common. But I agree that 1,3,4 in and out are reasonable | 15:24.12 |
| | I really don't know if gamut is common or not | 15:24.42 |
| Robin_Watts | For our usage, float accounts for half of the calls. | 15:24.58 |
| | (in terms of transform setup, far less actual data goes through it, as it's being used for blackpoint magic) | 15:25.33 |
| | In terms of bulk data, I believe we are almost exclusively int. | 15:25.49 |
| ray_laptop | float ? PS and PDF don't even offer float data options, and gs certainly doesn't EVER use float colors | 15:25.58 |
| Robin_Watts | but we are not necessarily a typical user of lcms2. | 15:26.09 |
| | So any optimisations I do have to be done with an eye on them being configurable for other users, as Marti is unlikely to accept wholesale changes just to suit us. | 15:26.50 |
| mvrhel | bbiab | 15:27.05 |
| ray_laptop | well he can always get someone else to flesh out the other cases | 15:27.21 |
| chrisl | tor8: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=a4bc7215 | 15:27.41 |
| Robin_Watts | ray_laptop: My plan is that I fix it so that transform factories work properly with cmsChangeBuffersFormat. | 15:27.50 |
| | And I provide the templated header. | 15:28.00 |
| | I use the templated header to define our own transform factory that offers the ones that we need. | 15:28.17 |
| | and then other people can use the templated header with different options to make their own transform factories. | 15:28.35 |
| henrys | hmm I think created an account for customer190 on bugzilla but don't recall it asking me for a password I wonder if it is just open until he logs in. | 15:28.41 |
| tor8 | chrisl: cool! | 15:31.06 |
| chrisl | tor8: I want to try it on my various platforms here before I push it to the central repos..... | 15:31.31 |
| | It cluster tests fine, though | 15:31.42 |
| tor8 | chrisl: want me to do the git-subtree thing on top of that? I wonder if we can do it without having a separate 'remove gs/jbig2dec' commit first. maybe by faking ancestry in the commits using some filter-branch rewriting and grafts. | 15:32.09 |
| Robin_Watts | tor8: Except that would change all the historical gs SHAs right ? | 15:33.15 |
| tor8 | Robin_Watts: not if I only do it on the merge commit before I push it | 15:33.31 |
| | just as a way to work around the fact that "git-subtree add" doesn't like it if the directory already exists | 15:34.01 |
| | or I could put the magic keywords in manually in a commit message and hope that works too | 15:34.18 |
| Robin_Watts | tor8: Ah, I see. | 15:34.28 |
| chrisl | tor8: do we have to worry about that? I thought that was one of the reasons we wanted to two repositories totally in-sync before going ahead | 15:34.29 |
| Robin_Watts | Do the git remove as one commit. | 15:34.37 |
| | The git subtree as another. | 15:34.43 |
| | then git rebase -i HEAD~2 and squash the two ? | 15:34.53 |
| chrisl | That's what I did for just zapping the derived files | 15:35.10 |
| tor8 | chrisl: git-subtree looks at lines with some special keywords to figure out which commit of the external repo a merge comes from | 15:35.17 |
| | Robin_Watts: git rebase seems to skip 'merge' commits altogether :( | 15:35.40 |
| chrisl | So we can't "start from here", then? | 15:35.50 |
| tor8 | chrisl: that's what I think we can do with some hackery | 15:36.02 |
| chrisl | I'll test the windows build now, but the Solaris/SPARC, MacOS/PPC and Linux/PPC will have to wait until tomorrow | 15:36.59 |
| tor8 | chrisl, Robin_Watts: http://git.ghostscript.com/?p=user/tor/ghostpdl.git;a=commit;h=457063f6c93eadd6899bed86bb0cb37666f63494 | 15:37.03 |
| | that's the 'import an external git-subtree' commit with --squash | 15:37.28 |
| | the git-subtree-dir and git-subtree-split lines are the important ones | 15:37.50 |
| | the next commit that does the merge doesn't seem to have any magic keywords, so it could just be a matter of resetting the branch to before the import and merging it manually instead | 15:39.01 |
| ray_laptop | darn. A memory leak on a hideously complex file with transparency (cust 532 only). Leaking about 3 Mb on _some_ bands :-( | 15:40.51 |
| tor8 | chrisl: okay, I've hopefully got something that works on ghostpdl.git in tor/master | 15:52.47 |
| marcosw | henrys: I just tried logging in as customer190 and it said I needed to enter a password. | 15:53.09 |
| tor8 | chrisl: two files still differ -- .cvsignore (eh? why's that still there) and .gitignore | 15:53.55 |
| henrys | that's what I feared see abov. | 15:53.58 |
| | marcosw:can you just give him an account with the gs download password | 15:54.46 |
| | and he can change it. | 15:54.56 |
| chrisl | tor8: presumably because "cp" ignores hidden files | 15:55.19 |
| marcosw | henrys: I can do that. | 15:55.22 |
| | henrys: actually I'll use the customer company name as the password. | 15:55.50 |
| chrisl | tor8: are there any implications that you know about in having more than one .gitignore file in a repository? | 15:56.51 |
| tor8 | chrisl: if I understand git-subtree correctly, doing a git-subtree merge from upstream (jbig2dec.git) will rebase the new patches onto the "Squashed 'gs/jbig2dec' content from commit 3a424b8" commit, and then do another merge onto master | 15:56.56 |
| | chrisl: I think it reads them in deepest .gitignore priority, so a .gitignore is a subdir is read first then following parent dirs up to the top | 15:58.29 |
| chrisl | OKay, so that should be fine, and .cvsignore can be ditched, of course | 15:59.01 |
| tor8 | yeah. I'll try ditching the .cvsignore as a test for how merging and pulling between repos works | 15:59.26 |
| chrisl | henrys: did we really opt out of luratech support last year? | 15:59.57 |
| henrys | chrisl:miles did yes, actually I reported something a while back and discovered Miles stopped and I thought I passed it along but maybe not. | 16:01.20 |
| chrisl | Hmm, perhaps not ideal, given that we also decided to make it the default for paying customers.... | 16:02.12 |
| henrys | chrisl:agreed and this problem may change that, they still fix something that is broken. | 16:02.56 |
| | I have mixed feelings about it, it is a small fraction of functionality | 16:03.38 |
| chrisl | TBH, I'm wondering if we should revisit the decision, now we have OpenJPEG in there | 16:04.35 |
| henrys | I'll put it on the agenda if you like. | 16:04.50 |
| | we don't have a support contract with them either ;-) | 16:05.14 |
| | actually it is going on the agenda - generally I think the luratech product is pretty solid, I'm a bit more confident with it. | 16:06.08 |
| chrisl | Well, what do you think? My feeling is there isn't the gulf in quality, performance, memory use etc between OpenJPEG and Luratech that there was with Jasper | 16:06.10 |
| tor8 | chrisl: don't use the stuff on tor/master yet, I still need to test this more | 16:06.22 |
| chrisl | tor8: I'm also still testing the build stuff on chrisl/master..... | 16:06.56 |
| henrys | and luratech will fix a bug if we find one, openjpeg not so sure. | 16:07.12 |
| tor8 | chrisl: it's not happy about splitting out jbig2dec history (it seems to start from the first ghostpdl commit instead of the merge) | 16:07.32 |
| | chrisl: okay, the --onto option of 'git-subtree split' seems to be doing the right thing | 16:09.24 |
| | anyway, gotta go. | 16:09.30 |
| chrisl | henrys: that's true - my concern was dropping the support contract at the same time as we significantly increased the coverage it gets..... I'm necessarily advocating removing Luratech for the commercial release, I just wondered if we should revisit based on the current situation | 16:10.49 |
| | s/I'm necessarily/I'm *not* necessarily | 16:12.08 |
| henrys | I'm talking to miles about it now. | 16:12.55 |
| mvrhel | Robin_Watts: Thanks for cc'ing me on the email to Marti | 16:43.28 |
| Robin_Watts | mvrhel: no problem. I should have copied you on the previous one. | 16:43.45 |
| | IF you see me say anything stupid, please say! | 16:44.01 |
| mvrhel | aha. found my GC issue | 17:18.25 |
| | Robin_Watts: I am guessing you did not dig into this | 17:18.38 |
| | Where the problem happens to be I see that I even have a comment that I had added that says "Possible GC issue?" | 17:19.04 |
| | One of those cases where I wrote something that did not feel right and forgot to get back to it | 17:19.50 |
| | at least I did write myself a note | 17:20.10 |
| Robin_Watts | mvrhel: Sorry, no. I've been stuck in lcms. | 17:26.46 |
| | What I'd hoped was a quick diversion has kept me occupied. | 17:27.07 |
| mvrhel | ok well please dont spend anytime on what I sent you | 17:27.38 |
| Robin_Watts | ok. | 17:27.45 |
| mvrhel | must have just barely gotten in front of you Robin_Watts | 17:54.38 |
| | mine will be done quick | 17:54.51 |
| Robin_Watts | no worries, I've been hogging it enough. | 17:54.53 |
| mvrhel | hopefully this fixes my segvs | 17:54.59 |
| | then I can actually do a commit sometime soon | 17:55.20 |
| | this halftone stuff has been taking forever | 17:55.41 |
| | crap still one more file | 18:01.06 |
| Robin_Watts | 1 fixed, 1 to go? | 18:01.17 |
| mvrhel | yes | 18:01.23 |
| Robin_Watts | could be worse :) | 18:01.34 |
| mvrhel | yes it could be | 18:01.39 |
| | let me see if it fails on windoze... | 18:02.49 |
| | and of course it does not | 18:04.43 |
| | aha with MaxBitmap set properly it does crash in windoze | 18:17.19 |
| | so that is good news | 18:17.23 |
| | not a segv but an error] | 18:18.01 |
| Robin_Watts | memento ? | 18:18.23 |
| mvrhel | no it is a clist error | 18:19.19 |
| | it appears | 18:19.25 |
| Robin_Watts | oh, right, I see. | 18:19.59 |
| | The clist error may be not be the first thing that's gone wrong though, and a memento build may cause it to SEGV earlier (i.e. closer to the real problem) ? | 18:21.00 |
| mvrhel | perhaps. I will give it a try | 18:22.03 |
| | running now | 18:23.42 |
| | same error situation... | 18:24.38 |
| | very weird | 18:25.09 |
| | since a path in the clist is the source of the error | 18:25.27 |
| | likely something else is mucking it up | 18:25.48 |
| Robin_Watts | ugh, sounds nasty. | 18:25.59 |
| mvrhel | need to step out for a bit. | 18:27.24 |
| ray_work | mvrhel: besides memento, make sure and run with -Z? (couldn't hurt and sometimes spots problems) | 18:54.33 |
| | mvrhel: call me later if you want me to help with it. | 18:55.25 |
| mvrhel_laptop | marcosw: you there? | 20:13.46 |
| marcosw | mvrhel_laptop: yup | 20:13.54 |
| mvrhel_laptop | I dont' see any issues when I run the file in Bug693300 | 20:14.09 |
| marcosw | open the file in adobe acrobat and select output preview | 20:15.43 |
| mvrhel_laptop | ah | 20:15.49 |
| marcosw | I probably should have mentioned that in the bug report :-) | 20:16.29 |
| mvrhel_laptop | ok | 20:16.41 |
| | now I see | 20:16.43 |
| | that is odd | 20:17.05 |
| | so it is some overprint issue | 20:17.21 |
| | the path is getting fillled with 2 different images. one that is in a separation space with OP true and the other as a regular RGB image | 20:19.25 |
| | weird | 20:19.34 |
| marcosw | I'm still surprised when we get problem files from this customer. I would have thought that we would have seen all possible combinations of spot colors, transparency, overprinting, etc. by now. | 20:20.27 |
| mvrhel_laptop | marcosw: yes me too | 20:28.40 |
| Robin_Watts | mvrhel_laptop: Urm... I'm confused. | 20:35.01 |
| | I've tweaked lcms2 so I can get a dump of all the different color transformations we use, and their frequencies. | 20:35.26 |
| | And most of the input/output formats make sense. | 20:35.49 |
| | but I've got a format of 0x4000a here. | 20:36.02 |
| | Which is supposed to be RGB, 2 bytes per channel, 1 channel. | 20:36.21 |
| | eh? | 20:36.25 |
| | 0x4001a is much more common, which is the saner, RGB 2 bytes per channel, 3 channels. | 20:37.28 |
| mvrhel_laptop | Robin_Watts: is an indexed color space sneaking in somehow? | 20:37.55 |
| Robin_Watts | I wonder... | 20:38.20 |
| | I'm going to assume that's the answer, thanks. | 20:38.30 |
| | ooh, an answer from marti. | 20:39.27 |
| mvrhel_laptop | bbiab | 20:52.12 |
| mvrhel | back | 21:32.45 |
| | so I am suspecting that my clist issue is yet another problem with copy_planes | 21:33.15 |
| | ray_laptop: I may drag you into this one | 21:33.31 |
| | but I will try to see if I can narrow it down first | 21:33.41 |
| | I guess with the threshold stuff there are just so many copy_plane commands going into the clist we are hitting issues | 21:34.22 |
| | that is, the odds are more likely | 21:35.23 |
| | Forward 1 day (to 2012/08/30)>>> | |
IRC Logs