| | <<<Back 1 day (to 2013/06/23) | 2013/06/24 |
| Robin_Watts | And just to make Monday more interesting... the hot water in the house has gone wrong. | 07:54.19 |
| tor8 | "wrong"? | 08:04.41 |
| Robin_Watts | no pressure. We get hot water from the taps, just very slowly. And it's useless for showering. | 08:05.03 |
| tor8 | that could be a bit annoying! | 08:05.45 |
| kens | Odd, isn't your water fed by gravity ? | 08:12.09 |
| kens | wonders if Robin's gravity isn't working properly | 08:12.26 |
| chrisl | If it's a combi-boiler, it'll rely on the water pressure from the main | 08:17.35 |
| Robin_Watts | It's not a combi boiler. | 08:47.10 |
| | Supposedly what I am seeing is typically caused by a duff valve, or a blocked pipe. | 08:47.35 |
| | The boiler man cometh later. | 08:48.08 |
| chrisl | Probably lime scale....... | 08:48.50 |
| Robin_Watts | tor8: So, we really need to fix the Makefile for MuPDF to get the cluster working again. | 10:06.07 |
| | Are you happy for me to try? | 10:06.12 |
| tor8 | Robin_Watts: what needs to be fixed? | 10:08.35 |
| | I thought you said running "make V8_PRESENT=no" was sufficient, but it's been a couple of days so my memory is hazy | 10:09.03 |
| | or did you want an explicit "make nosj" target? | 10:11.32 |
| Robin_Watts | tor8: OK, but that requires me to change the cluster code. | 10:11.38 |
| | I'd rather have an all-nojs target. | 10:11.45 |
| | Of course, that all-nojs target could boil down to make V8_PRESENT=no | 10:12.03 |
| tor8 | right. easy fix for all-nojs is to recursively call make with V8_PRESENT=no | 10:12.08 |
| Robin_Watts | fab. | 10:12.16 |
| tor8 | the other option is to split the INSTALL_LIBS and _APPS variables | 10:12.35 |
| | Robin_Watts: fix on tor/master | 10:16.43 |
| Robin_Watts | I don't see the need for that personally, but it's up to you. | 10:16.48 |
| | tor8: looks good to me. | 10:17.08 |
| tor8 | yeah, the $(MAKE) V8_PRESENT=no is reasonable enough for me | 10:17.30 |
| | the same approach would work for most other similar "optional, auto detected presence" features should we want them | 10:18.01 |
| | Robin_Watts: should we take on the patch on zeniko/fixes? | 10:19.39 |
| Robin_Watts | tor8: haven't looked. | 10:20.20 |
| tor8 | rebased and fixed version on tor/master | 10:21.54 |
| | not sure if any of them have been fixed elsewhere since he wrote the patch | 10:22.57 |
| | it's all in your and paul's xref/repair code | 10:23.08 |
| Robin_Watts | tor8: Oh gawd, it'll probably conflict with the progressive stuff. | 10:23.55 |
| | I did take on some of zenikos fixes in the area... | 10:24.03 |
| | tor8: Why the change from else if to if in the first block? | 10:41.57 |
| | num can't be <= 0 and > MAX_OBJECT_NUMBER at the same time (for sane values of MAX_OBJECT_NUMBER) | 10:42.21 |
| tor8 | no idea | 10:42.33 |
| Robin_Watts | ok. Otherwise that commit looks fine. | 10:43.42 |
| | I'll take it on, but put back the else if. | 10:43.57 |
| | In fact, I'm going to collapse the two halves of that if together. | 10:44.25 |
| | I had this advertised to me at the weekend: http://www.ebuyer.com/507394-dell-3330dn-mono-duplex-network-printer-210-29941?utm_source=b2c_weekend&utm_medium=email&utm_campaign=b2c_weekend | 10:49.59 |
| | "Free" mono duplexing laser printer (after cashback and tradein) | 10:50.20 |
| | tradein being (according to ebuyer) any working printer. | 10:50.43 |
| | The DELL site seemed to imply it had to be a one of a specified set of printers, so I'd make enquiries before going ahead. | 10:51.21 |
| | Oh ,wait I see. It *is* any printer as a tradein. | 10:54.13 |
| | tor8: I'm going to look at paulgardiners 4 commits, OK ? | 11:01.18 |
| tor8 | okay. | 11:06.28 |
| | the first two are good, but I haven't looked at the big ones yet | 11:08.07 |
| Robin_Watts | The first two do indeed look good. | 11:08.19 |
| | the next one has a problem in that if it fails building a linked list (malloc failure) then it fails to clean it up. | 11:08.43 |
| | other that that it looks OK. | 11:09.23 |
| | tor8: coo. New apartment. Congrats. | 11:18.30 |
| | Found a better pizza place to live over? | 11:18.38 |
| tor8 | Robin_Watts: that's the sad part :( | 11:22.08 |
| | but it's a lot more central, and bigger! | 11:22.13 |
| chrisl | Better broadband? | 11:22.44 |
| tor8 | chrisl: should be about the same, I don't expect any major differences there | 11:23.20 |
| Robin_Watts | is going to take a punt on that printer. Supposedly it does PCL 53/6 and PS3. | 11:23.27 |
| tor8 | more options though | 11:23.28 |
| Robin_Watts | s/53/5e | 11:23.39 |
| chrisl | tor8: more options is good - hope it all goes smoothly | 11:23.58 |
| | Robin_Watts: what's the toner cost like? | 11:24.17 |
| tor8 | where I live now I'm stuck with one provider... and they've been dodgy sometimes | 11:24.38 |
| Robin_Watts | supposedly "cheap to run" according to a review site. It's intended as a workgroup printer. | 11:24.49 |
| tor8 | like when the internet went down for a week because the server crashed and the person who has the key to the basement where they kept the servers was on vacation >.< | 11:24.58 |
| Robin_Watts | The bad factors were "expensive to buy" and "small input tray". | 11:25.16 |
| | small input tray is not a problem for my use. | 11:25.30 |
| | and "free" doesn't seem to be "expensive to buy" to me. | 11:25.44 |
| tor8 | duplex is a feature to kill for! | 11:25.52 |
| chrisl | tor8: when my cable modem went down for an extended period it was because the local build had caught fire! | 11:25.55 |
| Robin_Watts | duplex and network. And free. And (for comedy value) comes with another free multifunction mono laser printer. | 11:26.28 |
| tor8 | having an android phone saved me that time, wifi hotspot over 3g isn't actually all that bad for day-to-day use | 11:26.38 |
| chrisl | when it happened to me I had ADSL from Global Graphics, too | 11:27.16 |
| Robin_Watts | 135 quid for a toner cart. For 14000 pages, 0.9p per page. | 11:28.46 |
| chrisl | Not too bad then | 11:28.59 |
| Robin_Watts | Current printer is more like 1.4p per page. | 11:29.35 |
| chrisl | It would be nice to know who actually made it | 11:30.31 |
| Robin_Watts | actually... it's too big for my office. I think I'm gonna pass on it. | 11:33.45 |
| | I'll probably kick myself later. | 11:34.07 |
| | tor8: In pauls review, he has a function pdf_get_incremental_xref_entry. | 11:38.48 |
| | That returns the xref_entry for a given number in the incremental xref section. | 11:39.09 |
| | Seems reasonable enough. | 11:39.16 |
| | he has another function that returns whether a given numbered entry will be in the incremental section or not. | 11:40.06 |
| | what should that be called ? | 11:40.12 |
| | Currently he has: pdf_xref_is_incremental_entry. | 11:40.41 |
| | I wonder if it ought to be pdf_is_incremental_xref_entry ? | 11:41.11 |
| tor8 | the word order seems rather haphazard :) | 11:41.34 |
| Robin_Watts | or pdf_xref_entry_is_incremental | 11:41.48 |
| tor8 | yes, pdf_is_incremental_xref_entry or pdf_xref_entry_is_incremental would sit better with our existing naming conventions | 11:42.28 |
| Robin_Watts | i am tempted to take his commits as is, then produce a followup commit with fixes in. How do you feel about that? | 11:42.55 |
| tor8 | I think having "is" first is more in line with what we've done before, but "entry is incemental" passes the "read it aloud" test better | 11:43.04 |
| Robin_Watts | I think I'd lean towards the former, personally. | 11:43.44 |
| | (with our current naming scheme). | 11:44.08 |
| | If we were doing modular naming pdf_<module>_operation then the latter would be better. | 11:44.44 |
| tor8 | Robin_Watts: yes, no argument from me there. | 11:45.13 |
| | I'm not convinced of the big picture approach with the incremental xref updates, having to manually ensure that new objects live in the right xref section strikes me as fragile | 11:45.33 |
| Robin_Watts | tor8: Well, presumably the idea is that all 'high level' modifications to the doc should do the "ensure_incremental" call. | 11:46.23 |
| tor8 | couldn't pdf_create_object, update_object, delete_object, etc do that automatically? | 11:46.37 |
| | possibly gated by a "modify in place / modify incrementally" flag in the xref/document | 11:47.11 |
| Robin_Watts | pdf_create_object calls pdf_get_new_xref_entry, which ensures that we are in the incremental area. | 11:49.20 |
| | Likewise pdf_update_object | 11:49.56 |
| | and pdf_delete_object | 11:50.15 |
| tor8 | right, and we need the ensure_incremental_xxx calls so we don't modify old objects in-place | 11:51.43 |
| Robin_Watts | tor8: I believe so. | 11:52.04 |
| tor8 | perhaps adding a "mutable" flag to pdf_obj and making them be immutable by default or some other copy-on-write scheme? | 11:52.13 |
| | if a pdf_obj is edited, make a clone of the original state and put that in the old xref and move the now-mutable pdf_obj pointer into an incremental section? | 11:53.03 |
| Robin_Watts | tor8: except not all pdf_obj's are in the xref. | 11:53.35 |
| | and when I modify a pdf_obj, I can't get back to the 'parent' obj. | 11:53.56 |
| tor8 | so each obj would need a parent pointer to be able to go all the way back up | 11:53.58 |
| Robin_Watts | and that would present problems; suppose I put the same pdf_obj into several dictionaries? | 11:54.43 |
| tor8 | reparenting would modify the 'mutable' flag of the new container | 11:55.48 |
| Robin_Watts | eh? Suppose I create a dictionary, D. I fill it with some keys and int values. | 11:56.32 |
| tor8 | the mutable/parent flag could just be a reference to the xref slot it lives in | 11:56.38 |
| Robin_Watts | I then put D into another dictionary E. | 11:56.59 |
| | and I put D into another dictionary F. | 11:57.08 |
| | where would D->parent point ? | 11:57.17 |
| tor8 | then E would be copied on write, and F would be copied on write, and D->parent would be irrelevant | 11:57.25 |
| | until the next time the pdf is saved, at which time existing objects would have to be frozen... | 11:57.51 |
| Robin_Watts | No, I don't see how that can work. | 11:58.05 |
| tor8 | the parent is only needed to figure out which xref slot to "clone" when doing copy-on-write | 11:58.21 |
| | okay, let's consider another approach. the parent one has problems. | 11:58.50 |
| Robin_Watts | the parent one is unworkable, I believe. so by all means let's consider another approach. | 11:59.13 |
| tor8 | each pdf_obj contains the original xref object number taken while parsing the object from disk | 11:59.36 |
| Robin_Watts | ok. | 12:00.20 |
| tor8 | modifying any pdf_obj with an object number would trigger a cloning operation. go back to the original root pdf_obj of that object number, make a deep copy and replace the xref->table[num].obj pointer with the copy. then recursively clear the object number flag beginning from the root pdf_obj. | 12:00.58 |
| | and insert the original root object in the incremental xref section | 12:01.36 |
| | there's still the issue that we can put the same instance of an object in multiple locations | 12:02.20 |
| | but that won't bite us until we have to freeze during saving | 12:02.33 |
| Robin_Watts | tor8: Would insert the *copied* root object in the incremental xref section. | 12:02.41 |
| tor8 | Robin_Watts: no, it'd make a copy of the original for safe keeping | 12:03.06 |
| Robin_Watts | tor8: The original object needs to stay where it was, unchanged. | 12:03.23 |
| tor8 | otherwise the user would be holding on to the wrong opointer | 12:03.25 |
| | of course, we could just do this with an immutable flag, forbid all modifications on immutable objects, and make a "clone-as-mutable" function | 12:04.02 |
| | that'd probably be better in the long run as then it's more clear what's edited and where | 12:04.16 |
| | but it does mean we need deep and shallow cloning functions to be called in the right places | 12:05.02 |
| | making all modifications go into the incremental xref automatically would be more convenient | 12:05.34 |
| Robin_Watts | I'm still struggling with this in my head. | 12:07.12 |
| tor8 | Robin_Watts: consider pdf_dict_puts(dict, key, val) ... if the dict is copied and the *copy* is put in the incremental section | 12:07.37 |
| | which one would be updated? | 12:07.46 |
| | and how would we notify the user that 'dict' needs to point to the new copy | 12:08.02 |
| Robin_Watts | ok. So the purpose of the deep copy is to leave us with an identical object which we can leave where it was. | 12:08.43 |
| tor8 | yes. | 12:09.14 |
| Robin_Watts | IF we do this, we should have a document (or context) flag to mean "all updates should be incrementalised" | 12:09.45 |
| tor8 | I'm not sure why we'd need to though, maybe it's enough to just move the root object to the incremental xref section | 12:09.59 |
| Robin_Watts | so that we can still load a document and mess with it, and store it without having to use incremental updates. | 12:10.05 |
| tor8 | and zero out the old xref sections cached pointer | 12:10.28 |
| Robin_Watts | tor8: Assuming that saving works by byte copying the old file, sure. | 12:10.50 |
| tor8 | Robin_Watts: actually, that shouldn't matter :) | 12:11.16 |
| Robin_Watts | tor8: Why not? | 12:11.30 |
| tor8 | if we rewrite a new file, xref section by xref section, we'd reload the original object from file from its original offset | 12:11.56 |
| Robin_Watts | Fair enough, but... | 12:12.25 |
| tor8 | so just detaching the modified object from the old xref entry's cache slot and putting it in the new incremental section's slot should suffice | 12:12.26 |
| Robin_Watts | If I come to save a file incrementally, I need to ensure that I get exactly the same set of bytes out for the existing sections as I did before. | 12:12.34 |
| | Otherwise digital signatures etc fail. | 12:12.46 |
| tor8 | Robin_Watts: yes, an incremental save would always copy the original bytes and append new data to it | 12:12.58 |
| Robin_Watts | and we can't guarantee that we read in/write out and get the same. | 12:13.05 |
| | OK, so the cost all this is a an extra pointer for every pdf_opj | 12:13.34 |
| | and a flag in the context. | 12:13.42 |
| tor8 | Robin_Watts: or an extra int (for the object number) | 12:13.51 |
| | or do you mean a pdf_xref_entry pointer? | 12:14.24 |
| Robin_Watts | We need to be able to find the parent xref entry. | 12:14.46 |
| | Whether that's done with a pointer, or an int, I don't care. | 12:15.08 |
| | is an int enough? | 12:15.26 |
| tor8 | a pointer to the root object wouldn't be enough | 12:15.26 |
| | but I think an int should suffice, depends on whether the 'incremental' xref section shadows it | 12:15.47 |
| | any objects in the incremental section would have 0 as their object number | 12:16.02 |
| Robin_Watts | An int is enough, only if it's enough for us to find "the most recent version of this object" | 12:16.09 |
| tor8 | a pdf_xref_entry is enough if all we want is to zero the cached entry->obj entry and then recursively zero the number (to flag the root object and children as having been moved to the incremental section) | 12:17.33 |
| | however, the pdf_xref_entry table can be realloced... | 12:17.49 |
| Robin_Watts | True. | 12:18.02 |
| | OK, int wins then. | 12:18.06 |
| tor8 | and I think we only care about latest object, at a given "xref level" anyway | 12:18.27 |
| Robin_Watts | say that last sentence again with different words. | 12:18.55 |
| tor8 | we only care about the most recent version of an object / xref slot | 12:19.28 |
| Robin_Watts | ok. | 12:19.44 |
| tor8 | and if we want older versions, we can "pop" xref sections off the stack | 12:19.56 |
| Robin_Watts | objects can go from 0...65535 right ? | 12:19.59 |
| tor8 | 0..2^31 I believe | 12:20.14 |
| | the "old" pre-compressed object stream xref format has 99999 as the generation number limit, which served double purpose for the linked list of "free" xref slots | 12:22.07 |
| | which is a feature I don't think anybody relies on anymore | 12:22.32 |
| Robin_Watts | "The maximum generation number is 65535" according to my PDF dead-tree book. | 12:23.56 |
| tor8 | oh right. I was just going by the number of digits in the generation field of the fixed length record format of the xref table | 12:24.29 |
| Robin_Watts | WThe xref table must contain one entry for each object number 0 to the maximum object number used in the file, even if one of more of the object numbers in this range do not occur in the file" | 12:25.04 |
| tor8 | which brings us to another question... generation numbers...? | 12:25.05 |
| Robin_Watts | generation number = which xref section you are in. | 12:25.24 |
| tor8 | not in any file I've ever seen :) | 12:25.40 |
| | I think the number of times I've run into non-zero generation numbers can be counted on one hand | 12:26.35 |
| Robin_Watts | To avoid pdf_obj's growing in size, we could use bitfields. | 12:26.37 |
| | refs can be 16 bits. | 12:26.43 |
| | kind/marked can become bitfields. | 12:26.51 |
| | then we can use an int for the object number. | 12:26.59 |
| | front door, brb. | 12:27.05 |
| tor8 | Robin_Watts: we probably could, but I suspect malloc overhead is going to make any savings irrelevant | 12:27.48 |
| kens | chrisl ping | 12:28.08 |
| chrisl | kens: pong | 12:34.16 |
| kens | chrisl I finished the filenameforall for NTFS, and it was a bit more involved than I'd hoped (mostly due to the UTF8/WCHAR stuff). I was about to embark on the OS/2 and DOS, but I'm now feeing wary of this, as I have no way to even compile the code, let alone test it | 12:35.11 |
| | I was thinking maybe we could leave these as they are and note it. Then if anyone complains we can ask them to write it :-) | 12:35.35 |
| | What do you think ? | 12:35.40 |
| chrisl | kens: sounds fine. I don't think it's even worth a bounty..... | 12:36.05 |
| kens | My feeling as well, both OS's are long obselete. | 12:36.20 |
| | I'll do some more testing and then push my brnch to Casper. | 12:36.40 |
| chrisl | Okay, sounds good | 12:36.55 |
| kens | It does look like the Linux code 'ought' to enumerate sub-directories, but it doesn't for me, so maybe I don't undertand the code. | 12:37.11 |
| | Or perhaps I don't understand the file pattern, it seems willing to cater for wildcards mid-pattern.... | 12:37.41 |
| chrisl | I haven't looked at it - I'm struggling with a bit of a headache today | 12:38.23 |
| kens | There's no hurry.... | 12:38.32 |
| | chrisl btw the file that James CLoos attached from Cairo still has a full page transparency group | 12:39.46 |
| chrisl | kens: Is it the page group, or is it still a stupid sub-group? | 12:40.24 |
| kens | The page is defined with a group[ | 12:40.35 |
| chrisl | Well, that's normal, isn't it? | 12:40.53 |
| kens | I thought not, I thought that defined the whole page as transparent | 12:41.06 |
| chrisl | Or is the page group supposed to be implicit? | 12:41.11 |
| kens | Beats me, I don't remember this stuff | 12:41.21 |
| | Well, looks like he's correct, any transparency in the PDF file and ps2write reverts to rendering the whole thing | 12:47.07 |
| chrisl | Does pdfwrite do the same? | 12:47.30 |
| kens | Not when its got a high compaitibilty level, checking low levels now | 12:47.49 |
| | It would seem that pdfwrite (CompatibiltyLevel=1.3) doesn't do that. | 12:48.43 |
| chrisl | Hmm, that's....... strange | 12:48.57 |
| kens | Ah, but it includes transparency in the PDF file which is clearly wrong | 12:49.01 |
| | So something is broken | 12:49.12 |
| chrisl | Oops! What about the PDF subset(s)? | 12:49.32 |
| kens | I got the switch wrong, case error | 12:49.46 |
| | Its exactly the same as ps2write, a full page image | 12:50.12 |
| | I'm not sure how optimisable this is, I'll have to talk to Michael | 12:50.55 |
| | away from keyboard briefly | 12:51.26 |
| chrisl | kens: pdf_main.ps line ~1860 - If the page has a Group, enclose contents in transparency group. (Adobe Tech Note 5407, sec 9.2) | 12:55.33 |
| Robin_Watts | tor8: sorry, heating engineer here. | 13:32.43 |
| | At the moment on a 32bit system pdf_obj_s is 7 4 byte words. | 13:33.22 |
| | I think we can add the int and reduce it to 6. | 13:34.02 |
| | by pushing 'd.sorted' into a bitfield. | 13:34.34 |
| | along with kind and marked. | 13:34.38 |
| | I wrote a malloc lib (using 2 splay trees), which meant that the minimum allocated block size was 28 bytes. | 13:34.58 |
| tor8 | Robin_Watts: go for it. | 13:35.35 |
| Robin_Watts | OK, so I reckon we can take the first 3 of Pauls commits with only needing a small fixup on the last one to do with correcting on a malloc failure. | 13:36.09 |
| | and we can discuss the 4th with him when he gets back. | 13:36.20 |
| tor8 | okay. | 13:37.15 |
| kens | chrisl so if the page has a group, the whole page is transparent ? | 13:42.40 |
| chrisl | kens: it seems so. But just removing that implicit group doesn't seem to help with that file, so...... | 13:43.31 |
| kens | wonders if its possible to have a trnasparent file which does not have a group at the page level | 13:43.37 |
| | chrisl when I removed teh group I got a blank page.... | 13:43.50 |
| Robin_Watts | joy. might need a new hot water cylinder. | 13:44.23 |
| kens | I know Michael is travelling today I'll try and remember to ask him abhout this tomorrow | 13:44.27 |
| Robin_Watts | diameter of hot water cylinder = 50cm | 13:44.35 |
| kens | Oh new cylinder, much expensive | 13:44.40 |
| chrisl | kens: I think that's best.... | 13:44.42 |
| Robin_Watts | width of loft hatch = 48cm. | 13:44.55 |
| kens | Robin_Watts : so how did you get it up there i the forst place ? Through the roof ? | 13:45.10 |
| Robin_Watts | kens: it was up there before we converted the garage. hence no loft hatch. | 13:45.29 |
| kens | Oh.... | 13:45.36 |
| Robin_Watts | I can get slimline dual cylinder replacements @ 475mm. | 13:45.56 |
| kens | ooh that's tight still | 13:46.06 |
| Robin_Watts | dual coil replacements, I mean. | 13:46.08 |
| chrisl | Robin_Watts: if there's wooden trim around the hatch, you might get away with just removing that | 13:46.12 |
| kens | I was thining that too | 13:46.20 |
| | lot of effort though | 13:46.27 |
| Robin_Watts | And interestingly, as I am a company, I can get a solar heating system fitted and get all the money back from the government. | 13:46.45 |
| kens | Solar water heating ? I wouldn't do that. | 13:47.03 |
| Robin_Watts | kens: I am dead keen on the idea. | 13:47.20 |
| | though I know you've had problems. | 13:47.26 |
| kens | We have it, its *way* more trouble than its worth, and you'll need a *much* bigger tank | 13:47.42 |
| Robin_Watts | kens: No mainline gas here, so we have to buy oil. It's expensive. | 13:47.43 |
| | kens: Right, but if I have to replace the tank anyway, and the government will pay for it... | 13:48.06 |
| kens | A major problem in this country is the variability between summer and winter sun. If you have enough tubes to make deent amounts of hot water in the winter, then it makes so much in the summer that you can't use it all | 13:48.34 |
| Robin_Watts | kens: And how is having too much hot water a problem? :) | 13:48.55 |
| kens | So either you throw hot water down the drain, or the circulating fluid gets over hot, and soldifies | 13:49.10 |
| Robin_Watts | kens: That sounds... suboptimal. | 13:49.48 |
| kens | Which is expensive, smelly and difficult to do yourself, or explodes the tubes, which is expensive, and difficult top do yourself | 13:49.52 |
| Robin_Watts | What circulating fluid do you use? ethylene glycol ? | 13:50.16 |
| kens | Ideally you need a sunshade on the tubes | 13:50.18 |
| | Robin_Watts : I think tha'ts correct yes | 13:50.27 |
| | We have to watch ours, the fluid can reach well over 120 degrees | 13:50.47 |
| Robin_Watts | At what point does it start to solidify? | 13:51.06 |
| | Is it a water/glycol mix or something, and the water boils off ? | 13:51.32 |
| kens | Its progressive, it gets sludgy throughout its life as I understand it (volatiles biol off) but the hotter it gets the worse the problem is | 13:51.43 |
| Robin_Watts | kens: So would a 'service' once a year solve it ? | 13:52.02 |
| kens | The chap we use reccomends every 2 years I think | 13:52.20 |
| Robin_Watts | ok, I can easily live with that, I think. | 13:52.35 |
| kens | But that really means we should have a tank twice the size we do | 13:52.36 |
| Robin_Watts | kens: Know how big your tank is offhand ? | 13:52.53 |
| kens | 50 litres maybe ? I'm not certain | 13:53.04 |
| Robin_Watts | I can get slimline tanks in 180 or 210 litres. | 13:53.30 |
| kens | is not an expert.... | 13:53.44 |
| | I suspect there were a lot of cowboys around when this system was fitted. | 13:54.06 |
| Robin_Watts | yeah, I like to think the technology should be mature by now. | 13:54.22 |
| kens | would not count on that, I think there are *still* a lot of cowboys around. | 13:54.38 |
| | On the plus side, I think the worst ones went into PV | 13:54.51 |
| | Essentially its a plumbing problem with added complications | 13:55.04 |
| | And I hate plumbing | 13:55.12 |
| | oho ! | 13:55.54 |
| | mvrhel_laptop : are you really here ? | 13:56.01 |
| mvrhel_laptop | kens: yes for a bit | 13:56.11 |
| | off to airport in about 2 hours | 13:56.23 |
| kens | excellent. I need some help understanding transparency | 13:56.26 |
| | Yell if this is not a good time | 13:56.32 |
| mvrhel_laptop | no this is a good time | 13:56.38 |
| kens | OK so this is bug #694360 | 13:57.04 |
| | Using ps2write, the whole page gets rendered. | 13:57.16 |
| | The page has a transparency group, which (I think) is why this happens. | 13:57.30 |
| | Is it possible to have a transparent PDF file where the page does *not* have a transparency group ? | 13:57.51 |
| mvrhel_laptop | kens: I think so. You can specify an alpha value I thought in a graphic state. let me double check | 13:58.53 |
| kens | Presumably in that case you could also specify a SMask for an image XObject without having the page be in a transparency group ? | 13:59.33 |
| mvrhel_laptop | yes | 13:59.58 |
| | I think that is correct | 14:00.14 |
| kens | OK last question, do you have an example file constructed that way ? | 14:00.39 |
| kens | suspects that's the hard question | 14:00.52 |
| | I'd like to test the behaviour of ps2write with such a file | 14:01.10 |
| mvrhel_laptop | we may have one in the test suite that ray_laptop constructed long ago when we started tying the softmask in the graphic state like it should be | 14:01.26 |
| Robin_Watts | kens: It's trivial to make one. | 14:01.43 |
| mvrhel_laptop | kens: there you go | 14:01.54 |
| kens | Robin_Watts : if that's so, can you make me one please ? | 14:01.57 |
| Robin_Watts | Sure. | 14:02.03 |
| mvrhel_laptop | kens: see page 550 in the pdf spec | 14:02.44 |
| kens | mvrhel_laptop : I'll look now | 14:02.56 |
| mvrhel_laptop | the soft mask need not be tied to a grpu | 14:02.57 |
| | group | 14:03.01 |
| | but can just work on individual graphic obects | 14:03.11 |
| | same with the CA ca setting | 14:03.29 |
| kens | Right, then it should not be required fo Cairo to make the whole page transparent. I need to see what Poppler does with this file as well. Once I test ps2write I'll bott a VM and try that. Thanks! | 14:04.14 |
| mvrhel_laptop | kens: glad that I was of some help | 14:05.16 |
| Robin_Watts | http://ghostscript.com/~robin/trans_tiger.pdf | 14:05.37 |
| kens | I find transparency is just enough to overload my goldfish memory.... | 14:05.47 |
| | Got it thanks Robin_Watts | 14:05.59 |
| Robin_Watts | I just added /ca 0.5 and /CA 0.5 to an ExtGState. | 14:06.07 |
| kens | Good enough for me :-) | 14:06.15 |
| mvrhel_laptop | kens: I know the feeling. I am having the same feeling with DeviceN and overprint right now with my attempts to get overprint simulation working | 14:06.36 |
| kens | yeah that all looks pretty hideous | 14:06.56 |
| mvrhel_laptop | I need to do some work on paper today to determine if this is even possible | 14:07.00 |
| | the Ghent tests are killing me | 14:07.08 |
| | I think the difficulty is in the DeviceN colors that mix the spot and process colors (CMYK) and then also have just a lone spot | 14:07.45 |
| kens | They are fairly comprehensive on overprint testing. I have an open bug for pdfwrite that says I don't handle most (any ?) of them correctly. | 14:07.46 |
| mvrhel_laptop | both get converted to CMYK alternate space for CMYK device and so the overprint blending simulation really cant work in that case | 14:08.12 |
| kens | err, Robin_Watts the problem with the tiger file is that whole content is now transparent | 14:08.29 |
| Robin_Watts | kens: right. Why is that a problem? | 14:08.42 |
| mvrhel_laptop | I may end up having to abandon the overprint simulation | 14:08.53 |
| kens | So I can't tell if pdfwrite is rendering the whole content to an image, or just the transparent bits | 14:08.57 |
| Robin_Watts | Would you rather I made just the second half of the content transparent? | 14:09.05 |
| kens | Robin_Watts : that would be good I think | 14:09.21 |
| | as long as some portion of it is not transparent | 14:09.28 |
| Robin_Watts | http://ghostscript.com/~robin/trans_tiger2.pdf | 14:11.08 |
| | Left hand whiskers are solid, right hand are transparent. | 14:11.18 |
| kens | Shows a blank page for me, let me download it | 14:11.28 |
| Robin_Watts | kens: If you want I can pdf clean it, then it'll work in pdf.js | 14:12.01 |
| kens | OK Acrobat shows it fine | 14:12.04 |
| | If needs be I can save it from there thanks | 14:12.28 |
| Robin_Watts | ok. | 14:12.33 |
| kens | OK ps2write still renders the whole page as an image. THat may be sub-optimal | 14:13.51 |
| mvrhel_laptop | kens: some of the work that ray_laptop did, to ensure only the bands that had transparency actually ended up pushing the pdf14 device may be of help to you with this | 14:33.45 |
| | not sure | 14:33.47 |
| | that was for the clist | 14:33.54 |
| kens | mvrhel_laptop : ray mentioned it on the bug thread | 14:34.05 |
| mvrhel_laptop | so it may not be helpful, but I thought I would mention it | 14:34.09 |
| | oh ok | 14:34.15 |
| | just did not want you to have to reinvent the wheel | 14:34.32 |
| kens | I'm going to pass on doing anything more with this bug until he's done the clist for high level devices stuff :-) | 14:34.32 |
| mvrhel_laptop | sounds like a good idea | 14:34.42 |
| kens | But I would liek to see what Poppler makes of tehse PDF files | 14:34.47 |
| mvrhel_laptop | yes | 14:34.53 |
| kens | WHich means building Poppler, which means getting a new version of automake..... | 14:35.02 |
| | I thin I'm lost in dependencies.... | 14:35.16 |
| chrisl | kens: can't you just install it? | 14:35.24 |
| kens | chrisl, working on that now | 14:35.32 |
| | chrisl I thought I would get the poppler source from Git and build it.... May have been a bad plan | 14:36.57 |
| chrisl | kens: bit of a nightmare, IIRC, I don't think I ever got it to build, but not sure..... | 14:37.37 |
| kens | failed again 'cannot find install-sh'. I think I'll give up | 14:39.22 |
| mvrhel_laptop | brb | 14:39.46 |
| chrisl | hmm, install scripts should come with the package | 14:39.47 |
| kens | I told it to install poppler, it may not be bang up to date but it'll do | 14:40.30 |
| chrisl | Hmmm, I dunno how to tell pdftops how to not compress the entire file | 14:41.13 |
| kens | Maybe you can't | 14:42.00 |
| henrys | I'll be in and out today - it's probably time for my dog, he's 13 1/2 and not doing well. | 14:42.03 |
| chrisl | kens: so, pdftops produces a 2.3Mb compressed PS file from trans_tiger2.pdf - "feels" like a full page image to me | 14:42.19 |
| kens | me too | 14:42.26 |
| | If you post it somewhere I'll decompress it and look closely. | 14:42.48 |
| | Since your 10 minutes ahead of me.... | 14:42.57 |
| chrisl | kens: http://www.ghostscript.com/~chrisl/trans_tiger2.ps | 14:43.50 |
| kens | THanks. | 14:44.17 |
| chrisl | Oh, crap, no that's ours! | 14:44.24 |
| kens | ROFL | 14:44.31 |
| | 9.06 output | 14:44.44 |
| chrisl | So, where the hell did pdftops put it's file??? | 14:44.47 |
| kens | beats ne | 14:44.58 |
| chrisl | Ho! Found it - and it's 4.7 Mb! | 14:45.33 |
| | kens: same like above | 14:46.20 |
| ray_laptop | kens: the pdf14 compositor always write the entire page out as "transparent". It's only in clist mode where we can avoid using the pdf14 compositor for some bands that we can have some bands rendered w/o it. | 14:48.16 |
| | chrisl: have you looked at the problem from cust 532 ? | 14:48.47 |
| chrisl | ray_laptop: no, I haven't - which one? | 14:49.04 |
| ray_laptop | it came in after you were gone on Friday. | 14:49.45 |
| | chrisl: "Issues with Fix for a Crash" | 14:50.17 |
| kens | ray_laptop : thanks I understadn now | 14:50.33 |
| chrisl | ray_laptop: looking now - trying to decipher what they're talking about....... | 14:50.41 |
| ray_laptop | henrys: A PCL question just came in from cust 801. It's rather vague, but if you can handle it, that would be great. If not, let me know. Subject: Regarding PCL language | 14:52.07 |
| kens | So Poppler also creates a full page image. That's fine, we cna leave it alll until after Ray gets his clist enhancement sorted | 14:52.13 |
| chrisl | kens: question is: does it do it so quickly just because it's using 300dpi? | 14:52.47 |
| ray_laptop | chrisl: the follow up email from Naganuma-san has the 'diff' which helps (I think) | 14:53.02 |
| kens | chrisl I would imagine so yes. When I compared teims at 300 dpi we were basically the same | 14:53.09 |
| henrys | ray_laptop:well I was going to if marcosw didn't, he likes to have first crack at these, but if you'd like me to answer it now I will. | 14:53.17 |
| kens | chrisl don't forget, at 720 dpi we produce some 6 times the amount of data.... | 14:53.39 |
| chrisl | kens: well, that seems all good, then! | 14:54.25 |
| kens | chrisl I believe so, I will write some more into the bug thread shortly, its already closed so there's nothing more to dfo just yet | 14:54.49 |
| chrisl | kens: BTW, it looks to me like pdftops produces a full page image for the file posted on the bug | 14:54.57 |
| ray_laptop | henrys: I'm not sure if marcosw knows if there are options that are not in the docs (i.e., whether or not the docs are up to date) | 14:54.59 |
| henrys | ray_laptop:I'll send marcosw and support the answer, then he can do with it as he pleases. | 14:56.07 |
| kens | chrisl it seems to always to do so, just as we do | 14:58.57 |
| chrisl | kens: for much the same reasons, I imagine! | 14:59.19 |
| kens | chrisl I expect os, yes | 14:59.29 |
| chrisl | ray_laptop: can you e-mail/post the updated wheel.exe, please - wtf can't they use a standard image format?!?! | 15:00.16 |
| henrys | ray_laptop:I was just talking to chrisl about how I was kicking myself for not giving language switching a higher priority. | 15:07.55 |
| ray_laptop | chrisl: The updated 'wheel' is on their FTP site, but I've uploaded it to ghostscript.com/~ray | 15:25.34 |
| chrisl | ray_laptop: thanks - I struggling to find the e-mail with the ftp details - I know I've got it, can't remember where...... | 15:26.08 |
| ray_laptop | chrisl: I think the reason they don't use a "standard" format is that they have the 'tag' plane maintained in the data as a separate channel | 15:26.15 |
| | chrisl: see private chat | 15:29.11 |
| | trying to plow through my emails, then get into the hairier issue from cust 801 (reverse page order printing) | 15:38.02 |
| | If all they did was PDF it would be easy :=/ | 15:38.17 |
| henrys | ray_laptop:so bgprint and PCL? | 15:38.31 |
| | tested? | 15:38.36 |
| ray_laptop | henrys: BGPrint is coupled into the NumRenderingThreads > 0 weekly testing on Friday AM (Thursday midnight or something) | 15:39.27 |
| | henrys: BGPrint is 'invisible' to the languages since it's buried in the 'output_page' function | 15:40.05 |
| henrys | PCL does have some globals though but I think they are okay. | 15:40.38 |
| ray_laptop | as far as the parsing thread is concerned, the page was 'printed' once the bg thread starts | 15:40.43 |
| | henrys: the only globals of concern would be ones that the parsing thread sets that it expects the print_page procedure to use on the next page. | 15:42.01 |
| | then the current printing thread may or may not use the one for the next page on the page currently printing in the background | 15:42.54 |
| | henrys: and they would be localized in a specific device | 15:43.23 |
| | henrys: the upshot is that I am sure that PCL (or even XPS) is fine with BGPrint=true | 15:44.20 |
| | at least for the devices that enable it and that we've tested. | 15:44.46 |
| Robin_Watts | tor8: pdf_obj shrinking patch on robin master | 15:45.32 |
| henrys | ray_laptop:I sent my answer to marcosw if he wants me to send it I will thought not getting roped in is appealing. | 15:47.28 |
| ray_laptop | henrys: well, since I am usually communicating with them, should I go ahead and send it to them ? | 15:48.10 |
| | just so they have (mostly) a single point of contact ? | 15:48.37 |
| henrys | ray_laptop:whatever you think. | 15:51.17 |
| ray_laptop | henrys: thanks for that email. I'm sure that will help them. | 15:51.21 |
| | henrys: since marcosw isn't around (AFAICT) I'll go ahead and send it. He should see my version quickly enough that they won't get two replies. | 15:52.11 |
| tor8 | Robin_Watts: drop the /* char sorted; */ comment? | 15:52.21 |
| | looks good otherwise | 15:52.37 |
| Robin_Watts | oops. will do. | 15:52.50 |
| | tor8: oh, eck. | 15:55.11 |
| | pdf_obj's don't have a pdf_document pointer in them. | 15:55.26 |
| ray_laptop | marcosw: (for the logs). I forwarded henrys' reply to cust 801 so you don't need to. | 15:55.55 |
| tor8 | Robin_Watts: r.xref does though | 15:56.13 |
| ray_laptop | hopes he sees my reply before sending another one | 15:56.29 |
| tor8 | and there's a fz_context a well | 15:56.31 |
| Robin_Watts | Right, but we are proposing storing an int for all types. | 15:56.46 |
| tor8 | those could probably be merged and have the pdf_document at the fz_context's place | 15:56.52 |
| Robin_Watts | tor8: right. | 15:57.03 |
| tor8 | I believe the fz_context is a remnant from before the fz_obj -> pdf_obj rename | 15:57.22 |
| Robin_Watts | so replace the fz_context with a pdf_document. | 15:57.27 |
| | replacing ctx with ctx_ and rebuilding :)_ | 15:57.56 |
| | All the errors are in pdf-object.c | 15:58.24 |
| tor8 | yeah, it's an opaque type :) | 15:58.31 |
| Robin_Watts | D'Oh. | 16:00.22 |
| | So, mostly it's for the context for malloc/free etc. | 16:00.38 |
| tor8 | Robin_Watts: how about a pdf_associate_obj(pdf_obj *obj, pdf_document *doc, int number) to (recursively) set the object ownership (with a better name) | 16:00.40 |
| | yeah, in all but the resolve_object instance it's for malloc/free | 16:00.51 |
| Robin_Watts | but sometimes it's for the context used with errors. | 16:00.54 |
| tor8 | and for try/catch | 16:01.09 |
| Robin_Watts | try/catch is... interesting. | 16:01.23 |
| | we can't have 2 threads using the same ctx for errors at the same time. | 16:01.37 |
| tor8 | pdf_document is limited to a single thread though... but with all the caches and objects used as keys it gets ... interesting | 16:02.25 |
| | I have a feeling we should sometimes (you, me, and paul) have a get-together and bash out some of these things in person | 16:02.53 |
| kens | Sounds like a meeting in Copenhagen :-) | 16:03.30 |
| ray_laptop | kens: I'm going to take a crack at responding to Hiren if that's OK. I was going to include the relevant section of 'sample.ps' created by PSCRIPT5.DLL that shows him what's going on. | 16:04.01 |
| kens | ray_laptop : please do | 16:04.10 |
| ray_laptop | kens: ta | 16:04.16 |
| Robin_Watts | tor8: Are you volunteering for more travel? | 16:04.34 |
| kens | ray_laptop : you might also ask why he's doing this PDF->PS->PDF | 16:04.39 |
| Robin_Watts | Looking in docs/overview in the multithreaded section, I see rule 2: | 16:04.50 |
| kens | round-tripping is evil | 16:04.52 |
| Robin_Watts | "The document is bound to the context with which it is created." | 16:05.01 |
| | so that's fine, we wouldn't be breaking that. | 16:05.12 |
| ray_laptop | kens: They are using gs on the back end of a Windows (PS) printer and they probably want PDF out. | 16:05.26 |
| tor8 | make that documents, streams and pdf_objs IIRC | 16:05.40 |
| kens | ray but they are starting with a PDF ...... | 16:05.55 |
| tor8 | Robin_Watts: travel within europe is fine, it's the long hauls and annoying immigration procedures that bother me most | 16:06.09 |
| Robin_Watts | pdf_objs would be bound to the document, which would be bound to the context. | 16:06.26 |
| ray_laptop | kens: I don't think they know WHAT the customer is printing from | 16:06.42 |
| tor8 | Robin_Watts: yes. except when they're not bound to a document (yet) | 16:06.49 |
| Robin_Watts | tor8: I propose to make them all be bound to a document. | 16:07.06 |
| tor8 | (like during parsing, or when creating stuff) | 16:07.08 |
| kens | ray_laptop : I'm confused then. How are they ending up with PostScript which is secured against distilling if they don't start from a PDF ? | 16:07.15 |
| Robin_Watts | i.e. instead of ever passing an fz_context, I would pass a pdf_document. | 16:07.26 |
| tor8 | use pdf_document instead of fz_context for pdf_new_xxx? | 16:07.28 |
| Robin_Watts | yes. | 16:07.33 |
| tor8 | right. sounds good. | 16:07.40 |
| | Robin_Watts: except one thing ... don't you transfer pdf_obj's between xrefs when doing the linearisation/renumbering? | 16:08.31 |
| ray_laptop | kens: the customer is printing a PDF file to their windows driver (which happens to be a PS->gs coupling). It's the Adobe/Microsoft PSCRIPT5.DLL that is putting in the 'no distill' stuff | 16:08.42 |
| kens | Right, so they are starting with a PDF file | 16:09.02 |
| Robin_Watts | tor8: Possibly. If so, there will have to be a 'pdf_obj_transfer' function or something. | 16:09.07 |
| kens | converting to PS and back to PDF is a Bad Thing (TM) | 16:09.20 |
| ray_laptop | undoubtedly using a PostScript pass through from the Adobe Reader 'print' function | 16:09.21 |
| tor8 | fair enough. or pdf_own_obj(obj, doc, number) or something like that which would be used when saving mutated objects to freeze the incremental update xref | 16:09.58 |
| ray_laptop | kens: hmm... I was admonishing Hiren about removing the "no re-distill" code and why he shouldn't be doing it because it would create an unprotected PDF, but that's exactly what gs does from the original :-/ | 16:34.22 |
| | kens: unless I'm missing something. | 16:34.41 |
| kens | PDF or PS output ? | 16:35.05 |
| ray_laptop | goes to check the PDF spec permissions | 16:35.10 |
| | kens: PDF output | 16:35.25 |
| kens | Umm, I have not tried this recently (oor possibly at all) | 16:35.42 |
| ray_laptop | gswin32c -sDEVICE=pdfwrite -o x.pdf sample.pdf | 16:35.43 |
| kens | ray_laptop : if its a protected fiel, that shoudn't work | 16:36.01 |
| ray_laptop | where sample.pdf has the Encrypt in the trailer x.pdf doesn't | 16:36.12 |
| kens | I guess iits debatable | 16:36.28 |
| ray_laptop | kens: is that an 'oops' ? | 16:36.37 |
| kens | Presumably the file is 'allowed to print' | 16:36.39 |
| ray_laptop | kens: according to Hiren, it has "OK to print" (I am looking now) | 16:37.11 |
| kens | I'm not sure whhat we can do about that. We can't use teh original passwords (don;t know them). | 16:37.22 |
| ray_laptop | kens: the PDF interpreter has to know them right ? | 16:38.49 |
| kens | ray_laptop : not if the file is only secured with an owner password, and allowed to print | 16:39.14 |
| | But its been a very long time since I looked at the (rahter poor) PDF security stuff | 16:39.37 |
| | I'm going to have to go, need to cook dinner | 16:39.54 |
| | night all | 16:40.05 |
| ray_laptop | hmm... mutool clean also removes the encryption | 16:41.55 |
| Robin_Watts | shhh! | 16:42.03 |
| ray_laptop | hmm... the document _does_ have 'content copying' allowed and 'content copying for accessibility' allowed | 16:45.14 |
| | but once we process it, we no longer have the disallowed things set (changing the document, document assembly, and page extraction) | 16:47.01 |
| | strange. Acrobat won't let me save it as an 'optimized pdf' but it WILL let me save it as a PDF/A | 17:06.43 |
| | but Acrobat creates the PDF/A with the permission bits the same | 17:07.08 |
| | Robin_Watts: tor8: anybody: What's the other linux pdf to ps converter ? (besides us) | 17:08.01 |
| | oh, I guess it's poppler | 17:08.47 |
| Robin_Watts | not a clue, sorry | 17:08.48 |
| ray_laptop | (pdftops -v) | 17:08.56 |
| Robin_Watts | oh, pdf to ps, yes, probably poppler. | 17:09.04 |
| dogisfat | Is there a reason that ghostscript would shift all objects on a page to be centered around 0y? | 19:19.55 |
| Robin_Watts | nope. | 19:20.56 |
| dogisfat | When I look at the PS file that I am feeding GS there are no pageoffset commands and all of the moves/lines are positive. When I run the PS file through a driver it ends up making moves/lines to negative y values that seem to center the image around 0y. | 19:27.01 |
| Robin_Watts | Any translate commands? | 19:30.41 |
| | Any code to set the matrix ? | 19:30.53 |
| bdam | Wondering if anyone might be able/willing to answer GS printing question. | 19:32.51 |
| Robin_Watts | bdam: Ask your question, don't ask to ask :) | 19:34.01 |
| bdam | Fair enough. I'm printing 200+ page manuscripts with GS's mswinpr2 driver. They are primarily monochrome but will have shading/dithering and other design elements on the title/chapter pages. | 19:35.45 |
| | I can't seem to get the shading to print as it would if manually printed via a regular Windows driver. | 19:36.32 |
| | If I set bitsperpixel to 1 it produced pronounced banding, set it to 4 and the shading has a pronounced pattern, set it to 24 and the print jobs become so large they just won't print. | 19:37.25 |
| Robin_Watts | What printer are you going to? (not so much model as technology) | 19:38.08 |
| | mono laser? 4 ink inkjet ? | 19:38.24 |
| dogisfat | Robin_Watts: Is there a trace output I could enable which would show translations/matrix modifications? The setup in the PS file is beyond me. | 19:38.56 |
| bdam | It's a canon laser (imagerunner 7105) | 19:38.59 |
| | mono | 19:39.16 |
| Robin_Watts | bdam: OK. | 19:39.36 |
| | So, if it was me, I'd try using gs to print to a 1bpp bitmap and look to see if the results there were what I expected. | 19:40.24 |
| | Are you OK using a command prompt ? | 19:40.34 |
| | gswin32c.exe -sDEVICE=pbmraw -o out.pbm -r300 -dLastPage=1 in.pdf | 19:41.23 |
| | That will print the first page of in.pdf to out.pbm | 19:41.33 |
| bdam | sure. For full discloure I'm doing this via PDF Creator using so it'll take me a few minutes to set up GS proper. | 19:41.51 |
| | sorry, it's using GS 9.07 | 19:42.30 |
| Robin_Watts | Are you complaining that if you print the page to a printer using a 'normal' windows printer driver, that the shading/dithering it uses is different to that used by gs ? | 19:46.36 |
| bdam | Correct although this isn't so much a complaint as discovering if there's some middle ground I've missed. If printing the PDF manually it's fine but via GS I seemingly have a choice of banding, distinct patterns, or files too large to print. | 19:48.40 |
| Robin_Watts | bdam: Well, there is no 'correct' way to convert from contone to mono. | 19:49.30 |
| | So we have various ways built into gs. | 19:49.44 |
| | You're probably getting our standard dithering routines. | 19:49.53 |
| | You can change the halftones used. | 19:50.08 |
| | For top quality, you might want to consider using a different device, and getting error diffusion. | 19:50.37 |
| | but we'd need to see an example to be able to comment properly. | 19:50.56 |
| bdam | When you say device, you mean using a different GS device type (ex IJS) or a different printer? | 19:54.17 |
| Robin_Watts | bdam: I mean printing to tiff or something. | 19:54.52 |
| | and then maybe reprinting the tiff. | 19:55.00 |
| dogisfat | It would seem I have found my problem, OSX is somehow corrupting the PS file | 19:56.58 |
| | Why would supplying a page size and then a custom page size make a PS file improperly interpreted? | 20:04.18 |
| bdam | Thanks for the help Robin, I made some progress but I'm done for the day, just wanted to thank you for your guidance. | 20:57.54 |
| Robin_Watts | bdam: no worries. I'll be here tomorrow too, | 20:58.10 |
| | as will others. | 20:58.14 |
| Gigs- | could someone mark the file attached to http://bugs.ghostscript.com/show_bug.cgi?id=694372 private please | 21:30.07 |
| | libpng seems to fail building | 21:57.22 |
| | my fault, nevermind | 22:01.59 |
| | Robin_Watts: can you get that bugzilla file for me | 22:04.11 |
| | have a second private file at http://bugs.ghostscript.com/show_bug.cgi?id=694373 | 22:24.51 |
| | please mark | 22:24.53 |
| | I thought this last one might be running into the colorant limit, but I tried upping the soft limit to 16 and it still fails | 22:26.35 |
| | instead of CMYK it defines a deviceN colorspace with 4 colors that effectively replace CMYK | 22:27.01 |
| Robin_Watts | Gigs-: Marking as private now. | 22:50.12 |
| | should be private now? | 22:50.45 |
| | Forward 1 day (to 2013/06/25)>>> | |
IRC Logs