| | <<<Back 1 day (to 2011/09/05) | 2011/09/06 |
| kens | chrisl, just FYI I found 2 more cases in our test suite where ps2write emits a MM font as a type 1, and which caused a seg fault. All are fixed with your latest patch. | 09:02.25 |
| chrisl | kens: Well, that's something. How does pdfwrite handle these? | 09:03.37 |
| kens | That's an interesting question. I haven't checked the content yet, but the PDF files work. | 09:04.39 |
| chrisl | Hmm, I'd expect the same error to occur - strange...... | 09:05.23 |
| kens | Yes, that's waht I thought.... | 09:05.33 |
| | Just making a PDF file to look at. | 09:05.42 |
| | Just checked, both GS and Acrobat are happy with the PDF file, now to look inside it. | 09:06.59 |
| | I don't suppose you remember teh fontn name ? | 09:07.56 |
| | Oh, probably AdobeSerifMM | 09:08.18 |
| chrisl | Ah, couldn't remember if it was Sans or Serif - but yes | 09:08.37 |
| kens | Looks like pdfwrite emits it as a CFF font. | 09:08.41 |
| | Many times. | 09:09.04 |
| chrisl | Several instances? | 09:09.25 |
| kens | Only if the file has a *lot* of different fonts. | 09:09.37 |
| | Looks like 80 fonts, each containing one glyph ;-) | 09:10.31 |
| chrisl | Hmm, suboptimal - but not wrong..... | 09:10.56 |
| kens | Indeed. I'm guessing the conversion to CFF strips out the MM instructions, which is why it works. | 09:11.16 |
| chrisl | It would have to. Maybe it's that conversion that causes it to emit the font(s) in the way it does | 09:12.19 |
| kens | I'm assuming so, yes. | 09:12.28 |
| | So a putative ps3write could do the same :-) | 09:12.54 |
| chrisl | Yes. I guess a hacky solution might to have ps2write convert to CFF and then back to Type 1 - ick..... | 09:13.31 |
| kens | Definitely. | 09:13.43 |
| | But if a CFF conversion can work, then it ought to be possible to do a clean type 1 version too. | 09:14.03 |
| chrisl | Yeh, it's probably a fairly simple operation just to strip the relevant op codes from the char strings | 09:15.08 |
| kens | I hope so, but I'm not certain, I can't recall what the operations are for :-) | 09:15.33 |
| | fetching coffee, need fuel for this one. | 09:16.01 |
| Robin_Watts | Gah. | 09:27.01 |
| | The win64 stuff in the makefile allows you to specify whether you want to build a win64 thing or not. | 09:27.39 |
| | but nothing detects the version you are building on. | 09:27.50 |
| | Anyone got any insight into how to do that ? | 09:28.07 |
| kens | off the top of my head, no.... | 09:28.33 |
| chrisl | Robin_Watts: you have to tell it: BUILDSYSTEM=32/64 | 09:34.22 |
| kens | no WIN64 define present for 64-bit builds ? | 09:35.10 |
| chrisl | WIN64 tells the makefile *what* to build, BUILDSYSTEM tells it what you're building on | 09:35.58 |
| kens | OK. | 09:36.08 |
| | Could ask Windows I think, but requires a C call I suspect | 09:36.53 |
| chrisl | Yes, there is no standard way of find the word size from the Window command line - I looked, and looked :-( | 09:37.28 |
| | It's quite a common question, as it turns out | 09:39.55 |
| kens | chrisl on Stack Overflow if the environment variabel 'ProgramW6432' is non-empty then its 64-bit Windows. | 09:40.00 |
| | Turns out to be WIndows 7 only though | 09:40.44 |
| chrisl | Hmm, strange that Microsoft's developers wouldn't know that! | 09:40.45 |
| | Ah, that's not really much use just now :-( | 09:41.12 |
| | Robin_Watts: I was wondering if, rather than (or as well as?) being able to tell genarch to use a predefined arch.h, if it wouldn't be a good idea to allow command line option overrides for each the settings it creates. | 09:42.36 |
| kens | Heuristically you can check for '\Program Files (x86)' which is present in 64-bit installs | 09:43.03 |
| chrisl | I don't really have a problem using the BUILDSYSTEM setting. | 09:44.44 |
| | kens: Vista64 has "ProgramFiles(x86)" environment variable, does Vista32? | 09:48.05 |
| Robin_Watts | chrisl: That would be a much larger rework than I've done. | 09:49.52 |
| | At the moment you just add TARGET_ARCH_FILE=./base/arch-win32-msvc.h onto the nmake invocation. | 09:50.29 |
| | (sorry, the make invocation) | 09:50.51 |
| | nmake picks a default TARGET_ARCH_FILE based on the WIN64 setting. | 09:51.06 |
| chrisl | Robin_Watts: So, are we going to start shipping these? | 09:51.32 |
| Robin_Watts | chrisl: Yes, just give me a bit to finish testing what I have here. | 09:51.49 |
| kens | chrisl no no (x86) version on 32-bit Vista | 09:52.28 |
| chrisl | Robin_Watts: OKay, could we maybe not put them in "base" then? | 09:52.57 |
| | kens: okay, so that would be an option, if we ever felt so inclined - trust M$ to make it different...... | 09:53.34 |
| kens | Yep :-) | 09:54.48 |
| Robin_Watts | chrisl: where would you prefer them? | 09:57.07 |
| | Needs to be somewhere in gs, so it's available to all builds (pcl, xps etc) | 09:57.35 |
| | The only existing directory that is suitable is base. | 09:58.21 |
| | Creating a new dir is possible, but that would mean a whole new variable through all the makefiles etc. | 09:58.46 |
| chrisl | Robin_Watts: I was thinking maybe we need like an "arch" or "platforms" directory, we could then put all viable cross compile arch.h prototypes in there | 09:59.15 |
| | Hmm, yes, new variable makes it a bit of pain :-( | 09:59.39 |
| Robin_Watts | I'd personally favour sticking them in base for now, and we can move them later as part of a larger rework if required. | 10:00.21 |
| | bbiab. | 10:00.25 |
| chrisl | It's just it would be good to keep all the pre-defined arch.h files we could (privacy concerns permitting) in there, and I don't like the idea of 'base' being a "dumping ground" for stuff like that. | 10:00.55 |
| | BTW, I don't see arch.h getting recreated that often, so I think the dependencies for it are (nearly?) correct | 10:02.23 |
| Robin_Watts | Maybe. It was rays comment, I think. | 10:16.06 |
| | There were moves afoot (before I joined), I believe to split the source up into something more managable. | 10:16.48 |
| | base was merely the first stage. | 10:17.02 |
| kens | It started, that's why we have a base and psi | 10:17.03 |
| chrisl | I just mentioned the dependencies while I remembered, it wasn't aimed at your current stuff | 10:17.37 |
| Robin_Watts | So, favoured place for the arch files now? (Ignoring complexity, what would you like to see the directory called) | 10:19.03 |
| | arch? platform? config? | 10:19.28 |
| | I'd favour arch. | 10:20.03 |
| chrisl | Me, too. It fits with the file name. | 10:20.18 |
| Robin_Watts | And I'd personally favour <CPUtype>-<OS>-<toolset>.h as the name. | 10:21.51 |
| | so x86-windows-msvc.h and x64-windows-msvc.h | 10:22.05 |
| chrisl | Hmm, I'd prefer <OS>-<CPUtype>-<toolset>.h - but not enough to argue about it! | 10:22.57 |
| Robin_Watts | chrisl: There is a vague standard for this, right? I wonder what that is... | 10:23.40 |
| | LLVM uses architecture vendor-os | 10:25.10 |
| chrisl | Robin_Watts: I'm not sure, it's just in the directory listing, *I* would prefer all the Windows variants listed together, all the Linux variants listed together, and so on | 10:25.56 |
| Robin_Watts | That's a relatively compelling argument :) | 10:29.22 |
| chrisl | I do make them occasionally.... ;-) | 10:30.01 |
| Robin_Watts | tor8: For pickup at the international terminal on the shuttle bus, you need to call the hotel, so make sure you have the hotel number with you. | 11:02.48 |
| kens | hmm, thanks for that Robin_Watts. I hope one of us will remember ;-) | 11:03.15 |
| Robin_Watts | I've put it in my phone, but belt and braces etc... | 11:03.32 |
| | That helpful nugget is hidden away on the website a bit. | 11:04.02 |
| kens | I'm glad you found it! | 11:04.13 |
| Robin_Watts | Oh, I *hate* nmake. | 11:04.42 |
| | I've changed genarch so it only writes out the new file if it's different from the old file. | 11:05.15 |
| | But if you use nmake -d so you can see all the timestamps that it's basing the build on, it assumes that the timestamp has been updated. | 11:06.24 |
| | So, time to back that change out :( | 11:07.13 |
| tor8 | Robin_Watts: oh bother | 11:08.28 |
| Robin_Watts | tor8: Do you have a calling plan that works in the states? | 11:10.41 |
| tor8 | a ridiculously expensive one, that only seems to work with AT&T | 11:11.57 |
| Robin_Watts | There may be a courtesy phone, but it's not mentioned on the site. | 11:12.20 |
| | Or a taxi is $10 to $12 apparently. | 11:12.41 |
| | Oh, but you're like the queen and never carry cash, right? :) | 11:13.01 |
| tor8 | quite :) | 11:13.18 |
| | I can make exceptions, but it's such a hassle :) | 11:13.48 |
| | Robin_Watts: site says int'l travellers use the courtesy phone in the terminal. | 11:15.44 |
| | I remember another time (was it chicago or washington?) when the shuttle bus only stopped by the domestic terminal unless you rang | 11:16.24 |
| | sometimes I wonder who the real culprit is when you see pdf files generated by cairo, that use 7 nested xobjects, two of which are tiling patterns, to draw an image. | 11:22.44 |
| kens | cairo :-) | 11:25.00 |
| tor8 | I've got a ridiculous file. the bboxes for some xobjects are in the 22000x11000 range. takes forever to render when you do the "hey let's render one tile to a bitmap and copy that so it'll be faster"... | 11:26.52 |
| Robin_Watts | chrisl: OK, that's my fiddlings committed. All tests out for me, but sods law says something will have gone wrong. | 12:26.52 |
| chrisl | Robin_Watts: thanks. I'll try it out in a bit | 12:36.04 |
| kens | chrisl I've been through the pdfwrite/ps2write code and there is no provision at all for converting a MM font. It just copeis the CharStrings data directly from each glyph thet's embedded. To deal with this I'm going to have to do yet another type 1 font interpreter that can discard MM instructions. | 12:58.59 |
| | However, if I do that, I presume the instance of the font won't be correct. | 12:59.19 |
| chrisl | kens: it shouldn't be any more wrong than the CFF version that ends up in the PDF - unless the Type 1 to CFF converter does something "clever" | 13:10.46 |
| kens | No, I think its pretty simplistic. | 13:14.22 |
| | I think I can detect a MM font by looking for WeightVector, which gives me the number of designs. With that I know how many elemnents are given to each OtherSubr, and that means I can simply elide the OtherSubr calls. I think that should make it all work. | 13:15.13 |
| | I think I will walk through the type 1 to CFF converter just to see what it does though. | 13:15.52 |
| chrisl | It's probably easier than making ps2write handle MM fonts, and preserve the settings use to create an instance! | 13:17.12 |
| kens | I did look into that, but MM fonts aren't in basic level 2 | 13:17.32 |
| | They must have been added later | 13:17.41 |
| chrisl | Hmmm, I thought Adobe's ones were supposed to work, because they include makeblendedfont implemented in Postcript - but, of course, with MM specific things in the charstrings, probably not..... | 13:20.30 |
| kens | The only MM-specifics in the CharStrings are calls to CallOtherSubr in the tange 14-18 whch are the 'MM' othersubrs. | 13:21.14 |
| | range | 13:21.24 |
| chrisl | I'm rather (pleasantly) surprised that freetype doesn't just ignore the error. | 13:23.04 |
| kens | It may be taht we simply don't emit enough 'OtherSubrs' entries that causes it to complain. | 13:23.28 |
| | It may be that supplying empty procedures would make everyone happy. | 13:23.41 |
| | Interesting, we write the font with a Subtype of MMType1 | 13:25.13 |
| | (Its OK because opdfread can handle that) | 13:25.30 |
| chrisl | No it has a specific error case for it "unexpected multiple masters operator" | 13:25.59 |
| kens | There are no MM operators, according to the MM spec. | 13:26.14 |
| | Just specific OtherSubrs | 13:26.23 |
| chrisl | Yeh, it means OtherSubrs call | 13:27.20 |
| kens | :-) | 13:27.25 |
| | Hmm, the type 1 font writer doesn't emit any OtherSubrs at all. | 13:36.42 |
| | chrisl how does FreeType recognise a MM font ? THis one has a WeightVector, but none of the other required entries. | 13:37.31 |
| | The ps2write output that is | 13:37.38 |
| | If I was to emit 18 dummy entries in OtherSubrs, woudl FT be happy with it ? | 13:38.12 |
| chrisl | I'm not sure: the error is trigger by trying to call an OtherSubr in the MM range when there is no "blend" entry in the decoder structure - do you want me to track where that comes from? (NOTE: the AFS code errored, too, IIRC). | 13:39.58 |
| kens | I'm guesing the 'blend' entry is the missing $Blend procedure. | 13:40.22 |
| chrisl | Very likely | 13:40.38 |
| kens | Which means I can't just emit the OtherSubrs, I'll have to strip them. | 13:40.43 |
| | Though oddly the type 2 converter doesn't seem to do that. | 13:40.58 |
| | But I'm not sure I want to worry about it. | 13:41.09 |
| chrisl | As I say, if you want me to track where "->blend" comes from, let me know - back in a sec, need to feed the cat....... | 13:43.18 |
| kens | Nah, I'll do it, just hoping for an easy solution | 13:43.34 |
| MAPI__ | hi | 14:20.31 |
| Robin_Watts | MAPI_: Hi. | 14:23.49 |
| MAPI__ | hello, | 14:24.24 |
| | I need to print with ghostscipt, epson stylus photo printers. | 14:24.24 |
| | I should have the ability to print multiple times on the same line before the table to move y. | 14:24.24 |
| | To get a larger amount of ink as possible, because printing on textiles. | 14:24.24 |
| | is it possible? | 14:24.25 |
| Robin_Watts | MAPI_: To do that you'd need to alter the epson stylus device. | 14:24.52 |
| kens | All things are possible, how much work do you want to do ? | 14:24.53 |
| | THis question was sent to support by the way | 14:25.04 |
| Robin_Watts | In the grand scheme of things, that doesn't sound like a huge change for someone sufficiently motivated. | 14:25.22 |
| | (i.e. all the work is in the device, and doesn't involve fiddling with the innards of gs) | 14:25.43 |
| MAPI__ | you have in mind the multi-pass print EK study, as it does? | 14:26.50 |
| Robin_Watts | but (I strongly suspect) it's not something that you'll find someone here will do for, as a) we don't have such a printer, and b) it doesn't generally enhance gs for the wider world. | 14:26.51 |
| | All this could change by you becoming a customer of course :) | 14:27.11 |
| | MAPI_: Sorry, I haven't a clue what a multi-pass print EK study is. | 14:27.43 |
| MAPI__ | Sorry, EK Print Studio | 14:28.18 |
| | is a RIP for textile printing | 14:28.40 |
| Robin_Watts | Ah, right, so there is a RIP out there that does this already. | 14:29.04 |
| | That doesn't change anything I've said, I believe. | 14:29.15 |
| MAPI__ | What is in a file .ppd -dupWeaveXPasses? | 14:33.00 |
| kens | Sounds liek something from CUPS | 14:33.35 |
| MAPI__ | no, are in .PDD file the gs | 14:35.20 |
| kens | I have no idea what you mean there. | 14:35.48 |
| MAPI__ | but you are here to pull the tails of elephants? | 14:36.07 |
| Robin_Watts | Mr Google suggests it's a flag to the epson stylus color device. | 14:36.19 |
| kens | Even if the file has a reference to Ghostscript that has nothing to do with whether it relates to CUPS. | 14:36.20 |
| | And no, I'm not hre to pull the tails of elephants | 14:36.43 |
| Robin_Watts | Hmm. What's a .upp file ? | 14:36.51 |
| kens | I thought that was a Windows spool file of some sort. | 14:37.07 |
| Robin_Watts | Looks like a filter specifier for cups. | 14:37.22 |
| | oh, it's a uniprint thing. | 14:37.34 |
| kens | So, back to CUPS again, as I said | 14:37.35 |
| | UniPrint, that's the thing. | 14:37.41 |
| Robin_Watts | Is UniPrint cups ? | 14:37.55 |
| kens | No, but I think CUPS can use the UniPrint driver. | 14:38.08 |
| MAPI__ | yes, is a uniprint file | 14:38.16 |
| Robin_Watts | right. So -dupWeaveXPasses is some parameter or other to the uniprint device in gs. | 14:38.46 |
| MAPI__ | but changing the files. upp, you can not succeed? | 14:39.35 |
| Robin_Watts | I am unfamiliar with any expression about "pulling the tails of elephants". | 14:39.38 |
| kens | yes, its declared in gdevupd.c | 14:39.41 |
| Robin_Watts | MAPI_: Not a clue, I've never used uniprint. | 14:39.49 |
| kens | Pulling the tails of elephants sounds like a dangerous activity to me. | 14:40.55 |
| MAPI__ | There is a driver for the Epson Stylus Photo R1900? in gs | 14:41.43 |
| kens | Not that I'm aware of. | 14:42.09 |
| MAPI__ | for a epson stylus photo in general | 14:42.46 |
| kens | There is a file called 'iupp-How-to-be' ni gs/contrib/epson740 which talks about weaving. | 14:43.07 |
| chrisl | uniprint is listed as being decprecated - not sure how accurate that is (doc/Deprecated.htm) | 14:44.06 |
| kens | in any event MAPI__ the simple answer seems to be that Ghostscript does not currently do what you want. SO there is no simple 'use this command and it will work' that we can give you. | 14:45.16 |
| | You will need to do significant development work yourself, or pay someone to do it, if you want this functionality. | 14:45.50 |
| chrisl | Robin_Watts: the Ghostscript "nsis" nmake target doesn't seem to work now - I'm not sure if that relates to your changes | 14:46.05 |
| Robin_Watts | chrisl: Oh. | 14:46.28 |
| | I've never used that :( | 14:46.35 |
| chrisl | It's kind of important..... | 14:47.04 |
| Robin_Watts | That would mean building outside the solution. | 14:47.08 |
| | What do I need to install to be able to use it ? | 14:47.17 |
| chrisl | Leave it with me a bit, hopefully it's not difficult to resolve. I suspect it would work for you anyway - looking at the error it would probably only go wrong on a 64 bit host. | 14:48.23 |
| MAPI__ | thank you anyway, do not know anyone that can help us? | 14:50.01 |
| kens | MAPI__ Its not really our area of expertise, we're more used to dealing wiht paper or with electronic formats I'm afraid. | 14:50.36 |
| Robin_Watts | MAPI__: It sounds like you want to speak to the people responsible for the uniprint device. | 14:51.00 |
| | You can probably find their addresses in the source code. | 14:51.11 |
| | Failing that, you may want to talk to the authors of cups, as they are more plugged into this kind of thing. | 14:51.33 |
| | tkampeter is often here, and he may be able to point you in the right direction. | 14:51.54 |
| chrisl | Robin_Watts: false alarm, I think - I mis-typed an option, sorry! | 14:52.02 |
| Robin_Watts | Ah! :) | 14:52.19 |
| kens | The last pdate to the UniPrint device was 11 years ago. | 14:52.59 |
| chrisl | Well, as I said, it is listed a being deprecated | 14:53.24 |
| Robin_Watts | kens: So clearly, it's perfect and no bugs have been found in that time :) | 14:53.26 |
| kens | :-) | 14:53.31 |
| | I was merely speculating that its unlikely that the authors would be at the same mail address. | 14:53.52 |
| Robin_Watts | kens: My email address hasn't changed in longer than that. | 14:54.11 |
| chrisl | Robin_Watts: I'm just rerunning the nsis build, but the debug and release targets worked fine, so I don't anticipate a problem | 14:54.19 |
| MAPI__ | bye bye | 14:54.47 |
| kens | Robin_Watts : Agreed, nor has my personal address, but the ones in the driver are (eg) .co.nz. My work email address has changed 3 times in that period (I think, maybe more) | 14:55.39 |
| Robin_Watts | My personal address is a .co.uk. | 14:55.59 |
| kens | All things are possible. | 14:56.08 |
| chrisl | Hmm, my new desks were damaged in transit - had to return them (refuse delivery). What a pain :-( | 14:56.22 |
| kens | I'm not saying its not worth trying | 14:56.25 |
| Robin_Watts | My sole point is that it's still worth a try. | 14:56.30 |
| | chrisl: Oh, hateful. | 14:56.36 |
| kens | desks plural ? :-O | 14:56.42 |
| chrisl | Yes, I am *so* untidy, I need two desks to hold the mess..... ;-) | 14:57.22 |
| Robin_Watts | I custom built a desk around 2 walls of my office - much more space efficient. I can fit WAY more mess in now. | 14:58.14 |
| kens | I have htat solution also. | 14:58.25 |
| | My desk includes a min race-track | 14:58.34 |
| | mini | 14:58.37 |
| Robin_Watts | Leyland or BMW ? | 14:58.49 |
| kens | Sclatectix clone | 14:59.05 |
| | typing as shameful as ever.... | 14:59.43 |
| | Scalectrix xlone with 2 mini's | 14:59.53 |
| chrisl | It seemed an unnecessary complication (not to mention taxing of my woodworking skills!) to custom build a desk, when two identical desks at right-angles gives me very nearly exactly what I need. | 15:00.01 |
| kens | Old fashioned leyland ones | 15:00.03 |
| chrisl | Cool :-) | 15:00.19 |
| | How many hours do you spend playing with that, and humming "we are the self preservation society"? ;-) | 15:01.11 |
| kens | :-) | 15:01.22 |
| | Only when I need a break. Sometimes I fly the helicopter instead. | 15:01.34 |
| chrisl | My helicopter is rather sorry for itself after an unscheduled wall related incident....... | 15:03.00 |
| | Robin_Watts: nsis builds also worked fine :-) | 15:03.24 |
| kens | will remember not to let chrisl fly | 15:03.29 |
| chrisl | Probably wise | 15:04.08 |
| henrys | I think we decided not to have a meeting but I'll be around during the regular meeting time. | 15:49.58 |
| kens | If we're not meeting then I'll push off on time. | 15:50.15 |
| | Didn't get a piza last nigth due to rain | 15:51.51 |
| ray_laptop | Robin_Watts: I saw the comment about 'detecting the build system'. I don't know if you meant 'automatic' or manual. The manual method exists as BUILD_SYSTEM= macro can be specified | 15:58.39 |
| Robin_Watts | ray_laptop: I mean automatic. | 15:58.55 |
| | In an ideal world, I'd like people to be able to load the VS solution, choose "Win64" from the drop down and hit build. | 15:59.28 |
| ray_laptop | if you have the toolchain paths, then if it has "Program Files (x86)" then you are building on a 64-bit system | 15:59.53 |
| Robin_Watts | ray_laptop: Except "Program Files (x86)" will be "UbergruppenFuhrer (x86)" on german machines... etc. | 16:01.50 |
| marcosw_ | UberguppenFuhrer? | 16:02.13 |
| Robin_Watts | Ubergruppenfuhrer, I meant. | 16:02.31 |
| | Some long german word. | 16:02.34 |
| | I was forgetting that we had a german speaker here :) | 16:02.41 |
| marcosw_ | they are all long | 16:02.44 |
| ray_laptop | Robin_Watts: really? what a screwy way to write an OS | 16:02.49 |
| kens | More than one | 16:02.50 |
| marcosw_ | btw, it's spelt Obergruppenführer | 16:02.56 |
| Robin_Watts | But it means "Mother-in-law", right? :) | 16:03.18 |
| kens | close enough | 16:03.41 |
| marcosw_ | you mean hippopotamus? | 16:03.59 |
| kens | marcosw_ is showing his age now | 16:04.12 |
| marcosw_ | I was wondering if anyone would get that :-) | 16:04.25 |
| ray_laptop | and the %WINDIR% is "ClearPanelOfSemiviscousMaterial", right | 16:04.39 |
| Robin_Watts | Reggie Perrin? | 16:04.42 |
| kens | correct | 16:04.53 |
| | three was a recent remake marcosw_ | 16:05.12 |
| | there | 16:05.16 |
| marcosw_ | There was Monty Python reference on Eureka last week ("No one expects the Spanish Inquisition"). | 16:05.26 |
| Robin_Watts | ray_laptop: If there is a sys var that points to "Program Files (x86)" then I could look for that... | 16:05.38 |
| kens | has that T-shirt | 16:05.51 |
| Robin_Watts | ray_laptop: Do you have a sysvar that points to Program Files (x86) ? | 16:06.32 |
| kens | Well, if thre's no meeting them I'm off. Night all. | 16:06.38 |
| Robin_Watts | Night kens. | 16:06.50 |
| henrys | Robin_Watts:I thought the tradition was to choose win64 - and it would default to that on a 64 bit system. | 16:07.01 |
| Robin_Watts | henrys: At the moment, if you're on a win32 machine, and you choose win32, you can build. | 16:07.32 |
| marcosw_ | is now torrenting the Fall and Rise remake... | 16:07.37 |
| ray_laptop | Robin_Watts: I've got: COMMONPROGRAMFILES='C:\Program Files (x86)\Common Files' AND COMMONPROGRAMFILES(X86)='C:\Program Files (x86)\Common Files' | 16:07.43 |
| Robin_Watts | If you're on a win64 machine and you choose win64, you can build. | 16:07.59 |
| henrys | using the pathname is bogus | 16:08.09 |
| Robin_Watts | I believe that if you're on win64 machine you can choose win32 and still build. | 16:08.14 |
| | (because win64 can run win32 exes) | 16:08.23 |
| | But what you can't do is build for win64 on a win32 machine. | 16:08.36 |
| | And we *could* do that, if only I had some way of detecting in a makefile whether I was on a win64 or a win32 machine. | 16:09.02 |
| | ray_laptop: Don't like the sounds of that really. | 16:09.21 |
| ray_laptop | Robin_Watts: but I only see that in msys bash. In cmd.exe I see: ProgramFiles="C:\Program Files" AND ProgramFiles(x86)="C:\Program Files (x86)" | 16:09.42 |
| Robin_Watts | Right. Mr google suggests programFiles(x86) | 16:09.57 |
| ray_laptop | Robin_Watts: why can't you build WIN64 on a 32-bit machine ? (doesn't it work if you give WIN64=1 BUILD_SYSTEM=32) | 16:10.45 |
| Robin_Watts | So I could say "If we don't have an environment variable called "PROGRAMFILES(X86)" then we're on a windows 32 machine. | 16:10.56 |
| | ray_laptop: I probably can, but I can't set up the solution to do that automatically. | 16:11.16 |
| | Well, actually, I probably could, couldn't I. Cos Win64 machines can run win32 exes. | 16:11.59 |
| | I'll try that. | 16:12.09 |
| ray_laptop | without checking if "X%ProgramFiles(x86)%" = X | 16:12.58 |
| Robin_Watts | yes. | 16:13.15 |
| ray_laptop | the main problem I had was on 64-bit systems, having it know where the compiler was. But once you are in the VS tool, that's already defined | 16:14.15 |
| Robin_Watts | I have an xcode project that *seems* to be happy building ghostscript/ghostpdl. | 16:14.16 |
| henrys | oh you fixed it or yours just worked with the current code? | 16:14.55 |
| Robin_Watts | Are people ever going to have a 64bit system with 64bit compilers, and NO 32bit compilers? | 16:14.55 |
| | I redid the xcode project. | 16:15.09 |
| henrys | Robin_Watts:oh does it work on lion? | 16:15.30 |
| Robin_Watts | Lion is all I have. | 16:15.40 |
| chrisl | Robin_Watts: currently, you cannot have no 32 bit compilers/tools in VS. | 16:15.56 |
| ray_laptop | Robin_Watts: AFAIK, there isn't a 64-bit mode VS. The 64-bit compiler is ALWAYS a 32-bit app. (in "Program Files (x86)" directory) | 16:15.59 |
| henrys | Robin_Watts:great news, thanks I'll give it a go. | 16:16.10 |
| Robin_Watts | We've not gone the full turtleneck in this house :) | 16:16.11 |
| | henrys: I haven't committed it yet. | 16:16.19 |
| | ray_laptop: Ah. That's almost sane. | 16:16.34 |
| | Then why don't we have BUILDSYSTEM default to 32 ? | 16:17.57 |
| ray_laptop | prior to the BUILD_SYSTEM= variable it assumed that the tools were in "Program Files" unless you said WIN64=1 then is assumed you were on a 64-bit system and the tools were in "Program Files (x86)" | 16:17.59 |
| | so we kept the default that if BUILD_SYSTEM wasn't given, and we were building 64-bit, we were on a 64-bit system (default BUILD_SYSTEM=64 if WIN64=1) | 16:19.13 |
| | plus running genarch built as a 64-bit app required that you were on 64-bit. | 16:19.54 |
| Robin_Watts | Hmm. !ifndef BUILD_SYSTEM\nBUILD_SYSTEM=32\n!endif | 16:20.03 |
| | so, now I'm confused again. | 16:21.02 |
| | It looks to me like BUILD_SYSTEM will default to 32 if it's not set. | 16:21.40 |
| chrisl | It does | 16:21.47 |
| Robin_Watts | So on a 32bit machine, when I set WIN64=1, why does genarch get built as a 64bit app? | 16:22.11 |
| ray_laptop | Robin_Watts: I think things have gotten honked up since I last touched it. I used to have WIN64=1 in the psi/msvc64.mak among other things, and _did_ have BUILD_SYSTEM default to 64 if WIN64 was 1 | 16:22.20 |
| Robin_Watts | I haven't touched any of the BUILD_SYSTEM stuff. | 16:22.48 |
| ray_laptop | but chrisl assumed 'ownership' and may have changed things without testing them | 16:22.53 |
| chrisl | Robin_Watts: genarch is built with the same tools as the gs executable | 16:23.24 |
| Robin_Watts | Regardless of who changed what, I don't understand how BUILD_SYSTEM can default to 32, and I can be getting 64 bit exes for genarch - unless I'm misunderstanding what BUILD_SYSTEM is supposed to do. | 16:23.43 |
| | chrisl: I thought it used CCAUX? | 16:23.51 |
| chrisl | Is CCAUX setup differently for the two cases? | 16:24.22 |
| ray_laptop | Robin_Watts: all BUILD_SYSTEM used to do was to tell the macro where to find the tools | 16:24.31 |
| Robin_Watts | Right, that's where I'm confused. | 16:24.43 |
| chrisl | ray_laptop: I never use msvc32/64.mak, I always use msvc.mak directly now | 16:24.54 |
| Robin_Watts | I thought BUILD_SYSTEM was supposed to set what tools to use for CCAUX. | 16:25.36 |
| ray_laptop | Robin_Watts: it probably _should_ but that (probably) never was done. | 16:26.15 |
| Robin_Watts | right. | 16:26.21 |
| chrisl | ray_laptop: msvc32.mak and msvc64.mak don't, and never have set WIN64 and/or BUILD_SYSTEM | 16:26.51 |
| ray_laptop | I've only ever built 64-bit binaries on my 64-bit system | 16:26.58 |
| Robin_Watts | So... is there a magic flag to cl that tells it to generate 32bit code? | 16:27.29 |
| chrisl | I have to use different parameters to vcvars.bat to get a 32 vs 64 bit build environment | 16:28.14 |
| | s/vcvars.bat/vcvarsall.bat | 16:28.56 |
| | Robin_Watts: it's different compilers to generate 64 or 32 bit code | 16:29.43 |
| ray_laptop | chrisl: I guess not (about having msvc64.mak set WIN64=1). I thought that was supposed to be the case, and am not sure why it isn't | 16:30.21 |
| | Robin_Watts: the tools for 64-bit are in the 'amd64' path | 16:31.32 |
| chrisl | ray_laptop: I don't know, ever since you split it out into three makefiles, I always used msvc.mak directly, so it never struck me to check | 16:31.45 |
| ray_laptop | chrisl: I still used msvc32.mak with WIN64=1 specified (which we wanted to work since that was the way it used to work). Probably just forgot to add setting the WIN64=1 in msvc64.mak | 16:33.17 |
| Robin_Watts | So.. you can't use 32 and 64bit compilers in the same build without chopping and changing paths? That's just mad. | 16:34.23 |
| chrisl | Complain to MS..... | 16:34.42 |
| ray_laptop | Robin_Watts: the net is that to build 64-bit on a 32-bit platform, we have to make sure to (1) use the 32-bit tools for CCAUX building and (2) use a canned 64-bit arch.h | 16:35.28 |
| Robin_Watts | ray_laptop: The latter part of that is done. | 16:35.41 |
| | It's 'just' 1) left to do. | 16:35.50 |
| chrisl | Robin_Watts: what about using a recursive nmake call to make the aux tools? | 16:35.57 |
| ray_laptop | Robin_Watts: but obviously not tested ;-) | 16:36.03 |
| Robin_Watts | chrisl: recursive nmake calls kill the rainforest, and cause global warming. | 16:37.10 |
| | or just make life hell. something like that. | 16:37.29 |
| chrisl | Well, you're going to have carry around two paths for the compilers then. | 16:39.29 |
| ray_laptop | Robin_Watts: we already have recursive make for PCL builds and for gs debug builds, so I don't see that another use is that bad | 16:39.37 |
| Robin_Watts | ray_laptop: only to the sanity of whichever poor person has to implement it. | 16:39.59 |
| | It may be easier than I think. resorting to recursive make always gives me pause. | 16:40.23 |
| chrisl | or stop f*rting about, get yourself a 64 bit Windows machine | 16:40.24 |
| | I don't think it will be very easy: on linux "make debugobj/aux/mkromfs" elicits: "make: *** No rule to make target `debugobj/aux/mkromfs'. Stop." | 16:42.08 |
| Robin_Watts | chrisl: It's not of huge import. It can certainly wait. | 16:48.45 |
| | having the ability to use precanned arch files helps with cross compiling though, so it's still worthwhile. | 16:49.15 |
| chrisl | Robin_Watts: yes, I think that's good. I'm just not too bothered about letting people build executables they can't run! | 16:50.09 |
| ray_laptop | clearly being able to build 32-bit binaries on 64-bit Windows (as well as 64-bit binaries) is of more interest. | 16:56.57 |
| chrisl | that works, it's how I do the releases - I only have 64 bit Windows machines | 16:57.27 |
| Robin_Watts | ray_laptop: I believe you can do that with the solution as it is now. | 16:57.39 |
| | We have customers that deploy 32bit Windows machines, and probably do the building on 64bit machines, hence it's important that works. | 16:58.34 |
| chrisl | I gotta go play squash - 'nite all! | 17:08.10 |
| Robin_Watts | henrys, tor8: Either of you use xcode much ? | 17:33.35 |
| | I've got a project setup, with 7 targets that do the building (2 configure stages, plus 5 builds) | 17:34.33 |
| | It looks like I then have to have various "Schemes" set up to say what to build for debugging etc. | 17:35.14 |
| | But those Schemes are saved as part of the project as robin.something, which makes me thing they are per-user rather than per-project ? | 17:35.43 |
| | And they have non-relative paths in them. | 17:36.44 |
| henrys | I don't use xcode I was just checking if it worked. | 17:37.37 |
| Robin_Watts | Ah, I need to mark them as shared. | 18:06.40 |
| mvrhel2 | Robin_Watts: so where are we now on the plank testing? | 19:16.06 |
| Robin_Watts | mvrhel2: Ah, good question. | 19:16.20 |
| mvrhel2 | should we push forth to look at halftone issues now? | 19:16.23 |
| Robin_Watts | marcosw_: I never got your email about the latest results. | 19:16.31 |
| | mvrhel2: The gs ones match, as far as I can see (at least close enough) | 19:16.47 |
| mvrhel2 | ok. great. | 19:17.03 |
| Robin_Watts | marcosw_ was testing the pcl ones, but the disc filled up. He restarted it, but I didn't see the results yet. | 19:17.09 |
| mvrhel2 | and so is plank now on cluster testing? | 19:17.13 |
| Robin_Watts | Yes, we can start to look at the halftone stuff. | 19:17.19 |
| | mvrhel2: Not until we check the pcl results (and do some xps ones I guess) | 19:17.35 |
| marcosw_ | Robin_Watts: I sent it to tech@artifex yesterday | 19:17.40 |
| | the subject was "plank vs pamcmky4 for GhostPCL" | 19:17.52 |
| Robin_Watts | So you did, sorry. | 19:18.04 |
| marcosw_ | there were quite a few differences. | 19:18.24 |
| Robin_Watts | 7am this morning for me :) | 19:18.25 |
| | ok, I'll run through them tomorrow. | 19:19.27 |
| mvrhel2 | Robin_Watts: darn. ok well let me know if something comes up that I can look at | 19:23.48 |
| tor8 | g0 ` mr "0' W | 19:24.15 |
| | p3[= | 19:24.15 |
| Robin_Watts | mvrhel2: You can start to look at the halftoning stuff now, I would think? | 19:24.31 |
| | Just steer clear of pcl etc. | 19:24.52 |
| tor8 | has gremlins in his keyboard... | 19:24.59 |
| Robin_Watts | marcosw_: Can we enable plank on the cluster for gs only ? | 19:25.09 |
| mvrhel2 | Robin_Watts: that would be nice. | 19:25.16 |
| | brb | 19:25.27 |
| marcosw_ | can and will do. | 19:25.57 |
| Robin_Watts | marcosw_: Thanks. | 19:26.04 |
| marcosw_ | need to give presentation now, so will sign off to avoid colloquy interrupting the slides :-) | 19:26.38 |
| henrys | Robin_Watts:looks like any file with an image is different FWIW | 19:29.33 |
| Robin_Watts | henrys: Joy. | 19:29.51 |
| henrys | well the good news is it might be just one issue. | 19:32.26 |
| | I'll look at one now. | 19:32.37 |
| | are all the colors supposed to be interverted for this device as part of some diabolical plan? | 19:38.47 |
| | both devices pamcmyk4 and plank have black backgrounds. | 19:39.05 |
| | maybe imagemagick is wrong | 19:39.23 |
| Robin_Watts | Ahem. | 19:48.51 |
| | No one saw that, right? | 19:48.55 |
| | henrys: I've pushed the xcode project, such as it is. | 19:50.14 |
| henrys | I guess I am confused - I understand it is a subtractive space that doesn't mean imagemagick can't represent it as it is on paper. x11cmyk is not reversed. Is that what the Ahem is about? | 19:51.27 |
| Robin_Watts | No. Ahem was about me pushing something to casper and then removing it 10 seconds later. | 19:52.03 |
| | henrys: Look at the produced pam files in a hex editor. Do the values look right? | 19:52.42 |
| | If plank and pamcmyk4 agree, then it's probably imagemagick at fault. | 19:53.03 |
| henrys | oh, anyway I can't see visible difference but cmp does show pixel difference 377 vs. 1 at many coordinates | 19:53.22 |
| Robin_Watts | 255 vs 1 ? | 19:54.45 |
| henrys | right cmp output by default is octal | 19:55.02 |
| Robin_Watts | I'm being called for dinner. will look at this tomorrow, sorry. | 19:55.05 |
| henrys | np | 19:55.14 |
| mvrhel2 | henrys: how does photoshop do on the files? | 20:12.28 |
| | as far as polarity? | 20:12.35 |
| | plank was inverted for me | 20:12.40 |
| henrys | well the background is 0 in the file and it's cmyk so ... | 20:14.01 |
| | if it were just plank I wouldn't be concerned have we somehow screwed up cmyk devices - I get the same thing with pam, which is quite mature. | 20:17.59 |
| | xllcmyk is good | 20:19.11 |
| | how is the depth 4 and the maxval 255 I guess you guys were talking about that and I missed it. | 20:28.20 |
| mvrhel2 | ah. | 20:38.19 |
| henrys | I see so 4 pixel for a cmyk color and only 1 bit per pixel so 4 bytes per pixel - a bit confusing. | 20:42.59 |
| | so 4 components | 20:43.16 |
| | and 1 bit per byte | 20:43.30 |
| mvrhel2 | hehe | 20:43.35 |
| henrys | that's why my offset calculations were wrong. | 20:43.57 |
| mvrhel2 | ok. well that is something that we need to get corrected | 20:44.06 |
| henrys | I imagine the planar is compact and he expands it in the device. | 20:47.29 |
| mvrhel2 | yes that is correct. | 20:50.30 |
| henrys | so I said many values differ between 255 and 1 but that is simply because the "max's" are different. I can't see visual differences. Was there some reason we chose output formats with different max's? | 20:55.47 |
| mvrhel2 | I remember this being a discussion topic on IRC about 2 weeks ago | 21:00.26 |
| | let's add it to the list for Friday | 21:00.42 |
| henrys | mail sent to marcos | 21:00.57 |
| | let's see what else I can get myself into today ... | 21:02.28 |
| Robin_Watts | I originally wrote plank to output as 0 and 1 in pam format. | 23:08.03 |
| | pamcmyk4 outputted to 0 and 255 in pam format. | 23:08.41 |
| | so I thought marcosw changed plank to match. | 23:08.54 |
| | Yes, plank outputs with 0 and 255. | 23:19.30 |
| | Oh, were you comparing x11cmyk and plank ? | 23:20.10 |
| | ray claimed that many applications fail to cope with MAXVAL not equal to 255. | 23:33.09 |
| | Forward 1 day (to 2011/09/07)>>> | |
IRC Logs