| | <<<Back 1 day (to 2012/02/27) | 2012/02/28 |
| rurounijones | Hello all, this is a bit out of the blue but assuming I wanted some paid development work done requires mupdf knowledge are there any well-known individuals / companies (besides artifex) I could be pointed to. Or any places where I could ask? I dont wan't to post to the gs-devel mailing list first in case that is a faux-pas | 05:05.48 |
| mvrhel | tkamppeter_: you there? | 05:28.25 |
| henrys | mvrhel:I sort of feel like the new icc operators should take a gstate parameter like other operators instead of an imager state. Is it okay if I change that - given there aren't problems with doing it. | 05:43.07 |
| mvrhel | henrys: no that is fine | 05:52.15 |
| | good night off to bed | 05:59.41 |
| kens | Morning chrisl | 09:28.32 |
| chrisl | morning kens | 09:31.13 |
| kens | Did it take you long to get home yesterday ? | 09:31.31 |
| chrisl | No, it was a fairly easy drive this time | 09:32.10 |
| kens | probably just as well :-) | 09:32.23 |
| chrisl | Yeh! Did you get your bus okay? | 09:32.43 |
| kens | Indeed. Caught one at 9:20, was home by 11:30 | 09:32.58 |
| chrisl | About the same time as me, then | 09:33.49 |
| kens | Robin got home fastest then I guess | 09:34.06 |
| chrisl | Well, I had a coffee before leaving the airport - I saw the car park bus pulling away as I reached the door, and figured a dose of caffeine would not hurt! | 09:36.09 |
| kens | rurounijones, yes there are people other than the Artifex developers who can do MuPDF development work. It depends what you want done. | 09:38.09 |
| | I would suggest consulting with Robin Watts or tor8 when they are online (neither is yet). If you private message them when you see them talking you can discuss your requirements then. | 09:38.49 |
| rurounijones | kens. Excellent, thank you very much for the information | 09:57.28 |
| | I dont suppose you know which timezones they live in? | 09:57.46 |
| | Speaking of which, time to go home, I shall be back in an hour or so and hang around from then on. | 09:59.00 |
| kens | ruronijones Robin is in the UK, tor is in Sweden | 10:01.58 |
| | However both are late starters :-) | 10:02.08 |
| | oh, too wlo, I'll repeat when he gets back | 10:02.31 |
| | Hmm, my PCL change caused 449 diffs in pdfwrite. | 10:03.44 |
| | I wonder how widespread this bug is. | 10:03.54 |
| | Oddly, no diffs with ps2write.... | 10:04.32 |
| chrisl | I would guess that (almost?) every PCL/PXL file with truetype outlines is likely to be a candidate | 10:07.21 |
| kens | It should only be files with downloaded TrueType fonts | 10:13.51 |
| | But I'll see in a minute. | 10:14.00 |
| | I'm still puzzled why ps2write shows no diffs. | 10:14.24 |
| chrisl | Does it have something "special" to deal with fonts that would be symbolic in a PDF that makes this work? | 10:15.07 |
| kens | I wa wondering that, I will look at it after I check the diffs. If so I could elver off that and not change PCL at all | 10:15.34 |
| | Well the ps2write output is missing the text too, even with my change, so it looks like it aborts out in a different way. I guess that's why there are no diffs. | 10:18.28 |
| | I suppose I'd better loook at that too :-( | 10:18.42 |
| chrisl | Oh, that's a shame :-( | 10:18.46 |
| kens | Actually, I'm lying | 10:19.30 |
| | I used the 9.05 release instead of my patched code. My code works OK with ps2write | 10:19.47 |
| | So that's even more puzzling with the cluster result | 10:20.08 |
| | The cluster result is odd. THere are many small outline differences | 10:21.04 |
| | Hmm, I wonder if something has changed and I havent updated my tree | 10:22.14 |
| | No, my tree is up to date.... | 10:23.20 |
| | Bizarre. | 10:23.48 |
| | Ah wait, I forgot the 'pcl' on my bmpcmp. | 10:24.21 |
| | These are mostly PS diffs. | 10:24.55 |
| halabund | I am preparing some figures and I am having a hard time deciding what line width to use for a feature. As thin as possible while still clearly visible is preferable. I don't have a printer right now to test. Does anyone know if printers have a lower bound on line widths, i.e. is it safe to set it to as thin as 0.1 points without worrying that it'll disappear? The figure is exported to PDF. | 10:39.55 |
| | Adobe Reader does have a lower bound, i..e it'll never render the line thinner than 1 pixel. I am wondering if I can assume something similar for print as well. | 10:40.13 |
| | And other PDF/PostScipt viewers as well. | 10:40.41 |
| Robin_Watts | halabund: Short answer - no. | 10:44.39 |
| | There is no consistent way to guarantee a minimum feature size in pdf. | 10:44.57 |
| halabund | Robin_Watts: so if I set the line width, it is possible that the line will disappear when printed? | 10:45.14 |
| Robin_Watts | yes. | 10:45.23 |
| halabund | Hm. That's pretty bad. | 10:45.38 |
| | Well, I'll try it on a printed when I get the chance. If it prints fine, I'll just use the thin lines, and hope that everything will be fine on other printers as well. | 10:46.19 |
| | I hope the journal will complain in time if something is wrong. | 10:46.29 |
| | *printer | 10:46.42 |
| | Robin_Watts: But I heard a few time people talk about a PostScript "hairline". I don't know what that is, but I assumed it would be a line as small as possible while still visible, something like what I need. Is this "hairline" a technical term at all? | 10:48.06 |
| kens | 0 setlinewidth in PostScript sets a line of 0 width. PS guarantess this will be one pixel wide on all devices. | 10:48.48 |
| chrisl | halabund: (From PDF reference manual) A line width of 0 denotes the thinnest line that can be rendered at device resolution: 1 device pixel wide. However, some devices cannot reproduce 1-pixel lines, and on high-resolution devices, they are nearly invisible. Since the results of rendering such zero-width lines are device-dependent, their use is not recommended. | 10:49.20 |
| kens | chrisl but that is only going to work on a printer which prints PDF directly (if at all) | 10:49.44 |
| halabund | kens: that sounds great. Do you know if a small but positive line width will behave the same? My program fails to export 0-width lines correctly. (It just uses it's default width which is too thick) | 10:50.05 |
| | chrisl: Thanks | 10:50.18 |
| kens | halabund, no it won't, its a special feature of PostScript | 10:50.40 |
| | chrisl what's the name of the 'recover your system' Linuyx distribution ? | 10:51.28 |
| chrisl | kens: RIP Linus | 10:51.39 |
| | RIP LInux | 10:51.43 |
| kens | THat's it, thanks | 10:51.45 |
| chrisl | kens: I assumed that most methods of converting PDF to PS would preserve common features, like a "0" linewidth....... | 10:52.34 |
| halabund | I'm looking at the postscript output of the program, and it has a line that reads "/w{setlinewidth}bind def" Does this define w to mean setlinewidth? | 10:52.40 |
| chrisl | Yes | 10:52.59 |
| kens | chrisl I suspect most will convert to a bitmap, so it 'depends'. Given that on Windows it will have to go via GDI+, all bets are off :-) | 10:53.17 |
| chrisl | halabund: note that some programs emit PS with several levels of (re)definitions. | 10:53.50 |
| kens | Robin_Watts : ping | 10:54.24 |
| Robin_Watts | pong | 10:54.33 |
| chrisl | kens: Acrobat can produce its own PS, so it *shouldn't* go through GDI. | 10:54.39 |
| kens | Robin_Watts : sorry, ignore me, I'm being silly | 10:54.55 |
| | chrisl, f yes, PostScript should be fine, I was thinking generally | 10:55.10 |
| | This bmpcmp is weird, I wonder what is going on.... | 10:56.22 |
| chrisl | kens: well, to a non-PS printer, the GDI "rendering" should be targeted at the device, so it *ought* to be capable of handling a one device unit wide line. | 10:56.59 |
| kens | chrisl, but a GDI+ conversion means it won't know* its supposed to be a single pixel | 10:57.54 |
| chrisl | I thought GDI output was resolution specific....... | 10:59.56 |
| halabund | On an 1200 dpi device a hairline would be 0.002 mm wide. That sounds like it might be pretty close to invisible. Does anyone have any experience with what is the thinnest comfortably visible line width? I am thinking of using 0.5 point as a compromise. That is 0.18 mm. I am hoping that should be visible when printed as solid black on white. | 11:00.00 |
| kens | chrisl, I don't think you can specify a line widht as one pixel. | 11:00.18 |
| chrisl | But I would assume it can specify the width of line, which could be the size of a pixel | 11:02.29 |
| kens | halabund, the human eye can resolve down to ~1000 dpi at a comfortable reading distance. Obviously if you look closely, or furhter away, that changes. | 11:02.55 |
| | So it depends what you are trying to do with the line | 11:03.16 |
| halabund | Oh, then 0.5 points will be more than enough :-) | 11:03.28 |
| | Thanks for all the help! | 11:03.32 |
| kens | NP | 11:03.36 |
| halabund | This channel is always very friendly | 11:03.41 |
| kens | Intriguing. My new change causes 'some' embedded TrueType fonts to be embedded as TrueType fonts where previously they were embedded as bitmaps. | 14:10.20 |
| | Which is a plus, I just wish I knew why..... | 14:10.33 |
| | Oh, but oddly the text goes missing.... Not what regressionm testing showed. | 14:11.58 |
| Robin_Watts | tor8: Removing atof saves 13% on the whole of this test file, 24% on the problem page. | 14:16.34 |
| sebras | Robin_Watts: what do you replace atof() with? | 15:20.21 |
| Robin_Watts | I use my own routine, done as part of the lexing. | 15:20.54 |
| | (previously we lexed the number into a buffer, then effectively lexed it again while doing atof. | 15:21.24 |
| malc_ | hah. i was about to ask atof question myself | 15:21.37 |
| Robin_Watts | I did that on the plane over, but didn't get to do timings until just now. | 15:22.29 |
| malc_ | i remember seeing some conversion code that was over 1K lines long.. i.e. the thing is not as trivial as appears on the first glance | 15:23.26 |
| Robin_Watts | malc_: General conversion code, no. The new mupdf lexing atof/atoi is much simpler. | 15:29.29 |
| malc_ | Robin_Watts: btw. i just made an announcement of my stuff's release only to be notified that it doesn't build with current mupdf.. excellent timing for fz->pdf renaming :) | 15:31.30 |
| Robin_Watts | Sorry :) | 15:32.57 |
| | There is a rename2.sed script in the source that you may find useful. | 15:33.11 |
| | MuPDF 1.0 should be out this month, so we had to do the rename before that. | 15:33.47 |
| malc_ | Robin_Watts: nah, users just don't use the recommended build procedure it seems, which lists/fetches the your(plural) stuff that my stuff is known to work with :) | 15:38.03 |
| kens | Guys, I have to go give blood in half an hour. I hope to be back by 5pm, but I may be a few minutes late | 15:39.05 |
| Robin_Watts | kens: I doubt there will be much of a meeting. | 15:39.23 |
| kens | True, but just in case :-) | 15:40.50 |
| henrys | I was assuming we'd go without a meeting, but if anyone didn't have enough in SF I'm ready to go. | 15:50.47 |
| Robin_Watts | henrys: I mentioned the possibility of mupdf/javascript work to Paul, and he's interested. | 15:56.57 |
| henrys | very good news | 15:57.24 |
| tkamppeter | pitti, I have tested the postinst scripts calls of CUPS now (for bug 932882), by adding "touch /tmp/X; echo $* >> /tmp/X" to the beginning of the postinst. After "sudo dpkg -i <cups package> <printer-driver-gutenprint package>", /tmp/X contains "configure 1.5.2-5" twice and no "triggered" line. So the trigger is never executed. | 16:01.35 |
| | sorry, wrong channel. | 16:03.38 |
| henrys | kens:I sent you a report about the pcl->pdf with questions to ask the customer, I guess it would be easier if I followed up directly. | 16:24.25 |
| | ray_laptop:we thought skipping the meeting would be okay today. | 16:34.34 |
| ray_laptop | henrys: OK. just mention my nick if you want to chat with me about anything pending from the staff meeting | 16:35.13 |
| henrys | I see you have another top priority problem. | 16:36.31 |
| | mvrhel_laptop:just the man I wanted to see. | 16:37.38 |
| mvrhel_laptop | uhoh | 16:37.43 |
| ray_laptop | henrys: they're always "urgent" :-( | 16:38.11 |
| henrys | ray_laptop:lots of drama | 16:38.22 |
| | mvrhel_laptop:well I have everything (icc settings) coded up but it seems odd - when I set the default rgb icc it won't do it because the default was already set when the graphics state was set up. I'll poke at it a bit more because I want to understand it a bit better. | 16:39.29 |
| mvrhel_laptop | henrys: It should only not set it if you are trying to set it to the same thing that it is already set to | 16:39.59 |
| | then it ignores and moves on | 16:40.07 |
| | otherwise it should go ahead and release the default one and assign yours | 16:40.28 |
| | perhaps I broke something though.... | 16:40.46 |
| | this is why I need to create the test command sequence for these options | 16:41.00 |
| henrys | maybe I'm readiing the code wrong it looks like if *manager_default_profile == NULL it will set it. | 16:44.05 |
| mvrhel_laptop | let me look | 16:44.40 |
| | oh I see | 16:47.21 |
| | yes. so in PDF and PS, if the command line option was set, this ends up occurring before any defaults get set | 16:47.46 |
| | so for you this may not work henrys | 16:47.57 |
| | unless you make sure to do the command line settings before doing your intialization | 16:48.21 |
| | I had to do it this way because otherwise things were getting screwed up during a vmreclaim as mentioned in the long comment | 16:49.07 |
| henrys | okay I'll sort it out. | 16:49.38 |
| mvrhel_laptop | if I recall you do a call to gsicc_init_iccmanager. You will want to set your profiles that have been specified on the command line before doing the call to gsicc_init_iccmanager | 16:51.05 |
| moonbuggy | hi | 16:52.59 |
| Robin_Watts | tor8: I just built pdfdraw from the customers source; it takes 0.63seconds to do the problem page. Our current source takes 0.44. So I don't see their problem. | 16:53.04 |
| henrys | mvrhel_laptop:right thanks | 16:53.13 |
| Robin_Watts | henrys: When you finish with mvrhel, can we talk about the HPGL thing? | 16:53.34 |
| | moonbuggy: hi. | 16:53.50 |
| mvrhel_laptop | Robin_Watts: sure. we can talk. I know nothing about HPGL though so may not have much to offer :) | 16:54.06 |
| Robin_Watts | mvrhel_laptop: Perhaps I was unclear :) | 16:54.23 |
| henrys | Robin_Watts:go ahead | 16:54.36 |
| mvrhel_laptop | oh sorry | 16:54.39 |
| | you want to talk to henrys | 16:54.48 |
| moonbuggy | whats this about? | 16:55.01 |
| | i came axcros it online | 16:55.09 |
| | and i saw your irc logs go to the web | 16:55.21 |
| Robin_Watts | henrys: Did you get the patch/test file I sent? | 16:55.40 |
| henrys | no when did you mail it? | 16:56.07 |
| Robin_Watts | Last night. Let me check I didn't misspell your address. | 16:56.18 |
| moonbuggy | i quess i will continue searching for how to get irc logs onto the internet | 16:57.06 |
| Robin_Watts | Yeah, I mailed it at 20:50 last night. | 16:58.04 |
| | I can resend. | 16:58.07 |
| | resent | 16:59.10 |
| marcosw_ | are we meeting today? | 16:59.35 |
| henrys | Robin_Watts:there it is I completely missed it sorry | 16:59.36 |
| Robin_Watts | no worries. | 16:59.43 |
| henrys | marcosw_:I thought we'd skip do you have something? | 16:59.54 |
| Robin_Watts | henrys: Basically I want to know that my interpretation of the stroking/filling of such paths is correct. | 17:00.09 |
| marcosw_ | no, I'm good. just didn't want to miss it if we were. | 17:00.37 |
| Robin_Watts | (Essentially any moveto that follows a moveto is treated as a lineto when filling, and as a 'gap' when stroking) | 17:01.05 |
| | The key point is that a b moveto c d moveto closepath will close back to a b not to c d. | 17:01.44 |
| henrys | yes that seems perfectly correct | 17:03.17 |
| Robin_Watts | I've implemented it currently by spotting moveto/moveto at creation time and replacing that in the internal representation of the path as moveto gapto if the flag is set. | 17:05.45 |
| ray_laptop | Robin_Watts: actually, each moveto is supposed to start a sub-path when filling -- not a lineto | 17:05.55 |
| Robin_Watts | ray_laptop: No, this isn't postscript/PDF. | 17:06.10 |
| | HPGL path filling follows a different convention. | 17:06.27 |
| ray_laptop | Robin_Watts: sorry -- I didn't know it was HP-GL | 17:06.42 |
| Robin_Watts | ray_laptop: np. | 17:06.50 |
| henrys | It seems to be spot on - but I'll prepare a few more tests - we should look at even odd and non zero for these goofy fills on the HP. | 17:07.47 |
| Robin_Watts | If I stay working the way I am, I need to make it so that gaptos can be written to the clist. | 17:07.56 |
| | And the extra hpglfillmode flag of course. | 17:08.10 |
| henrys | Robin_Watts:you knocked down so much of it on the plane it would be a shame to drop it now. | 17:09.10 |
| kens | is back | 17:09.29 |
| Robin_Watts | I am tempted (now I have a clearer picture of what's required) to try and update the fill/stroke code to spot moveto/moveto on the fly, so I don't have this extra type kicking around. | 17:09.35 |
| | Whatever happens there will be some pdfwrite tweaking to do. | 17:09.56 |
| henrys | kens scroll back | 17:10.05 |
| Robin_Watts | I chatted to kens about this on the way to immigration :) | 17:10.31 |
| henrys | kens:actually you reminded me I need to go and give blood too. | 17:10.43 |
| kens | henrys, was just reading. Yes,please follow up with Aaron and co directly :-) | 17:11.01 |
| henrys | will do. | 17:11.10 |
| kens | henrys, over here they send me a form to fill in and bring along when its time | 17:11.26 |
| Robin_Watts | marcosw_: Closest possible silverstone dates are 5th May or 25th March. | 17:11.30 |
| | Neither of which sound ideal. | 17:11.39 |
| kens | IIRC marcos is at the show on the 5th | 17:11.51 |
| Robin_Watts | Indeed. | 17:12.00 |
| | Sorry, ignore 25th March. | 17:12.15 |
| | 8th April. | 17:12.21 |
| | There may be more dates to come in April, but they don't know them yet. | 17:12.51 |
| | Actually, changing the subpath handling in the scanline rasteriser scares me, so I'm going to stick with the current scheme. | 17:18.56 |
| henrys | mvrhel_laptop:found another thing - the languages call gs_state_alloc() to create their graphics state which in turn call gsicc_init_iccmanager() - you added the icc init manager after gs_state_alloc - and I assume you need a graphics state as the init_icc_manager() needs it - chicken and egg. | 17:19.38 |
| mvrhel_laptop | ah | 17:20.11 |
| henrys | see pctop.c:243 | 17:20.31 |
| | that gs_state_alloc has already called the init icc manager function. | 17:21.02 |
| | so you must be calling the init manager with uninitialized graphics state in ghostscript. | 17:22.26 |
| | ps/pdf | 17:22.32 |
| mvrhel_laptop | hmm. where does the alloc initialize it? | 17:22.49 |
| | I see where it creates a new one | 17:22.57 |
| | in gs_imager_state_initialize | 17:23.04 |
| | but I don't see an initialization | 17:23.15 |
| | of it | 17:23.17 |
| | it being the icc manager | 17:23.27 |
| | it looks like it is done in pcl_impl_allocate_interp_instance | 17:23.44 |
| henrys | oh right duh sorry. | 17:23.47 |
| mvrhel_laptop | having a pissing match with people in the openicc discussion | 17:24.16 |
| | fun stuff | 17:24.20 |
| henrys | is this a public thing or an email war | 17:25.05 |
| | ? | 17:25.14 |
| mvrhel_laptop | hehe. It is a mailing list | 17:28.45 |
| Robin_Watts | I couldn't find public archives with google. | 17:29.13 |
| mvrhel_laptop | I guess to call it a pissing match is a bit much. I just know some of the people on this list get pretty worked up and I poked one who I know has some strong opinions | 17:29.40 |
| | I had seen some misinformation about Ghostscript and its capabilities in color and also there seems to be some misunderstanding about output intents and PDF files so I am trying to make sure that it is understood what ghostscript can do. tkamppeter may need to expose some of the color API in the pdftoraster filter for cups | 17:32.06 |
| | http://www.freedesktop.org/wiki/OpenIcc | 17:32.25 |
| Robin_Watts | "In real life, if you meet someone with their pants on inside out, and a dead parrot stapled to their lapel, it's a good bet they are a nutter. On the Internet you have no such warning." (J Michael Straczynski) (possibly paraphrased) | 17:32.36 |
| mvrhel_laptop | yes. | 17:33.12 |
| henrys | bbiab | 17:38.17 |
| mvrhel_laptop | ok. back to the output intent salt mine | 17:46.47 |
| | kens: question for you | 17:47.33 |
| kens | ? | 17:47.37 |
| mvrhel_laptop | what do you know about the /writeoutputintents command in pdf_main.ps | 17:48.16 |
| | was this for writing out the outputintent in pdfwrite? | 17:48.28 |
| kens | I believe it does, for PDF/A | 17:48.56 |
| mvrhel_laptop | ok. alexcher was asking me if I wanted to use this for what I need but I fear that it would only serve to confuse things since my goal is to make use of the output intent for rendering. Not set an output intent for describing what the device data means | 17:49.59 |
| kens | But its a PDF input thing, so I'm not sure now | 17:50.05 |
| mvrhel_laptop | well, that is the difference and my reasoning for keeping two different operators | 17:50.35 |
| kens | Makes sense to me | 17:50.54 |
| mvrhel_laptop | ok. good. me too | 17:51.37 |
| | we are going to have to sort all of this out for pdfwrite at some point | 17:52.06 |
| | as to how to use all of these color settings. the output intent only add to the fun | 17:52.33 |
| | s/add/adds/ | 17:52.41 |
| kens | I need to redo all the colour handling anyway, but its second on the list now | 17:53.24 |
| | TIme for me to be off, goodnight all | 17:56.17 |
| henrys | mvrhel_laptop:so I guess it is not trivial to allow the default to be reset? The way things are set up the arguments aren't even processed before you init the icc. The way pcl and the other languages are set up now the following should be legal: pcl6 -sDEVICE=ppmraw -o foo.ppm -dDefaultRBGProfile=some.icc -sDEVICE=pbmraw -dDefaultGrayProfile=another.icc -o foo.pbm. | 18:02.29 |
| | sorry there should be a pcl file argument after each -sDEVICE | 18:03.31 |
| mvrhel_laptop | henrys: I understand. | 18:03.42 |
| | If I recall, I was having an issue with vmreclaims blowing away and resetting the profiles | 18:04.09 |
| henrys | I am in the process of redoing so it is just ghostscript | 18:04.11 |
| | but that's a ways off. | 18:04.16 |
| mvrhel_laptop | this was before I fixed a lot of memory related issues with profiles though | 18:04.28 |
| | so, it is possible that it may work to remove the NULL check | 18:04.40 |
| | I would need to test | 18:04.45 |
| | is there a way to have frequent vmreclaims occur? | 18:05.01 |
| | in gs | 18:05.07 |
| henrys | do profiles need to be in gc memory? | 18:05.49 |
| mvrhel_laptop | no they are not in gc memory any longer | 18:06.09 |
| | hold on | 18:06.17 |
| | so this may not be an issue any longer | 18:06.32 |
| Robin_Watts | ray_laptop: ping ? | 18:06.46 |
| mvrhel_laptop | let me yank it out and run a cluster push | 18:06.52 |
| | see if anything explodes | 18:07.12 |
| henrys | okay. | 18:07.15 |
| tkamppeter | mvrhel_laptop, what did you want to ask me yesterday/today in the morning? | 18:21.58 |
| mvrhel_laptop | tkamppeter: I sent you an email. It was about the open printing meeting | 18:22.21 |
| ray_laptop | Robin_Watts: pong | 18:25.44 |
| tkamppeter | mvrhel_laptop, I replied. Your session should be on Wed, between 9am and noon. | 18:26.02 |
| mvrhel_laptop | ok. so you would like me to talk at that time? | 18:26.19 |
| Robin_Watts | ray_laptop: in gxclpath.h ... can I just reuse any obselete one? | 18:26.27 |
| ray_laptop | Robin_Watts: yes, but please grep for it to make sure it really is obsolete :-) | 18:27.02 |
| tkamppeter | mvrhel_laptop, yes. | 18:27.02 |
| Robin_Watts | (Specifically, I'm planning to reuse cmp_opv_htfill as cmd_opv_gapto | 18:27.14 |
| | ray_laptop: It's commented out, so presumably it's safe :) | 18:27.26 |
| ray_laptop | Robin_Watts: that group looks fine. | 18:30.06 |
| Robin_Watts | ray_laptop: I'm not going to bother with h and v variants. | 18:30.26 |
| ray_laptop | Robin_Watts: h and v variants ? | 18:31.11 |
| henrys | ray_laptop:I think Miles is going to stir a pot that doesn't need stirring right now, but hopefully I'm wrong. | 18:31.12 |
| ray_laptop | henrys: me too | 18:31.34 |
| Robin_Watts | yeah, equivalents to hlineto and vlineto. | 18:31.35 |
| | I will however have to somehow push changes to the pis->hpglfillmode bit through the clist. | 18:31.59 |
| ray_laptop | Robin_Watts: is gapto only used in one of the fill modes ? | 18:32.53 |
| Robin_Watts | Or will I. | 18:32.56 |
| | The hpglfillmode bit is only used during path construction. | 18:33.18 |
| | so actually, we should be OK I think. | 18:33.34 |
| ray_laptop | Robin_Watts: that's what I was thinking. | 18:33.35 |
| henrys | ray_laptop:I was thinking of something more gradual and subtle we or you could do in engineering - to request more work of them just a gradual increase in push back. | 18:37.48 |
| | s/subtle/subtle approach/ | 18:38.03 |
| ray_laptop | henrys: or we could just make them wait longer and longer ;-) | 18:39.48 |
| henrys | speak of the devil now they want Robin_Watts | 18:41.06 |
| Robin_Watts | Carrier Lost... | 18:42.06 |
| henrys | mvrhel_laptop:did the mouse trap break? | 18:42.22 |
| | mvrhel_laptop:stepping through the language setup stuff I really need to get started on reworking that. I'm glad I looked at the icc stuff now. | 18:43.35 |
| mvrhel_laptop | wtf. the build failed again | 18:43.36 |
| Robin_Watts | So, that's the text files. They aren't compressing the bitmaps (just copying them). Ain't much we can do to make that faster. | 18:43.38 |
| mvrhel_laptop | henrys: I don't understand | 18:44.08 |
| | why the build failed on the clusterpush | 18:44.17 |
| | why does this keep happening to me | 18:44.22 |
| Robin_Watts | Did they experiment with raising the bandheight so we 'flush' less often? I bet they didn't even try. | 18:44.25 |
| | mvrhel_laptop: Let me look. | 18:44.31 |
| henrys | mvrhel_laptop:were you able to figure out last time? | 18:44.37 |
| mvrhel_laptop | well, no it just started working | 18:44.46 |
| henrys | it was clear you didn't have a fresh pcl makefile from the error. | 18:44.59 |
| mvrhel_laptop | this time it looks different | 18:45.21 |
| | failed at language switch | 18:45.38 |
| | make[2]: *** No rule to make target `../gs/base/gSbitops.h', needed by `obj/zcolor.o'. Stop. | 18:45.52 |
| Robin_Watts | make[2]: *** No rule to make target `../gs/base/gsLibctx.h', needed by `obj/pccolor.o'. Stop. | 18:46.26 |
| henrys | Robin_Watts:shoot questions at them to do the foot work. We can't spin engineering hours doing ghostscript mind experiments . | 18:47.21 |
| mvrhel_laptop | not sure what to do here | 18:48.26 |
| Robin_Watts | mvrhel_laptop: Want to bet that feet has a dodgy bit in it's memory ? | 18:48.27 |
| henrys | you think a memory problem is causing a case shift? | 18:49.16 |
| Robin_Watts | That'd be my guess. | 18:49.35 |
| | Given that it compiled fine on the other nodes. | 18:50.03 |
| henrys | maybe.. | 18:50.10 |
| | take it offline and restart? | 18:50.53 |
| Robin_Watts | mvrhel_laptop: Do you want to do the honours ? | 18:51.24 |
| | (On the regression dashboard click 'enabled' to the right of feet, then resubmit your job) | 18:51.43 |
| mvrhel_laptop | ok | 18:52.08 |
| henrys | i'll send mail to marcos | 18:52.38 |
| mvrhel_laptop | it shows it is still enabled.... | 18:53.27 |
| | maybe it will update in a bit | 18:54.10 |
| | nope it is fetching the source | 18:54.24 |
| | should I abort | 18:54.27 |
| | Robin_Watts | 18:54.31 |
| ray_laptop | holy cow! over 5200 calls to 'make_font' on a single page. That doesn't seem right. | 18:55.00 |
| | hmm... it's getting invoked (from the interp) multiple times to print a single string :-( | 18:59.51 |
| Robin_Watts | mvrhel_laptop: Abort it. | 19:00.20 |
| | For some reason, the touch failed. Let me look into that. | 19:00.34 |
| mvrhel_laptop | ok aborted | 19:01.03 |
| Robin_Watts | Disabled now. | 19:02.24 |
| | (Essentially we need to touch feet.down in the cluster directory - for some reason my web thing has stopped working to do that. Either the cluster directory has stopped being world writable, or someone stopped the script having permission to do it.) | 19:03.10 |
| mvrhel_laptop | Robin_Watts: so I should push again? | 19:06.59 |
| Robin_Watts | yes, sorry. | 19:07.09 |
| mvrhel_laptop | no worries | 19:07.17 |
| | thanks for helping | 19:07.24 |
| Robin_Watts | np. | 19:07.54 |
| ray_laptop | Robin_Watts: thanks for amplifying my suggestion about increasing the BandHeight | 19:16.09 |
| Robin_Watts | ray_laptop: I hadn't seen your mail. | 19:16.55 |
| ray_laptop | Robin_Watts: it irritates me that now they are saying there is a performance problem with a slower processor. | 19:16.57 |
| | just use the faster CPU and STFU | 19:17.28 |
| Robin_Watts | I think they've gone to a FASTER processor. | 19:17.36 |
| | and the timings they gave us before were for the faster processor. | 19:17.51 |
| ray_laptop | well, with the faster processor, we _do_ beat the target | 19:18.21 |
| Robin_Watts | Indeed. | 19:18.27 |
| | But I think they want to beat it with the slower processor, so that the faster processor is gravy. | 19:18.44 |
| ray_laptop | that's why my response started as: I don't understand | 19:18.55 |
| Robin_Watts | yeah. | 19:19.06 |
| | 50 bands per page seems ludicrous. | 19:19.28 |
| ray_laptop | I'd have to make the change to how the tiles go into the clist to work around that issue | 19:20.09 |
| Robin_Watts | It's possible that the hotspot has moved and is elsewhere now. | 19:20.50 |
| | I haven't seen a profile since they changed to copy instead of compress. | 19:21.21 |
| | but they can damn well try the suggestion I made 2 weeks ago, before I waste more time on it. | 19:21.46 |
| ray_laptop | I have to go pick up my car. bbiaw. (it had to be repaired after the car parked next to it burned up and melted the passenger side plastic parts and "toasted" the paint). | 19:21.49 |
| Robin_Watts | ouch. | 19:22.00 |
| ray_laptop | Robin_Watts: Eric sent one | 19:22.05 |
| Robin_Watts | He did ? | 19:22.35 |
| ray_laptop | Yes, back on 2/20 | 19:23.08 |
| Robin_Watts | I have an email on 2/20 with timings, but not profiles | 19:23.38 |
| ray_laptop | he cc'ed support, but didn't include you directly | 19:23.39 |
| | Robin_Watts: oh, sorry -- misread your comment. | 19:23.59 |
| | bbiaw. | 19:24.41 |
| henrys | marcosw:just emailing you see above. | 19:29.48 |
| marcosw | alexcher_: are you around? | 19:29.52 |
| Robin_Watts | Bonkers clist code. | 19:30.38 |
| | henrys: you were telling marcosw about the suspected RAM problems ? | 19:31.02 |
| henrys | well I was going to send him email but now he's here. | 19:31.26 |
| marcosw | so feet is having trouble with mvrhel_laptop's clusterpush? | 19:31.45 |
| Robin_Watts | marcosw: Yes. | 19:31.52 |
| | The 2 suspicious error messages were: | 19:32.04 |
| | make[2]: *** No rule to make target `../gs/base/gsLibctx.h', needed by `obj/pccolor.o'. Stop. | 19:32.17 |
| | make[2]: *** No rule to make target `../gs/base/gSbitops.h', needed by `obj/zcolor.o'. Stop. | 19:32.29 |
| | That smells like 1 bit errors in the RAM to me. | 19:32.39 |
| marcosw | odd, feet is pretty much identical to four of the other cluster nodes (except for a slower cpu). | 19:32.49 |
| henrys | memtest86? | 19:33.37 |
| Robin_Watts | I have the clist version of the hpgl stuff working, it seems. | 19:35.57 |
| | but the clist code is bonkers :( | 19:36.03 |
| | switch(op>>4) { case (foo>>4)... then in each of those cases: switch(op). | 19:37.21 |
| | Why not just do switch(op) at the top level? | 19:37.30 |
| | Is there some wierd, but important architecture on which the compiler does a poor job of just switching on a byte ? | 19:38.19 |
| mvrhel_laptop | bbiaw | 19:44.21 |
| marcosw | henrys: I just opened a bug for the same customer who needed pdfinfo.ps to work with Portfolio PDF files. They now ask that -dFirstPage and -dLastPage be modified to handle Portfolio PDFs: http://bugs.ghostscript.com/show_bug.cgi?id=692886 | 19:52.07 |
| Robin_Watts | Do we not have a switch to set what entry in a portfolio PDF we use already ? | 19:52.43 |
| | Can they not select the portfolio PDF with that, and then select the pages using FirstPage/LastPage from that ? | 19:53.40 |
| | henrys: OK, so I have a commit ready to go with the hpgl path stuff. Do you want me to commit that on master, for you to do the PCL stuff? Or should it go on a branch? | 19:58.06 |
| marcosw | Robin_Watts: if we do it's not documented (or I couldn't find it in the documentation). | 19:58.06 |
| Robin_Watts | That would seem like an omission to me. Alexcher? | 19:58.33 |
| marcosw | I was going to ask alexcher_ but he doesn't appear to be on IRC. | 19:58.44 |
| henrys | Robin_Watts:master is fine. | 19:59.57 |
| | marcosw:sorry dealing with a customer | 20:00.18 |
| | I'm back | 20:00.22 |
| Robin_Watts | henrys: All yours then. I've changed it to be hpgl_path_mode rather than hpgl_fill_mode as that makes more sense. | 20:00.45 |
| marcosw | nothing urgent, just keeping you in the loop with customer 531 | 20:00.56 |
| | Robin_Watts: too bad about the silverstone schedule. They are having a leap day sale tomorrow. | 20:04.48 |
| Robin_Watts | OOh, that's worth knowing. | 20:07.25 |
| | Helen has announced she wants to come. | 20:07.35 |
| marcosw | Robin_Watts: you should talk Miles into sending you to Drupa. The Nürburing is only 60 miles away. | 20:11.24 |
| Robin_Watts | marcosw: Yes, but my insurance specifically prohibits me taking my car onto a track. And so do rental car agreements :( | 20:12.20 |
| henrys | marcosw: can you print from acrobat 9.0 to an hp? | 20:16.48 |
| marcosw | henrys: yes. | 20:17.34 |
| henrys | I just put a file in my home on casper which will not print to my 4600 | 20:17.59 |
| Robin_Watts | henrys: Which file? | 20:18.19 |
| henrys | maybe not enough printer memory | 20:18.21 |
| marcosw | 1N6BA0ED5CN312353.20120221-ACTIVEPDF.pdf? | 20:18.43 |
| henrys | there is a reason I didn't say that. | 20:19.01 |
| | but carry on. | 20:19.06 |
| marcosw | oops, didn't read the file name :-( | 20:19.14 |
| Robin_Watts | Works fine on my 5L. | 20:21.06 |
| marcosw | The P4015x printed it but the CP3505dn displayed an insufficient memory error message. | 20:21.19 |
| Robin_Watts | but I get lots of vertical lines in the top right sections. | 20:21.48 |
| henrys | there are no black stripes over the epa section? | 20:22.07 |
| Robin_Watts | Yes, lots of them. | 20:22.30 |
| marcosw | the entire EPA section is black (with a bit of white text) | 20:22.47 |
| henrys | Robin_Watts:so it looks like the scan I just uploaded the file with the latest date. | 20:23.39 |
| Robin_Watts | IF I print it with the 'scale to fit' disabled, it comes out with no vertical lines. | 20:24.58 |
| henrys | Robin_Watts:I don't suppose you have preview handy and can try printing it from there? | 20:25.18 |
| | marcosw:yikes that doesn't sound good | 20:25.42 |
| | marcosw:works okay for me if printed from preview. | 20:26.09 |
| marcosw | It certainly doesn't look like it does on the screen. | 20:26.19 |
| henrys | marcosw:probably worth doing an adobe bug for. | 20:28.22 |
| Robin_Watts | henrys: Yes, my 5L output looks exactly like your scan. | 20:29.14 |
| henrys | okay thanks | 20:30.01 |
| | it sounds like the color printer ouput is messed up in some other manner. | 20:30.17 |
| | ah scale to fit. | 20:31.04 |
| | but it's ledger paper - is it clipped? | 20:31.48 |
| Robin_Watts | The 5L has 1Meg base memory, and I have another 4 in there. | 20:31.52 |
| | Without scale to fit, I get just the centre section printed. | 20:32.17 |
| henrys | right | 20:32.33 |
| Robin_Watts | so, yes, it's clipped. but it's enough to see that there aren't lines in the EPA section. | 20:32.39 |
| | You want me to try from Apple Preview ? | 20:32.52 |
| henrys | if it is handy that would be useful I really should get my mono printer working again. | 20:33.15 |
| marcosw | Robin_Watts: I'm having trouble finding car rental agreements for cars rented in Germany, but I'm pretty sure the ones in the US do not prohibit you from driving on a racetrack. They do prohibit racing but as long as the you don't time your laps and compare them to anyone else you aren't racing :-) | 20:35.32 |
| Robin_Watts | ok, so I need to set up a printer driver on mac os x :) | 20:36.02 |
| henrys | Robin_Watts:don't fool with it. | 20:36.30 |
| Robin_Watts | no, I should do this anyway. | 20:37.00 |
| henrys | marcosw:a print from preview works on color? | 20:38.13 |
| | I guess it would mine did fine. | 20:38.29 |
| marcosw | hold on, I'll check | 20:38.31 |
| | yes, the printout from preview worked fine. I'm going to try Adobe 10. | 20:40.02 |
| Robin_Watts | Preview prints it perfectly (scaled, not clipped, no black lines) | 20:40.17 |
| henrys | yup that's what I thought. | 20:42.40 |
| marcosw | the printout from Acrobat 10 is identical, the EPA section is black. | 20:42.42 |
| | oddly enough the color printer prints nothing and does not display an error message. | 20:43.03 |
| henrys | that's what my 4600 does. | 20:43.23 |
| | it is 11x17 maybe memory overflow. | 20:43.51 |
| | Robin_Watts:I missed something in the review ... we don't know if it will be an HPGL/2 style path when the path is created. We only know upon rendering it when gs_fill is called. | 21:03.42 |
| | so each path must store enough state to be able to render both ways. | 21:06.03 |
| | oh no mvrhel_laptop's job is aborting again. | 21:09.19 |
| mvrhel_laptop | huh | 21:11.11 |
| | i give up | 21:15.01 |
| henrys | it's been a bad day all around. let me look at the the macpro. | 21:16.18 |
| Robin_Watts | henrys: dunno if you saw that... | 21:19.44 |
| henrys | saw what? | 21:20.22 |
| | I still see those stupid message about can't stat the wts files but I see his makefile is up to date. | 21:20.52 |
| tkamppeter | Is the PDF output of "pdfwrite" (GS 9.05) supposed to be searchable? | 21:22.06 |
| Robin_Watts | My discussion about the hpgl thing ? | 21:22.33 |
| ray_laptop | tkamppeter: yes | 21:22.36 |
| henrys | Robin_Watts:oh did I drop off of IRC | 21:22.54 |
| ray_laptop | tkamppeter: don't tell me we broke that ! | 21:22.55 |
| marcosw | the missing wts files messages are a read herring, they can be ignored. | 21:23.02 |
| Robin_Watts | henrys: we had a netsplit. | 21:23.05 |
| henrys | I'll go to the irclogs | 21:23.17 |
| tkamppeter | ray_laptop, see https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/942866 | 21:23.21 |
| Robin_Watts | henrys: ghostbot went with you. | 21:23.34 |
| henrys | marcosw are you going to look at the clusters and mvrhel_laptop's job? | 21:23.36 |
| Robin_Watts | oh... | 21:23.38 |
| | Currently, how do you construct paths? | 21:23.41 |
| | Do you call gs_lineto etc? | 21:23.44 |
| marcosw | yeah, doing it now. | 21:23.46 |
| Robin_Watts | Looks like it. | 21:23.48 |
| tkamppeter | ray_laptop, cups-pdf uses Ghostscript to turn PostScript input into PDF, using the command line | 21:23.49 |
| Robin_Watts | You could call gs_gapto instead of gs_moveto in the appropriate cases. | 21:23.53 |
| henrys | Robin_Watts:yes | 21:23.53 |
| Robin_Watts | And then I could do an 'in-place' conversion of a path to replace gaptos with movetos in the postscript-fill-style case | 21:24.07 |
| ray_laptop | mvrhel_laptop: chris Murphy just doesn't get it. I'm surprised that he's trying to play the Rosenthal 'spec' card. Adobe is one of the worst offenders with accepting broken PDF's. | 21:24.21 |
| | mvrhel_laptop: you may want to point out that ICCBased colors have a /Alternate colorspace just so viewers can ignore ICC profiles in a document. | 21:25.02 |
| henrys | Robin_Watts:okay so if there is no current subpath use moveto else gapto? Is that the setup? | 21:26.27 |
| Robin_Watts | yes. | 21:26.35 |
| | actually... | 21:26.50 |
| | we could just keep everything exactly as it is. | 21:26.57 |
| | You'd go into hpgl path mode to start with. | 21:27.09 |
| ray_laptop | mvrhel_laptop: and we all know how likely it is that PDF creators will fix their PDF creation tools. All we ever hear is "it looks OK on the screen with Adobe Acrobat -- it's your problem." | 21:27.14 |
| Robin_Watts | Then you'd moveto/lineto as now. | 21:27.16 |
| henrys | That seems a bit cleaner to me. | 21:27.47 |
| Robin_Watts | And in the case where you want postscript style filling, you'd call gs_hpgl_to_ps_path(path) before you filled it. | 21:27.49 |
| henrys | I don't think I ever want to fill postscript style in gl/2 - just stroke. | 21:28.53 |
| Robin_Watts | In the test file I sent, is the stroking correct ? | 21:29.46 |
| ray_laptop | Robin_Watts: on cust 532, I am going to send them a "fix" to try that ignores the BandHeight setting and uses 1024. :-) | 21:30.11 |
| Robin_Watts | At the moment in HPGL mode I treat gaptos as unstroked. | 21:30.17 |
| ray_laptop | Robin_Watts: they won't even be able to tell. For a while the machine was printing in page mode because they didn't have the -dMaxBitmap=10000 in the right place in the arguments list and they didn't even know it. | 21:30.37 |
| henrys | Robin_Watts:the fill is correct with your new code. | 21:30.45 |
| tkamppeter | ray_laptop, gs -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s | 21:30.45 |
| Robin_Watts | henrys: Right, but are strokes? | 21:31.00 |
| ray_laptop | tkamppeter: you have a bunch of %s arguments in there. What CompatibilityLevel are you using (and what input file). Please open a bug with that info | 21:31.51 |
| henrys | no something is severely broken and I assumed it was the stroking lines drawn all over the place. | 21:32.03 |
| Robin_Watts | (henrys: Did I have stroke or fill in the test.ps?) | 21:32.25 |
| | I'm being called for dinner. bbiab. | 21:32.56 |
| henrys | okay no hurry | 21:33.03 |
| | you had stroke I tested the original hpgl/2 | 21:33.23 |
| | after calling your new operator. | 21:33.35 |
| marcosw | mvrhel_laptop (and others): it looks like some (most) of the cluster nodes had trouble reaching casper, I'm pretty sure the cluster would have recovered eventually, but I just restarted it manually. | 21:34.17 |
| henrys | marcosw: it does seem to happen to mvrhel_laptop frequently. | 21:35.16 |
| | bad luck? | 21:35.26 |
| ray_laptop | Robin_Watts: henrys: strong response to cust 532 telling them "look, if you want us to help, you have to do what we tell you to do" | 21:50.52 |
| | henrys: sort of a lead in to "you will have to upgrade to 9.0x" ;-) | 21:52.14 |
| henrys | ray_laptop:hopefully that will help. | 21:59.45 |
| mvrhel_laptop | henrys: so should a push again | 22:05.43 |
| henrys | no marcosw said he restarted it and your job is sitting there. | 22:07.02 |
| | mvrhel_laptop:now it seems to be limping along on the nodes that are up. | 22:07.49 |
| | it could be some vm hell is unleashed as a consequence of your change. | 22:08.33 |
| | bringing the tests down but that seems unlikely | 22:08.55 |
| Robin_Watts | henrys: OK, so 0 0 moveto 100 0 moveto 100 100 lineto 0 100 lineto closepath stroke - what does that give under HPGL ? | 22:10.39 |
| henrys | hang on. | 22:12.52 |
| Robin_Watts | Under postscript stroking rules, we'll see a triangle. | 22:14.23 |
| | Under HPGL I'd expect to see either a square or 3 sides of a square. | 22:14.56 |
| henrys | 3 sides of a square with your operator on 4 without but there is also a stray line that runs up the page with the operator on. | 22:15.58 |
| Robin_Watts | Right. I don't want to know what my code does :) | 22:16.33 |
| | I know what my code does (I hope!) | 22:16.48 |
| | I want to know what a real PCL printer does. | 22:16.58 |
| henrys | that draws a square. | 22:17.18 |
| Robin_Watts | Ah, well, in that case, it's easy. | 22:17.39 |
| henrys | but there is no closepath - you have to do the final lineto (pen down) | 22:17.54 |
| | do you want me to send you a gl/2 file that does that? | 22:18.33 |
| Robin_Watts | So, if what you say is true, how does a successive moveto differ in any way from a lineto ? | 22:18.46 |
| | i.e. how is: 0 0 moveto 100 0 moveto 100 100 lineto any different from: 0 0 moveto 100 0 lineto 100 100 lineto ? | 22:19.31 |
| henrys | sorry in polygon mode there is an implicit closepath. | 22:19.59 |
| | so any fill has a closepath. | 22:20.22 |
| Robin_Watts | ok, but ignoring that... | 22:21.02 |
| henrys | when filling the second moveto is treated as a lineto when stroking the second moveto is a moveto and presumably has no effect on the output. | 22:22.03 |
| Robin_Watts | That's not what you said a moment ago. | 22:22.47 |
| henrys | or I should say when stroking the first moveto has no effect on the output. | 22:22.54 |
| Robin_Watts | And that's not consistent with what you said either. | 22:23.15 |
| | 0 0 moveto 100 0 moveto 100 100 lineto 0 100 lineto closepath stroke - what does that give under HPGL ? | 22:23.29 |
| | I'm asking about STROKING there. | 22:23.38 |
| | FILLING that path will give me a square. | 22:23.46 |
| | I'd hope that stroking it would only stroke 3 sides of the square. | 22:24.11 |
| henrys | oh start over I added another point to your path. | 22:24.11 |
| | stroking it creates a triangle | 22:27.31 |
| Robin_Watts | i.e. the initial 0 0 moveto has no effect on the results of stroking it? | 22:28.19 |
| henrys | correct | 22:28.38 |
| Robin_Watts | Wow, that's bonkers. | 22:28.56 |
| henrys | there is not closepath though I'm adding pen down 1024,0 to the end to simulate your closepath. | 22:29.59 |
| | sorry i change 100 to 1024 | 22:30.19 |
| Robin_Watts | OK, so give me the path you're feeding it ? | 22:30.35 |
| henrys | PA0,0;PU1024,0;PD1024,1024;PD0,1024;PD1024,0 | 22:31.51 |
| Robin_Watts | Ah, so there is no closepath in PCL, that makes sense. | 22:32.13 |
| | Sorry. | 22:32.14 |
| | That's why it's a triangle not a square. | 22:32.24 |
| | The way I think about is that if there was a closepath, it would go back to 0,0. | 22:33.25 |
| | because that's the start of the subpath as far as filling is concerned, right? | 22:33.49 |
| henrys | I think if I construct the path as a polygon in polygon mode it would be interpreted as you say. | 22:33.57 |
| Robin_Watts | (Under HPGL rules, if I filled my path, I'd get a square, right?) | 22:34.20 |
| henrys | I should really test that now. | 22:34.21 |
| | I would hope so. | 22:34.41 |
| | but I wanted to make sure. | 22:34.49 |
| | yes a square with a polygon mode fill | 22:36.57 |
| Robin_Watts | So... I think we should be OK for PCL to go into hpglpathmode when it starts up, then always fill/stroke in that way. | 22:37.30 |
| henrys | yes that will get us close. I'm willing to be I'm overlooking something though. | 22:38.28 |
| | the clusters will tell. | 22:38.36 |
| Robin_Watts | yeah. | 22:38.42 |
| henrys | s/be/bet | 22:38.44 |
| Robin_Watts | I'm surprised that we haven't been seeing more problems if this is something we've always been getting wrong. | 22:39.07 |
| | I look forward to seeing the results from the clusters. | 22:39.37 |
| | I'm being called names - I'd better go watch telly with the missus. | 22:39.52 |
| | night. | 22:39.55 |
| henrys | oh you say turn it on now? | 22:40.04 |
| | okay see you tomorrow | 22:40.20 |
| | mvrhel_laptop:sent mail to marcos again... | 22:55.53 |
| mvrhel_laptop | maybe I should try a clean push | 23:40.47 |
| | Forward 1 day (to 2012/02/29)>>> | |
IRC Logs