| | <<<Back 1 day (to 2012/05/10) | 2012/05/11 |
| Chalu | Can ghostscript convert html to ps? | 06:07.35 |
| saper | I don't think so | 06:09.44 |
| | but most of the browsers can | 06:09.55 |
| cryptopsy | where is the pdf file format described? | 09:03.16 |
| kens | In the PDF Reference Manual and the ISO 32000 document | 09:03.33 |
| cryptopsy | tnx | 09:04.12 |
| Robin_Watts | Does anyone have the PDF-X4 or PDF-X5 standards (ISO 15930-7 and 15930-8) ? | 09:28.34 |
| kens | Nope... | 09:28.43 |
| chrisl | Robin_Watts: do we need the X4 and/or X5 specs, given that they're both PDF subsets, and we're looking at consuming, not producing PDF-VT? | 09:51.20 |
| Robin_Watts | chrisl: Possibly not, but the PDF/VT spec says that they "are indispensible for the application of this document". | 09:52.32 |
| kens | Possibly for constructing a PDF/VT file | 09:52.54 |
| | But not for consumption I would have thought | 09:53.09 |
| Robin_Watts | Quite possibly. Was just asking. And now I need to reboot my machine for Windows Update. Going to fit a firewire card while it's down, so I'll be back in a bit. | 09:53.45 |
| | So, why does my Firewire card have "Highspeed USB certfied" logos on it? | 10:07.37 |
| kens | Its a USB as well ? | 10:07.47 |
| Robin_Watts | nope. | 10:07.55 |
| kens | Its a bug :-) | 10:08.14 |
| chrisl | I'd guess it "pretends" to be a USB card so it doesn't need extra drivers? | 10:17.22 |
| saper | Robin_Watts: do you know what kind of FWOHCI chip is there? It might be some chip that has USB EHCI as well onboard | 10:20.49 |
| Robin_Watts | saper: I don't have a clue. It's a cheap dynamode card with a VIA chip. | 10:23.57 |
| chrisl | kens: ping | 10:46.45 |
| kens | pong | 10:46.51 |
| tor8 | Robin_Watts: take a look at tor/master see if you barf on my splitting the pdf_open_document [_no_run] function to avoid linking in resources in the mubusy tool | 10:46.59 |
| chrisl | kens: Have you got a second? | 10:47.06 |
| kens | Yes, good timing, I was just looking at outlines :-( | 10:47.18 |
| chrisl | Ugh! Could you open zfapi.c and look at the code around line 2453, please? | 10:47.53 |
| kens | Oh, continuation :-( | 10:48.28 |
| | Well it 'sort of' looks OK | 10:49.15 |
| chrisl | I'm trying to fathom why that code is there | 10:49.37 |
| kens | It seems to be returning to PostScript in order to run the BuildChar | 10:50.05 |
| | Presumably its a PostScript type 3 ? | 10:50.15 |
| | Oh, no, its a type 42 | 10:50.32 |
| chrisl | FAPI doesn't handle type 3 fonts | 10:50.36 |
| kens | Could we have added a BuildChar to the font somewhere else ? That sounds vaguely familiar | 10:51.13 |
| | Something to do with the opernd being a name not an integer | 10:51.29 |
| chrisl | I didn't you were allowed to replace a BuildChar after a font is defined | 10:52.35 |
| kens | I'm not sure its 'after' the font is defined. It may be part of our code for handling TrueType fonts directly. | 10:53.04 |
| | Is this an actual problem somewhere ? | 10:53.20 |
| chrisl | Well, we can't get to FAPI_do_char() without the font being defined | 10:53.34 |
| | It hasn't caused a problem, no, but obviously it uses the PS interpreter specific stuff, and I'm trying to eliminate as much of that as possible | 10:54.14 |
| kens | Yes but what I mean is that converting a TT to a type 42 (perhaps as a replacement font) may add a BuildChar to convert the glyph name into a glyph index. I'm not certain about that mind you | 10:54.18 |
| | chrisl I don't think that will actually ever get exercised by a non-PS interpreter | 10:54.37 |
| | If I'm right about the conditions | 10:54.50 |
| | And relying on my memory is not a good idea.... | 10:55.01 |
| chrisl | sorry, doorbell..... | 10:55.52 |
| kens | NP | 10:55.58 |
| chrisl | Yeh, I'm just trying to fathom whether I need to keep that stuff, and move it into the interp specific code, or I can just drop it - it doesn't seem to get called running on the cluster | 10:56.35 |
| kens | If I'm right about it being for TT fonts from disk, then it won't :-) | 10:57.03 |
| | I suspect it should be in the PS/PDF interpreter-specific code. Probably PS-specific really to be precise. | 10:57.59 |
| chrisl | But this is in the Type42 section, not the TTF section - and if we do put a BuildChar in the dictionary, it will have been replace by FAPIBuildChar, or we'd never get to this bit of code! | 10:58.43 |
| kens | Well its possible the code is dead of course. | 10:59.07 |
| chrisl | In my branch, I've commented it out, and that case returns an invalidfont - I'll leave it that way for now, and see what happens | 11:00.04 |
| kens | Seems reasonable, I hope you added a comment so you'll know what to do if anyone complains :_) | 11:00.32 |
| chrisl | Yes, I have. To be honest, all that glyph decoding stuff has to be interpreter specific anyway, I'd just prefer if it didn't have to return the o_push_estack value through the graphics library | 11:02.15 |
| aleray | what does "Can't set GraphicsAlphaBits > 1 with a vector device pswrite" | 11:35.18 |
| | mean? | 11:35.21 |
| | hum. I have this eps file I coded by hand. I get an error with ghostscript: http://dpaste.com/746540/ | 11:40.22 |
| | do yo have any clue? | 11:40.27 |
| | ok it had to do with GraphicsAlphaBits=4 I remove it | 11:49.21 |
| kens | pswrite is a vector dvice, you can't set GraphicsAlphaBits or TextAlphaBits with it. | 11:59.36 |
| aleray | kens, thanks | 12:00.02 |
| kens | It is also a deprecated device, don't use it. Instead use ps2write | 12:00.11 |
| aleray | kens, I have troubles opening my hand coded eps files on osx tiger (well I'm on linux but asked a friend too). Could you have a look at the file and tell me if there is anything wrong wit hit? | 12:01.02 |
| | http://git.constantvzw.org/?p=osp.work.cosic.rescue.git;a=blob;f=cards/back.eps;h=ed62c053896b3187460486e0eed84946ce0f5914;hb=HEAD | 12:01.33 |
| Robin_Watts | tor8: ping | 12:01.46 |
| | Looks like lots of code duplication there. | 12:01.53 |
| kens | aleray : what problem do you get ? errors ? | 12:02.07 |
| Robin_Watts | Can't we have pdf_open_document call pdf_open_document_no_run ? | 12:02.15 |
| kens | aleray an EPS file should not execute showpage | 12:03.29 |
| | Though that's not catastrophic usually | 12:03.42 |
| tor8 | Robin_Watts: yeah, I was thinking we might be able to do something to reduce the code duplication | 12:04.45 |
| aleray | kens, good to know. Do yo see anything else wrong? | 12:04.52 |
| | kens, osx tiger document viewer just says it can't convert it to pdf | 12:05.18 |
| kens | aleray : no, not really, but it would help to know what problems you are getting. | 12:05.18 |
| Robin_Watts | pdf_open_document basically does the same as pdf_open_document_no_run but with another function (or two) overridden, right? | 12:05.26 |
| kens | Hmm. | 12:05.29 |
| | aleray : have you tried it with Ghostscript ? | 12:05.40 |
| Robin_Watts | Also, it could use fz_always. (but that may be a hangover from the original code) | 12:06.03 |
| | brb | 12:06.14 |
| aleray | kens, yes. no problem to view the file | 12:06.20 |
| tor8 | fz_always is true enough. old code :) | 12:07.17 |
| kens | aleray : then it seems like its a OS/X bug really. | 12:07.42 |
| tor8 | yeah, but the function weave a nasty web of calling other functions to initialise stuff. | 12:07.49 |
| aleray | eps2pdf works fine too | 12:08.06 |
| | here on linux | 12:08.12 |
| chrisl | aleray: One thing that springs to mind is that alendar% is an optional device, the interpreter on OS/X might not have it | 12:08.39 |
| kens | and the GS pdfwrite device happily converts it to PDF as well | 12:08.46 |
| | AH, missed that. | 12:09.04 |
| | Yes, it may well not exist | 12:09.10 |
| | You should check for device existence before using it | 12:09.53 |
| aleray | chrisl, so it might be caused by the calendar device ? any alternative code to circumvent this? | 12:10.11 |
| kens | It looks like you are using it for a random seed, just use realtime | 12:10.32 |
| | It'll be good enough | 12:10.41 |
| chrisl | The alternative would be don't use %Calendar%% | 12:10.59 |
| kens | There is no guaranteed way to get date/time from a PostScript device | 12:11.07 |
| | Because if there were you would have to have a real time clock on all PostScript printers. | 12:11.31 |
| aleray | kens, chrisl thanks a lot. I didn't write this part of the file. Could you help me rewrite it with realtime ? | 12:13.29 |
| chrisl | aleray: something like: http://pastebin.com/SHZd8rST would probably work..... | 12:14.06 |
| kens | Yes, looks reasonable tro me | 12:14.32 |
| aleray | cool, although I don't really get the code | 12:16.25 |
| kens | If the device is there it works as before, if not then it starts with 0 | 12:16.41 |
| | THen it gets realtime, and adds the numbers, and uses the result as the random number generator seed. | 12:16.59 |
| | stopped executes the code in a 'stopped' context | 12:17.21 |
| | It doesn't provoke an error, it just reigisters it | 12:17.34 |
| | Sort of like throw/catch | 12:17.43 |
| aleray | nice | 12:17.57 |
| | BTW I was wondering if there was any tools/methodology to debug in postscript/eps... I found it very hard when I coded this file to spot the errors, and see the stack for instance | 12:18.51 |
| kens | Its hard to debug PostScript | 12:19.04 |
| Robin_Watts | chrisl: I've just had a random idea. You may hate it... | 12:19.04 |
| kens | == and pstack are your friends | 12:19.13 |
| chrisl | Robin_Watts: I am braced....... | 12:19.22 |
| | aleray: basically, you have to "instrument" the Postscript | 12:20.00 |
| Robin_Watts | On git.ghostscript.com, if you click on the snapshot link you get a tgz of the snapshot, right? | 12:20.01 |
| chrisl | Robin_Watts: yep | 12:20.09 |
| Robin_Watts | Suppose I add a new link to the right of that, that goes to a password protected area of our site, that says "commercial snapshot" | 12:20.22 |
| aleray | chrisl, thanks | 12:20.50 |
| Robin_Watts | When you click on that you get a page of dire warnings saying that this snapshot is automatically generated and untested etc, along with a download link. | 12:21.00 |
| tor8 | Robin_Watts: refetch tor/master, is that better? | 12:21.12 |
| chrisl | Robin_Watts: I'd need to revise the release script as we discussed at the staff meeting to have a "batch" mode | 12:21.28 |
| Robin_Watts | The download link would be populated by a version of the source that has been through the script (indeed, yes). | 12:21.45 |
| | Can we keep that script in the gs git tree? | 12:21.58 |
| chrisl | At some point, yes, it's just at the moment, it's tailored to my machine. | 12:22.26 |
| Robin_Watts | and can part of that script be git locations/hashes for the other libraries we need to pull in? | 12:22.28 |
| chrisl | We don't pull in other libraries from git | 12:23.09 |
| Robin_Watts | Or SVN revision. | 12:23.21 |
| | i.e. if everything like that is contained within the ghostscript git, then a commercial release becomes an automated,repeatable event. | 12:23.28 |
| | And you can tag the gs source for releases again. | 12:23.40 |
| chrisl | I do tag the gs source for releases | 12:23.59 |
| Robin_Watts | Ah, just not on master, right, sorry. | 12:24.09 |
| chrisl | And the changes in the tag aren't related to the commercial release | 12:24.27 |
| | the commercial release script just uses the head revision in svn for the luratech libs | 12:24.56 |
| Robin_Watts | ok, never mind. | 12:25.06 |
| | but I do like the idea of integrating it with git. | 12:25.17 |
| chrisl | I'll put aside some time next week to sort out the script, and get it into git. | 12:25.33 |
| Robin_Watts | because then customers can grab snapshots of the commercial release easily. | 12:25.44 |
| chrisl | True, but customers rarely want a snapshot, they invariably want their patch(es) applied to a previous release | 12:26.37 |
| kens | Because that's much safer than taking a tested snapshot :-) | 12:27.00 |
| Robin_Watts | customers want "something that works". | 12:27.11 |
| | Until now previous release + patch has been the easiest route (but as ken says, it's untested) | 12:27.41 |
| kens | Robin_Watts : no serioulsy, chrisl is correct | 12:27.56 |
| | THat is indeed what customers want | 12:28.03 |
| Robin_Watts | Ah well. | 12:28.16 |
| chrisl | But it's often not the previous release - it's often two or three releases old | 12:28.17 |
| Robin_Watts | tor8: looking now. | 12:28.39 |
| chrisl | Robin_Watts: I'm not saying it's not a reasonable idea - it might help us re-educate at least come customers that generally do keep up to date. It might be worth getting an opinion from marcosw about it | 12:30.10 |
| Robin_Watts | tor8: So you've made pdf_new_document public | 12:30.31 |
| | Why can't pdf_open_document just call pdf_open_document_no_run and then override the run_page ? | 12:30.59 |
| | overriding the run_page can't fail. | 12:31.09 |
| | Do we want a pdf_open_document_no_run_with_stream? If so, then pdf_init_document can be kept private too. | 12:33.12 |
| tor8 | they're all in mupdf-internal | 12:34.42 |
| | they have to be non-static for the linker to find them across compilation units | 12:34.56 |
| Robin_Watts | They don't have to be exposed across compilation units :) | 12:35.13 |
| | pdf_open_document(blah) { doc = pdf_open_document_no_run(blah); doc.super->thingy = secret; return doc; } | 12:36.00 |
| | same for pdf_open_document_with_stream (calling pdf_open_document_no_run_with stream). No need for pdf_init_document or pdf_new_document to be made public. | 12:36.54 |
| tor8 | init_document must be public (it's in pdf_xref.c) | 12:37.46 |
| Robin_Watts | why is it new to mupdf-internal.h this time then ? | 12:38.45 |
| | oh, because you split pdf_document1 out from pdf_xref.c ? | 12:38.58 |
| | Can we put it back? Do we gain anything from having that separate? | 12:39.10 |
| tor8 | Robin_Watts: yes. refetch tor/master. | 12:39.31 |
| Robin_Watts | and that way we can call pdf_document2.c pdf_document_run.c which is a nicer name | 12:39.46 |
| tor8 | we could put document1.c back | 12:39.47 |
| | put the contents of document1.c back into xref.c I mean | 12:40.04 |
| Robin_Watts | yes. | 12:40.11 |
| tor8 | and rename pdf_document2.c into pdf_xref_voodoo.c ;) | 12:40.29 |
| Robin_Watts | pdf_new_document should be static? | 12:41.01 |
| | pdf_document_run.c? | 12:41.11 |
| tor8 | sorry, fetch again. committed without having saved :( | 12:41.31 |
| Robin_Watts | or pdf_xref_voodoo, yes, I see that logic. | 12:41.36 |
| tor8 | I don't mind splitting the fz_document interface out of pdf_xref, but it does add to the number of files. | 12:42.26 |
| Robin_Watts | I like splitting files if there is a good reason. I dislike exposing internal interfaces unless there is a good reason. | 12:42.56 |
| tor8 | pdf_xref.c is already too big for my taste, but pdf_document.c was a bit small. | 12:43.00 |
| | yeah, I hear you. | 12:43.16 |
| | so let's merge and rename to voodoo (or do you have a better suggestion? pdf_xref_aux.c maybe?) | 12:43.47 |
| Robin_Watts | aux is fine. | 12:43.55 |
| | voodoo implies 'magic we don't understand' to me :) | 12:44.11 |
| | pdf_xref_run ? Cos it provides the 'run' functionality ? | 12:44.37 |
| tor8 | well, it doesn't implement the run functionality, it just hooks it in | 12:45.02 |
| | so it's a bit misleading when you're looking for the right file to edit | 12:45.16 |
| | I think I'll go with aux | 12:45.20 |
| Robin_Watts | Yeah. There should be a comment at the top of the file saying "This has been split out of pdf_xref.c to allow tools to be linked without pulling in unnecessary code" | 12:45.42 |
| | (or something along those lines, but better :) ) | 12:45.59 |
| | I have code in pdfclean to reorder the objects in a file according to the requirements of linearisation - but it's screwing encryption again, and I can't see why. | 12:50.09 |
| tor8 | Robin_Watts: okay, updated (hopefully final) version on tor/master | 12:53.57 |
| Robin_Watts | I like that. | 12:56.28 |
| tor8 | Robin_Watts: multiple iterations helps code quality quite a bit :) | 12:58.20 |
| Robin_Watts | lunchtime. | 12:58.20 |
| | Code reviews work :) | 12:58.44 |
| aleray | chrisl, kens thanks a lot for you advices | 13:13.44 |
| kens | NP | 13:13.51 |
| Robin_Watts | tor8: KS has relatives that play minecraft right? http://www.tomshardware.com/news/Minecraft-Calculator-Graphing-MaxSGB-Scientific,15109.html | 13:42.34 |
| tor8 | Robin_Watts: I sincerely hope the people making all these projects use scripting tools or something, because laying out those things manually.... eep! | 13:59.48 |
| Robin_Watts | Aha, generation numbers are screwed. | 14:02.48 |
| | tor8: Yeah. Or at least a really powerful copy/paste :) | 14:05.34 |
| | tor8, sebras: ping | 15:06.46 |
| | When writing linearised PDF we have to write out a linearisation params dictionary as the first thing in the file. | 15:11.58 |
| | Some of the entries in that need to know offsets of things that haven't been written yet. | 15:12.29 |
| | I was thinking we could write them out as 0000000000 and come back and replace them with the real values later? | 15:12.56 |
| | but that's not trivial to do with the existing object printing code. | 15:19.05 |
| | so I was pondering adding a new pdf_obj type that would mean "int, but prints really big when output". What do you think? | 15:19.44 |
| | kens: How does pdfwrite cope with that? | 15:20.34 |
| | Likewise, we have to put a hint stream into the middle of the document. The hint stream contains offsets to objects throughout the document (some before it, and some after it). | 15:21.45 |
| | The spec is slightly cunning in that the offsets after the hint stream are given as if the hint stream wasn't included (so we can write the document out once without the hint stream, then create the hint stream, then copy the document, inserting the hint stream, and just 'fixup' the final trailer. | 15:23.14 |
| | <fx: tumbleweeds roll past> | 15:23.41 |
| kens | busy sorry | 15:25.37 |
| Robin_Watts | kens: np. I'm most interested in getting feedback from tor8 as to how offended he is by the idea before I go and code it... | 15:27.04 |
| | actually, I can just use INT_MIN, I think. | 15:47.21 |
| henrys | marcosw:we don't need a meeting today but I was hoping to update bugzilla with enhancements you gathered from Drupa. | 15:56.08 |
| Robin_Watts | tor8: We appear to have missed renaming fz_new_name to pdf_new_name | 16:02.59 |
| tor8 | Robin_Watts: yuck, backpatching? I can understand why you lost your appetite reading the linearized pdf spec. | 16:10.54 |
| Robin_Watts | tor8: Yeah, it's foul. | 16:11.14 |
| tor8 | are you proposing a new pdf_obj type, pdf_placeholder_int (or something like it)? | 16:11.45 |
| Robin_Watts | That is one option. | 16:12.02 |
| tor8 | or you just set it to 999999999 | 16:12.22 |
| | and backpatch later anyway | 16:12.28 |
| Robin_Watts | The other option is that I just put INT_MIN in there to start with, then when we go back and rewrite, use the proper value. | 16:12.39 |
| | That option requires us to pad the dictionary with whitespage though. | 16:13.02 |
| | or whitespace. | 16:13.10 |
| tor8 | I think I'd prefer '9999999' (of however many digits you need) and then pad with spaces when printing the real value | 16:13.33 |
| | writing a temp file then copying things around seems a bit awkward | 16:14.17 |
| Robin_Watts | I'd have to pad the object with spaces, rather than the individual entries, I think. | 16:14.20 |
| tor8 | I don't understand. | 16:14.45 |
| Robin_Watts | I have to output: something like: | 16:14.59 |
| | 45 0 obj << /L 999999999 /O 9999999 ... >> endobj | 16:15.21 |
| | then a bit later come back and rewrite as: | 16:15.35 |
| | 45 0 obj << /L 1234 /O 34 ... >> endobj | 16:15.52 |
| | I don't really want to get into changing the object output routines (unless we go the placeholder route) | 16:16.19 |
| | so the spaces would have to be added after endobj rather than after 1234 | 16:16.36 |
| tor8 | oh, you were going to rewrite the whole dictionary. of course. | 16:18.09 |
| | hm, just print with 999999 and record the file position at the end of the dictionary | 16:18.25 |
| | then pad after the dictionary with spaces when you re-print it | 16:18.45 |
| Robin_Watts | That's the plan, yeah. | 16:19.33 |
| tor8 | ugh. the linearization parameter dictionary contains the file length. that's just... ick! | 16:20.44 |
| | what brain dead monkey thought this spec up? | 16:20.53 |
| Robin_Watts | So my plan is to write the file once, with placeholders and an empty hint stream. | 16:22.11 |
| | then make the real hint stream, and write the file again with real values/padding and the hint stream. | 16:22.36 |
| tor8 | I really hope we never have to actually parse linearized pdf files based on the spec! | 16:24.13 |
| | what was that bit about offsets and hint streams? | 16:25.29 |
| Robin_Watts | The hint stream contains the offsets of each page start (and other things) within it. | 16:25.49 |
| kens | Night all | 16:26.07 |
| tor8 | oh, so the hint stream offsets are minus the hint stream? | 16:26.20 |
| Robin_Watts | So if the length of the hint stream changes, you'd expect everything after the hint stream to move, and hence the hint stream would be invalid. | 16:26.29 |
| | So any offset > the start of the hint stream is stored with the hint stream length subtracted from it. | 16:27.02 |
| tor8 | right. makes sense. the only way you could do this braindead scheme and not run into an instable system. | 16:27.21 |
| Robin_Watts | yes. | 16:27.28 |
| | I'm disappointed that I still have to do the dictionary padding trick, but... | 16:28.29 |
| rayjj__ | somehow I missed a line when re-applying part of the reverted patch (to gsicc_profilecache.c). Code still worked, but still had the problem (referenced freed memory) :-( | 17:13.05 |
| | fixed now | 17:13.12 |
| | that problem had existed for a long time. I'm surprised that it never showed up with someone running -Z@ | 17:14.14 |
| | to write a linearized PDF, can you open several temp file streams, then write the "final" PDF once you have the whole thing (leaving construction of the initial xref and hints until then) reading in the temp files as needed. | 17:17.36 |
| | this is mostly what GS pdfwrite does -- it has several temp files for stuff that then get assembled into the resulting PDF at the 'close' | 17:18.35 |
| Robin_Watts | rayjj__: Could do. But doing it using just 1 file, but in 2 passes seems reasonable. | 17:19.33 |
| rayjj__ | that's how it manages to do 'ps2write' since that requires careful ordering of Resources and other stuff | 17:19.47 |
| | the GS ps2write is basically the 'streamable' PDF that gets processed by a canned ProcSet that interprets it | 17:20.47 |
| | Robin_Watts: but padding all 'forward' object numbers, etc. to 10 digits seems rather wasteful (doesn't apply to xref since that is always 10 digit offsets) | 17:22.38 |
| Robin_Watts | rayjj_: It's for 2 dictionaries in the entire document. I think we can live :) | 17:23.07 |
| | with maybe 10 entries in each. | 17:23.18 |
| rayjj__ | Robin_Watts: you also have to 'fill in' the xref's for each page, right ? | 17:24.00 |
| Robin_Watts | I have to output 2 xrefs. | 17:24.11 |
| | not 1 xref per page. | 17:24.41 |
| | first xref = page1, second xref =rest of the pages. | 17:25.01 |
| | It's the hint streams that are going to be a bitch. | 17:25.11 |
| | gs doesn't have nearly the problem with the hint streams that I will. | 17:25.45 |
| | (no thumbnails in gs, no outlines, no article threads, no named destinations, no interactive forms, etc etc) | 17:26.18 |
| | actually the first xref is going to be a pain too. | 17:29.13 |
| mvrhel | Robin_Watts: question for you | 17:37.34 |
| Robin_Watts | mvrhel: please god, distract me :) | 17:37.46 |
| mvrhel | so on 692870 | 17:38.01 |
| Robin_Watts | Right. | 17:38.33 |
| mvrhel | what needs to happen in the pdf14 stroking code to ensure we dont do the stroke the slow way | 17:38.55 |
| | I try to follow this stuff but it is a bit confusing | 17:39.09 |
| Robin_Watts | The stroking code tests for lop_is_idempotent | 17:39.15 |
| | (IIRC) | 17:39.21 |
| | basically, if you ensure that the alpha is set to 1, we should stroke the fast way. | 17:39.38 |
| mvrhel | oh so likely update_lop_for_pdf14 is the thing that is doing it | 17:40.49 |
| Robin_Watts | see: update_lop_for_pdf14 | 17:41.05 |
| | in gdevp14.c | 17:41.12 |
| | yes :) | 17:41.17 |
| mvrhel | :) | 17:41.20 |
| | ok. so let me see if I can wrap a zstroke with a knockout group | 17:41.44 |
| | in which case we should be able to set this for the faster case | 17:42.14 |
| Robin_Watts | a zstroke with a knockout group in the case where update_lop_for_pdf14 would set lop_pdf14. | 17:42.29 |
| mvrhel | so pis->log_op |= lop_pdf14 makes it the slow case, yes? | 17:43.24 |
| Robin_Watts | yes. | 17:44.21 |
| mvrhel | ok thanks! | 17:44.31 |
| Robin_Watts | lop_is_idempotent returns true when lop_pdf14 is set. | 17:44.44 |
| mvrhel | huh? that sounds backwards | 17:45.39 |
| Robin_Watts | returns false, sorry! | 17:45.49 |
| mvrhel | ok. I am already confused enough... | 17:46.00 |
| | now I have enough knowledge to jump in and break something | 17:46.38 |
| | Robin_Watts: it ripped through the file with that change | 18:27.08 |
| | I need to do a cluster push to see what effect this has if any | 18:27.45 |
| | I am thinking that we would not need to set the lop_pdf14 bit any more with the knockout group present | 18:28.30 |
| Robin_Watts | Quite probable. | 18:34.18 |
| mvrhel | we will see what comes back from the cluster push. I went ahead and disabled update_lop_for_pdf14 | 18:36.01 |
| | lunch time now | 18:36.47 |
| Robin_Watts | Well, presumably with the knockout group in place, the final condition will always equate to false anyway ? | 18:39.13 |
| mvrhel | no. the blend mode was not normal | 18:39.43 |
| | but that is a good point | 18:39.55 |
| | anyway. I am about done for the day actually. I have been fighting a head cold/sore throat since getting back and now I have a fever | 18:40.24 |
| Robin_Watts | With the knockout group in place, does the internal rendering still see a non-standard blending mode? | 18:44.21 |
| | If it does, then presumably we still have to use the slow code? | 18:44.40 |
| | (Or was the test wrong before?) | 18:44.49 |
| | I hope you feel better soon. | 18:44.55 |
| | Have a good weekend. | 18:44.58 |
| marcosw | henrys: will enter enhancements after I go through my emails. Just returned home from physical therapy. | 19:16.53 |
| tor8 | Robin_Watts: the first xref shouldn't be difficult, as it's fixed size :) | 19:24.55 |
| | it'll need to be filled out proper in the second pass though | 19:25.08 |
| Robin_Watts | tor8: It's not fixed size. | 19:59.34 |
| | It has an offset to the final one. | 19:59.43 |
| | but I have all that done. | 19:59.47 |
| | In theory everything except the hint stream should be done in the code I have here (but something isn't quite right) | 20:00.22 |
| | but I'm done for the night I think. | 20:00.32 |
| | Forward 1 day (to 2012/05/12)>>> | |
IRC Logs