| | <<<Back 1 day (to 2013/10/21) | 2013/10/22 |
| Micha` | Say, say, say... I know I'm all controversial and stuff, but what should happen if there is a Form XObject with a stream containing a single point and whose BBox is but this single point? | 09:48.40 |
| | Case in point (ohoh): when there are two isolated points in a path, and the bbox is large enough to contain both, even on the rim of the bbox, both are drawn. | 09:49.34 |
| | But with only one point, this fails. | 09:49.44 |
| | By which I mean, it is not drawn. | 09:50.20 |
| Robin_Watts | It's probably down to the handling of adjusting the rectangle for the stroke width. | 09:50.42 |
| Micha` | Is it about the stroke width? It seems that the stroke shape is not clipped by the bbox. | 09:51.16 |
| Robin_Watts | I'm sure if you step through the code you'll see where the problem comes from. | 09:51.26 |
| Micha` | Ahah, I do know what and where the problem is, thanks ;-) | 09:51.43 |
| Robin_Watts | If you take the bbox of a path that contains a single point, you end up with an empty bbox. | 09:51.44 |
| Micha` | I'm just unsure about the way to solve it. | 09:51.50 |
| Robin_Watts | Micha`: Ah, well, wave a patch our way to fix it then :) | 09:52.03 |
| | I'm still stuck in gs at the moment, but hopefully I can get back to mupdf soon. | 09:52.26 |
| Micha` | The are three possible ways to fix this, as I see it: (1) if we are given an empty box, enlarge it by a small amount, (2) consider that a point belongs to the empty box with the point as boundaries, (3) assert that the current interpretting behavior is correct, and that places in which such an empty bbox is created are faulty. | 09:55.39 |
| | Well then, let's open another bug report :-) Man, I feel I'm spamming this bug tracker! | 09:56.19 |
| Robin_Watts | 1 is bad. | 09:57.26 |
| | 2 is wrong, as our convention is that bboxes are closed on the the left and open on the right. | 09:57.50 |
| | 3 is the one to pursue I think. | 09:58.03 |
| Micha` | Well, I do agree then. So the problem would amount to tracking which calls to fz_expand_rect with an empty rect are "legitimate" in that sense. At the time being, when an empty rect is asked to be expanded, nothing is done; there is surely a good reason for that? | 10:05.36 |
| | Mmh, yes, the intersection of two non overlapping rect is an empty rect, and it won't make much sense to expand it at it is not spatially located. | 10:08.41 |
| Robin_Watts | Micha`: exactly. | 10:08.51 |
| | woo hoo! Downscaler working on the rendering threads. | 10:33.08 |
| Micha` | Would it make sense to write a new device for native Android output? | 11:40.15 |
| | Or is it just a waste of time? | 11:40.22 |
| | (i.e., the draw device is already the most efficient possible implementation, and Android primitives wont be any better.) | 11:47.29 |
| Robin_Watts | Micha`: It's possible that by using opengl you could get faster operation done. | 11:59.11 |
| | but tor is already doing that. | 11:59.23 |
| stanv1 | Hello. I'm trying to embeded font | 11:59.49 |
| Robin_Watts | So unless android has specific 2d acceleration, I think we can't really do much better. | 11:59.57 |
| stanv1 | And I receive error: **** Error reading a content stream. The page may be incomplete. | 12:00.02 |
| | Hello. I'm trying to embeded font to PDF | 12:00.12 |
| Robin_Watts | And the problem is, it's not trivial to move just part of the rendering into hardware, you need to move the whole thing because of the way transparency etc works. | 12:00.28 |
| stanv1 | But other engines don't notify about any problems about my embeded font stream | 12:00.47 |
| Robin_Watts | stanv1: That message is an indication that the interpreter thinks the PDF is corrupt. | 12:00.58 |
| | What version of ghostscript are you using ? | 12:01.05 |
| stanv1 | Robin_Watts: 9.07 | 12:01.23 |
| Robin_Watts | stanv1: Well, our standard response would be to tell you to try 9.10 | 12:01.49 |
| | (the latest) | 12:01.54 |
| | Then, if the problem persists, go to bugs.ghostscript.com and open a bug. | 12:02.11 |
| | Include as much detail as possible, including at minimum: 1) the files you are using to create the problem. | 12:02.31 |
| | 2) the exact command line you use. | 12:02.41 |
| | 3) a step by step set of instructions to enable us to reproduce the problem. | 12:02.59 |
| | If we can't reproduce the problem, we can't fix it. | 12:03.11 |
| | and if you make it hard for us to reproduce the problem we probably won't be bothered to work on it :) | 12:03.44 |
| | The smallest possible example would therefore be appreciated. | 12:03.54 |
| | I've found the ideal candy for the next staff meeting: http://www.amazon.com/Haribo-Gummy-Candy-Sugarless-5-Pound/dp/B000EVQWKC/ref=cm_rdp_product | 12:18.02 |
| | (Read the reviews) | 12:18.05 |
| kens | Eeek! | 12:19.29 |
| Robin_Watts | People bulk buying them for their congressmen sounds hilarious. | 12:21.14 |
| kens | thnks congress probably has enough hot air already | 12:21.40 |
| Robin_Watts | Oh, wow, it even says on the label: "Consumption of some sugar-free candies may cause stomach discomfort and/or a laxative effect." | 12:22.23 |
| kens | AH there's a warning, that's all right then :-) | 12:24.27 |
| Micha` | Robin_Watts: That's standard for sugar free candies. Frisk and similar mints all have this warning. But this is the first time I see sugar-free haribo sweets, and I live just next their factory! | 12:24.56 |
| | So just to finish up on this Android thing: Android has native functions for paths and paint; I do not know if there is some kind of acceleration behind, but I'd have guessed that the Android lib was better at drawing vector objects than a non native lib. If you say it ain't, I'll take your word :-) | 12:29.02 |
| stanv1 | Robin_Watts: There is assumption that I | 12:30.23 |
| | have wrong font description | 12:30.35 |
| | Robin_Watts: how can I produce more information ? | 12:30.54 |
| | **** Error reading a content stream. The page may be incomplete. | 12:30.59 |
| Micha` | stanv1: I think following Robin's steps is a good start. | 12:33.00 |
| Robin_Watts | Micha`: Our lib is "native". | 12:33.27 |
| | it's not hardware accelerated. | 12:34.10 |
| | The problem with the android stuff, is that it's not general enough; it will only render to android bitmaps, not to our pixmaps, and we need it in our pixmaps to cope with blending for transparency etc. You can't move the render path piecemeal. | 12:35.06 |
| Micha` | Well, there are transparency options in Android's lib. All the Porter/Duff modes are here. | 12:36.24 |
| | But I may be missing something obvious, sorry. | 12:36.44 |
| Robin_Watts | Micha`: Well, if you want to try it, I'd be interested to see the results. | 12:38.33 |
| Micha` | As long as you don't see any technical nonsense in this, I'd happily give it a try. I have close to no knowledge in Android graphics, so this is mainly formative to me. | 12:41.13 |
| stanv1 | %Resolving: [65 0] | 12:41.56 |
| | 0 (\376\377\000G\000D\000I\000.\000P\000P\000D) 0 0 Tform | 12:41.57 |
| | **** Error reading a content stream. The page may be incomplete. | 12:41.57 |
| Micha` | Any opinion on whether I should write the device in Java or in C? | 12:42.15 |
| | stanv1: is the PDF causing the problem confidential? | 12:42.55 |
| stanv1 | Micha` I can give it to you | 12:43.46 |
| Micha` | stanv1: Can you follow the steps Robin gave you earlier and open a bug report with the PDF attached? | 12:44.25 |
| | (Provided you did test with the latest version of gs) | 12:44.46 |
| stanv1 | https://dl.dropboxusercontent.com/u/9413602/Micha.pdf | 12:44.51 |
| Robin_Watts | Micha`: Well, you'll need to write the device in C as MuPDF does not have a device interface to call java. | 12:44.52 |
| kens | stanv1 please follow the instructions to report a bug. From the paste above, ytou PDF file is using 'Tform' which is not valid PDF syntax | 12:46.44 |
| Micha` | Robin_Watts: Interfacing will be necessary at some point, IIUC. Either I create a hollow device in C which loads the actual device written in Java, or I write the device in C which loads the numerous Java Android drawing functions. | 12:47.25 |
| stanv1 | kens: are you sure about Tform ? | 12:48.10 |
| Robin_Watts | Micha`: Exactly. | 12:48.50 |
| | I have started on some jni code, but it's not advanced enough to allow devices to be written in C yet. | 12:49.11 |
| kens | stanv1 if I was sure I wouldn't tell you to report a bug. One thing I am sure of ist hat nobody will look at it if you don't report a bug | 12:51.29 |
| Micha` | Well, so I'm pondering whether the bulk of the device should be written in C or in Java. With the little knowledge I have of JNI, I can't see if one is better than the other. | 12:52.33 |
| kens | just checked hte PDF Reference and can find no reference to a Tform operator | 12:53.34 |
| Robin_Watts | Micha`: Perhaps you should look at my JNI branch. | 13:01.52 |
| | If it was me, I'd be tempted to write a set of device entrypoints in C that MuPDF can call. | 13:03.45 |
| | Each of these would call back into java methods to do the actual drawing. | 13:04.08 |
| | That way the bulk of the coding can be done in java, if that's what you are more comfortable with. | 13:04.23 |
| | I have to say that I have never done JNI calls from C to Java, so I'm not quite sure how involved this is. | 13:04.43 |
| Micha` | I'm not more comfortable with one option or the other :-) I really have no clue which one is better. But OK, I'll have a go with the almost-all-Java then. | 13:07.18 |
| | Where can I find your branch? | 13:08.13 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/jni | 13:11.53 |
| | It is very "work in progress". | 13:12.07 |
| Micha` | Holy schnitzel! Impressive! | 13:15.33 |
| Robin_Watts | Micha`: It's really not that impressive. It's me sketching out a structure - that structure is NOT complete, or completely filled in yet. | 13:16.24 |
| | It was mostly done to see if this looked like being a reasonable way to work, and we haven't spotted any obvious flaws yet :) | 13:17.16 |
| Micha` | Anyway, it's nice to see that :-) If things are done right, a Java Android device could be plugged in this quite easily. | 13:20.22 |
| Robin_Watts | lunches. 70 minutes to meeting, right? | 13:24.32 |
| kens | 30 minutes now | 13:55.54 |
| | 35 in fact | 13:55.58 |
| Robin_Watts | ok. ISTR that the hour changed differently in the US and the UK last time. | 13:58.08 |
| | And we're just over a week away from it changing for us, I think. | 13:58.23 |
| chrisl | Robin_Watts: apparently, clocks change in California on 3 November 2013 | 14:09.33 |
| Robin_Watts | ok, so a week after us. | 14:10.04 |
| kens | I checked an online time thingy | 14:10.17 |
| | Sorry for slow responses, I've been looking through 65 pages of diffs | 14:10.50 |
| chrisl | That's just what I did - given the day I'm having, it wouldn't have surprised me if I'd cocked up the meeting time! | 14:10.59 |
| Robin_Watts | no worries | 14:11.00 |
| | Last time I had a con-call with Miles, I carefully calculated the time, then set the alarm on my phone an hour too late :( | 14:11.42 |
| chrisl | I tried using my phone's task list app, but it kindly resets all the task times to the timezone when we visit the US, and fails to set them back again when we come home - stoopid thing | 14:14.08 |
| henrys | chrisl: sounds like a reportable bug | 14:21.24 |
| chrisl | henrys: it probably is, but I think it's Motorola, rather than Google, and Mot aren't supporting that phone any more | 14:22.16 |
| henrys | I'm showing my house today and this giant spider is walking across the floor - best put it outside. | 14:23.11 |
| chrisl | henrys: claim it's pet ;-) | 14:23.50 |
| | it's a pet - even | 14:23.59 |
| henrys | it got away | 14:24.13 |
| | chrisl: just ignore the giant spiders and rats - it's all good. | 14:25.02 |
| chrisl | Spiders don't worry me - hate rats, though..... | 14:25.39 |
| henrys | you guys did get the email to tech yesterday about the meeting time? | 14:27.39 |
| kens | Ye | 14:27.46 |
| marcosw | yes | 14:28.04 |
| chrisl | Yeh, we just had a little confusion about clocks changing in various time zones | 14:28.11 |
| henrys | chrisl: oh that again. | 14:28.32 |
| kens | hey marcosw I had a funny thing with a cluster test, it was trying to run a file called custom.lst or something similar | 14:28.43 |
| Robin_Watts | henrys: Next week we are out of sync. | 14:28.45 |
| | henrys: So, this 801 thing... you want us to be able to cluster test their device. | 14:29.21 |
| | But their device has hacks right in the middle of the ghostscript core. | 14:29.38 |
| henrys | Robin_Watts: sorry that was a cryptic comment | 14:29.40 |
| | I would like to have a gdev801.c device that has all their code that we can plug in and debug or test | 14:30.32 |
| Robin_Watts | What we have now is a new scheme that allows them to reimplement their device in a way that keeps the performance that they had before (and possibly improves it) and yet lets us keep all the device changes in their device. | 14:30.44 |
| | So it should now be possible to do a gdev801.c that's much neater, and is testable. | 14:31.21 |
| henrys | Robin_Watts: as not to get in the situation we have with other printer customers where the code is far removed from the current dev code. | 14:31.22 |
| Robin_Watts | Right. | 14:31.29 |
| | but presumably we need to contact them and say "hey, let's work together to rejig your device". Or would you rather we went ahead and converted it, and told them afterwards ? | 14:32.00 |
| henrys | Robin_Watts: right that's what you and ray were working on? | 14:32.17 |
| | Robin_Watts: fantastic | 14:32.25 |
| Robin_Watts | henrys: Not exactly. | 14:32.27 |
| | Ray and I have been working on the new scheme. | 14:32.37 |
| | We haven't touched their device yet. | 14:32.42 |
| | But the new scheme does seem to be working nicely. | 14:32.55 |
| marcosw | kens: yes, that was my bug. I'm adding the ability to specify custom tests. it should be fixed now. | 14:33.00 |
| kens | thanks marcosw | 14:33.09 |
| Robin_Watts | aargh. sunlight. | 14:33.16 |
| henrys | Robin_Watts: well I am working on this also, the manager of the project I've been communicating with has gone dark. | 14:33.38 |
| | Robin_Watts: so we could make the change but I don't know if they would take it. | 14:34.04 |
| | marcosw: I assigned a customer bug back to you and I think you have another. | 14:34.27 |
| Robin_Watts | henrys: I don't think it's a huge amount of work to change their device. | 14:34.36 |
| | and it would make their life much easier when it came to upgrading gs versions. | 14:35.01 |
| henrys | Robin_Watts: we presumably could test the change against their old code also. | 14:35.14 |
| Robin_Watts | presumably. | 14:35.23 |
| marcosw | henrys: thanks for the reminder. | 14:35.56 |
| mvrhel_laptop | morning. sorry a bit late | 14:35.58 |
| henrys | mvrhel_laptop: np | 14:36.17 |
| Robin_Watts | ...and that's why mvrhel_laptop is best placed to solve the bug. | 14:36.18 |
| mvrhel_laptop | ha | 14:36.26 |
| henrys | chrisl: how goes it with the yuki task? | 14:36.52 |
| chrisl | henrys: I'm trying to work out how to spin this: we're missing a lot of glyphs compared to the MT fonts, but none are required for PDF, so..... | 14:37.35 |
| henrys | Robin_Watts: I'd like to add the project to the agenda - you call it "process page" | 14:38.12 |
| Robin_Watts | henrys: yeah. | 14:38.21 |
| chrisl | henrys: one concern - I'm wondering if they are considering trying to use our fonts for Postscript and PCL - based on some of the questions | 14:38.36 |
| henrys | chrisl: I think they would consider postscript but not pcl. | 14:39.13 |
| | Robin_Watts: but the real project is to allow device writers to take advantage of MT rendering yes? | 14:39.52 |
| Robin_Watts | henrys: Yes. We have that working. | 14:40.04 |
| | It's ready for commit now, just going to give ray a chance to give it another once over if he wants. | 14:40.21 |
| chrisl | henrys: is that permissible? Don't the URW fonts have to used with GS (or be compliant with the GPL)? | 14:40.38 |
| Robin_Watts | It's on robin/master for anyone interested in looking. There is a documentation change there too. | 14:40.40 |
| henrys | let me text that guy | 14:40.47 |
| mvrhel_laptop | Robin_Watts: so what exactly does it do? | 14:41.05 |
| | sorry I had not been following closely | 14:41.12 |
| Robin_Watts | Printer devices get called by their "print_page" entry point. | 14:41.34 |
| | Traditionally then they 'get_bits' from the device to get rendered scanlines out, and they then process them and output them. | 14:41.58 |
| | i.e. the device drives the extraction by extracting bits in whatever order it needs. | 14:42.18 |
| mvrhel_laptop | right | 14:42.24 |
| Robin_Watts | but it's a basically serial process. | 14:42.27 |
| | So now, devices still get called by print_page, but they can then call 'process_page'. | 14:42.46 |
| ray_laptop | morning, all. Sorry I'm a bit late. | 14:43.08 |
| | traffic at the coffee shop :-) | 14:43.22 |
| mvrhel_laptop | Robin_Watts: and then what happens? | 14:43.35 |
| henrys | ray_laptop: see the logs we've been discussing your latest project | 14:43.40 |
| Robin_Watts | They pass in a load of callback functions; process_page can then render bands on the threads, and for each band as it renders it calls the 'process_fn'. | 14:43.43 |
| ray_laptop | mvrhel_laptop: then the magic | 14:43.44 |
| Robin_Watts | The process_fn's can be called out of order (and at the same time). | 14:44.07 |
| ray_laptop | henrys: yes, I've reviewed the logs while waiting for the laptop to connect | 14:44.15 |
| Robin_Watts | Then process_page calls the output_fn, to actually do the output of each band. | 14:44.25 |
| | The output_fn's are guaranteed to be called in order. | 14:44.36 |
| ray_laptop | (output_fn is from the main thread) | 14:44.50 |
| Robin_Watts | So for my new png device, the process_fn's handle the downscaling, the application of the predictors, and the zlib compression. | 14:45.11 |
| henrys | so you'll be able to halftone within each thread as 801 does now? | 14:45.23 |
| ray_laptop | it needn't be, but that was easiest for Robin_Watts to connect in | 14:45.25 |
| Robin_Watts | And the output_fn's just write the compressed buffers to file. | 14:45.34 |
| ray_laptop | henrys: right | 14:45.38 |
| mvrhel_laptop | nice | 14:45.41 |
| ray_laptop | as long as the halftoning doesn't require info from a prior band | 14:45.58 |
| | as is the case for any threshold array based HT, including BNM | 14:46.18 |
| Robin_Watts | yeah, we can't do error diffusion for example where the errors persist from band to band. | 14:46.25 |
| ray_laptop | FS is a problem, however | 14:46.26 |
| mvrhel_laptop | so a probably silly question. where does clist writing and reading and its threads fit into this. | 14:46.27 |
| Robin_Watts | mvrhel_laptop: this stuff all piggybacks on the clist. | 14:46.47 |
| ray_laptop | the clist writing is still the same. | 14:46.48 |
| | this is equivalent to MT rendering, and actually the process_fn is called from the same thread that rendered the band | 14:47.25 |
| mvrhel_laptop | ok. so when I am in a thread rendering a band during clist reading, I get to do these extra functions on the data? | 14:47.26 |
| | in the thread | 14:47.31 |
| | ok | 14:47.36 |
| Robin_Watts | mvrhel_laptop: You never need to worry about this stuff. | 14:47.48 |
| mvrhel_laptop | and those functions came from the device | 14:47.50 |
| Robin_Watts | As far as the clist reading is concerned, you just render the bands as usual. | 14:48.07 |
| ray_laptop | there is a very clean (kudos to Robin_Watts) implementation of png16m called fpng | 14:48.11 |
| | with easy to follow examples of the process_fn | 14:48.26 |
| Robin_Watts | The magic calling of this functions happens outside clist_rasterise_lines (or whatever it is) | 14:48.34 |
| henrys | chrisl: wait which fonts are you testing - we have the URW type 1 80 right? kens reviewed those fonts a while back? | 14:48.44 |
| chrisl | henrys: there is no "80" | 14:49.01 |
| kens | 35 fonts | 14:49.12 |
| mvrhel_laptop | sounds nice Robin_Watts and ray_laptop | 14:49.14 |
| ray_laptop | I thought we had 80 TTF's for PCL | 14:49.20 |
| Robin_Watts | It turned out far nicer than I'd feared it would. | 14:49.28 |
| kens | I didn't review those | 14:49.29 |
| chrisl | henrys: the "80" fonts font set is the combined PCL and PS LL2 font sets | 14:49.30 |
| ray_laptop | and 136 from URW for PS LL3 | 14:49.33 |
| kens | I don't believe we have 136 from URW do we ? | 14:49.45 |
| ray_laptop | chrisl: are you looking at the TTF's, though ? | 14:49.53 |
| henrys | right so we pull the 80 from the 136 | 14:49.55 |
| chrisl | ray_laptop: not, Type 1 | 14:50.04 |
| ray_laptop | kens: yes, we have URW 136 | 14:50.05 |
| Robin_Watts | ray_laptop: I am tempted to amalagamate all the 'process_arg', 'init_buffer_arg' etc into a single 'arg'. | 14:50.11 |
| henrys | matching the ufst setup | 14:50.15 |
| kens | Hmm well I don't recall chekcing all of those | 14:50.21 |
| chrisl | henrys: that doesn't match UFST's setup | 14:50.25 |
| ray_laptop | so Type 1 fonts will render slightly differently to TTF's won't they ? | 14:50.38 |
| chrisl | Yes, due to hinting and other minor differences | 14:50.55 |
| henrys | chrisl: he specifically told me they were using the 80 font ufst setup | 14:50.56 |
| chrisl | henrys: yes, that's a combination of PCL *and* PS fonts | 14:51.10 |
| | BTW, it isn't 80, it's 83..... | 14:51.26 |
| ray_laptop | Robin_Watts: that's probably OK, but having them be different gives us some flexibility that we may need later (but I can't think of why) | 14:51.44 |
| chrisl | henrys: there is no PDF or Postscript spec that lists a font set containing 80 fonts | 14:52.08 |
| ray_laptop | chrisl: is that because of the lineprinter fonts ? | 14:52.11 |
| Robin_Watts | I thought it would be more flexible when chaining, but having just coded a chaining example (downscaler within fpng), it doesn't work out, and they all get set to be the same anyway :( | 14:52.24 |
| henrys | chrisl: right we are emulating HP printers and so are they as far as I know. | 14:52.32 |
| chrisl | henrys: we're implementing the PDF spec, not emulating a printer | 14:52.53 |
| henrys | chrisl: not for this project. | 14:53.11 |
| ray_laptop | Robin_Watts: well, the void *arg can have whatever an implementation needs, with separate sub-structs or parts for each part, so I guess 1 is fine | 14:53.34 |
| henrys | we are comparing ourselves with the ufst which is emulating a printer so... | 14:53.44 |
| chrisl | henrys: well in that case, the answer is simple: we can't do it | 14:53.48 |
| | UFST does not emulate a printer | 14:53.58 |
| henrys | according the documentation it does. | 14:54.31 |
| ray_laptop | henrys: I thought we were looking at licensing our fonts *instead* of UFST | 14:54.35 |
| henrys | ray_laptop: they are | 14:54.51 |
| | is there some way to print a font page on the simulator for postscript? | 14:55.16 |
| ray_laptop | UFST is just the font scaler technology. | 14:55.22 |
| chrisl | henrys: how does a font scaler emulate a printer.... anyway, not relevant | 14:55.27 |
| henrys | you should see 80 fonts | 14:55.31 |
| ray_laptop | Monotype has full RIP solutions, but that's outside the scope of UFST | 14:55.44 |
| henrys | UFST is fonts + font scalers | 14:55.56 |
| chrisl | henrys: no, it spits out a lot more than 80 because they have name mappings etc, just like we do | 14:56.02 |
| ray_laptop | henrys: I can easily feed it a PS to enumerate the font Resource category | 14:56.19 |
| chrisl | henrys: in order to have matching glyph sets, we'd need URW add 300+ glyphs to 136 fonts | 14:56.52 |
| ray_laptop | henrys: chrisl's point is the operative one. We have enough fonts, but they aren't as fully populated | 14:58.04 |
| | we probably have glyphs that they don't as well, but I haven't looked | 14:58.22 |
| chrisl | That's 300+ glyphs that are *not* required by either PDF or Postscript specifications | 14:58.49 |
| henrys | chrisl: okay but they specifically told me they were only concerned with 80 fonts. Can ray_laptop enumerate the fonts so we can see what truth is? | 14:59.05 |
| chrisl | I;ve already said that doesn't work, you'll get more than 80 fonts reported | 14:59.31 |
| ray_laptop | either chrisl or I could do it, and probably be able to tell which are just "alias" names | 14:59.35 |
| | Can't we just see what their FCO's contain ? | 15:00.07 |
| henrys | chrisl: oh is not possible to enumerate the true fonts? | 15:00.33 |
| chrisl | ray_laptop: it's not that easy - for example, Courier is not the same font as CourierHP | 15:00.36 |
| | henrys: we can't easily differentiate between "real" fonts, and name mappings, no | 15:00.59 |
| henrys | kens:I do think you reviewed the 136 set? | 15:01.03 |
| kens | henrys I no longer remember, its been a *very* long time | 15:01.20 |
| henrys | chrisl: I thought there was a list of the fonts in one of the ufst data files. | 15:01.54 |
| chrisl | henrys: there are several, that's one of the things I've been using | 15:02.25 |
| kens | henrys yes, and that was one of the things that was wrong, or at least inconsisitent, with the actual supplied fonts | 15:02.30 |
| henrys | chrisl: on the simulator the resident fonts are micro type correct? | 15:03.32 |
| chrisl | henrys: yes, they are (except the Japanese pair) | 15:03.59 |
| henrys | and there must be code that opens each font. | 15:04.05 |
| chrisl | Yes? | 15:04.23 |
| henrys | so a breakpoint on the open or a debug printf for each font? | 15:05.02 |
| | where it physically opens and mtfont | 15:05.24 |
| chrisl | Are you asking me to investigate someone else's Postscript interpreter code? | 15:05.26 |
| henrys | chrisl: I've told him we have the simulator and he has agreed for us to do a comparison I don' t see a problem. | 15:06.32 |
| chrisl | henrys: Well, that's going to take a lot longer, I've no idea how they interface to UFST, nor how tightly integrated it is, nor how much they have customised UFST | 15:07.50 |
| ray_laptop | henrys: What exactly do you want ? Just a list of the fonts they ship ? or the glyph names that are in those fonts, or what ? | 15:08.40 |
| henrys | chrisl: just forward yuki's email to ray_laptop | 15:09.01 |
| | we are getting near end here anything else for the meeting. | 15:09.32 |
| | ? | 15:09.32 |
| chrisl | I have a list of fonts, I have a list of glyphs in those fonts, and I have a list of glyphs in there that aren't in the URW fonts - I'm not sure what more information I need?? | 15:09.54 |
| ray_laptop | and do you need some analysis on their Japanese fonts "MHeiGBMediumMonotype" (in mhgbm.ttf) ? | 15:10.13 |
| chrisl | ray_laptop: I'm hoping not - we have a couple of good options as far as replacing them is concerned | 15:10.48 |
| henrys | chrisl: well if the printer can only access 80 fonts as I've been told I thought we could make the list smaller. But you can send the report as is, if you are more comfortable with that. | 15:11.00 |
| chrisl | ray_laptop: mail should be with you | 15:11.01 |
| ray_laptop | henrys: what else besides what chrisl already got ? | 15:11.04 |
| manuel | hi! good afternoon =) | 15:11.17 |
| henrys | ray_laptop: ? | 15:11.44 |
| ray_laptop | manuel: good morning (8:10 am here) | 15:11.45 |
| manuel | 8) | 15:12.03 |
| henrys | we can adjourn here unless there is other business. | 15:12.17 |
| Robin_Watts | henrys: Just on this 801 thing. Do we push ahead and look at converting their device? | 15:12.54 |
| chrisl | henrys: well even 80 fonts, 300 extra glyphs in each, that's not going to cheap, I doubt we'll get much interest in them from elsewhere, and I reckon it would blow the size so much cust 532 would balk anyway. | 15:13.08 |
| henrys | chrisl: what are they cyrillic? Central European? | 15:14.53 |
| manuel | to a mupdf developer: i look for some inside knowledge about mupdf! i wan't to know if it has implement a "Custom URL Scheme" for its iOS version. Tnx! | 15:15.10 |
| ray_laptop | Robin_Watts: are you proposing porting their device over to run on top of HEAD, then sending the revised driver that runs on that ? | 15:15.17 |
| henrys | Robin_Watts: I say go forward but not at p1 priority - ie. ray's customer's need are first. | 15:15.51 |
| chrisl | henrys: some are, but many are for PCL symbol sets - glyphs like: arrowupdn, arrowboth, SF440000, invsmileface etc | 15:16.05 |
| ray_laptop | henrys: I think the hot customer needs I've been on are OK now | 15:16.43 |
| Robin_Watts | henrys: sure. | 15:16.48 |
| chrisl | henrys: and the point remains many (possibly most) are non-standard glyphs for PDF and Postscript, so I doubt many Ghostscript customers would want to cough up extra cash for them | 15:17.32 |
| henrys | ray_laptop:okay but if new stuff comes in that's more important. | 15:17.40 |
| ray_laptop | henrys: and it won't take both Robin_Watts and I. Probably Robin_Watts is more familiar with his hooks, however, but we can draw straws ;-) | 15:17.41 |
| | I doubt either of us is eager to muck around with their stuff, but we can probably just wear gloves while working on it ;-) | 15:18.32 |
| henrys | chrisl: miles pays for the glyphs, the prices won't change. | 15:18.35 |
| | chrisl: size is the issue. | 15:18.44 |
| Robin_Watts | ray_laptop: I'll look at it. | 15:18.51 |
| henrys | kens:we're done I don't know if you saw the adjourn comment. Don't want to hold you up. | 15:19.36 |
| ray_laptop | henrys: for many of their products, they have a HD, but we do know that some of the low end have flash capacity constraints (6th gen) | 15:19.43 |
| chrisl | henrys: wouldn't it depend on the cost? I mean, we're talking about adding ~19440 glyphs | 15:19.49 |
| ray_laptop | chrisl: they probably "cheat" on the Italics | 15:20.35 |
| henrys | chrisl: that's a one time thing I get the impression it is not that expensive, we filled the pcl fonts fairly cheaply. | 15:20.49 |
| | chrisl: each pcl font has over 600 glyphs. | 15:21.04 |
| ray_laptop | chrisl: and AFAIK, they have lots of glyphs laying around that they just don't include when assembling fonts | 15:21.20 |
| chrisl | henrys: I know, these are basically all PCL fonts..... | 15:21.20 |
| henrys | I believe the customers printer shares the fonts don't they? | 15:22.11 |
| ray_laptop | Robin_Watts: Thanks. It actually shouldn't be too hard to rip the code out of gxclthrd.c and put it into process_fn's | 15:22.44 |
| Robin_Watts | ray_laptop: yeah, so I am hoping :) | 15:22.58 |
| chrisl | henrys: Yes, but the way the Microtype fonts work means it's easy to share - so all the fonts have all the glyphs for Postscript, PDF and PCL | 15:22.59 |
| henrys | "PCL fonts" is confusing me terminology wise. You mean a font that happens to have glyphs accessible by pcl symbol sets I guess? | 15:23.08 |
| chrisl | No, I mean fonts which a compliant PCL5 interpreter is expected to have available | 15:23.46 |
| ray_laptop | henrys: the arial and mhgbm they have are TTF's (separate from the FCO's) | 15:25.09 |
| | henrys: and they also have a times.ttf and wingdings.ttf | 15:25.41 |
| chrisl | So, we could probably configure Ghostscript to use our PCL5 font set, and get decent equivalents | 15:26.30 |
| henrys | chrisl:but we could write postscript to access these pcl fonts and use them if we were clever right? | 15:27.28 |
| | henrys: you aren't saying they are unreachable just not expected to be accessed by PDF or PostScript | 15:27.53 |
| | ? | 15:28.00 |
| ray_laptop | henrys is talking to himself | 15:28.21 |
| chrisl | henrys: on the customer's system? They are available from Postscript/PDF, nothing clever required | 15:28.26 |
| henrys | ray_laptop:thinking out loud on irc ;-) | 15:28.49 |
| | chrisl: they are in the standard encoding for the fonts? | 15:30.14 |
| chrisl | henrys: by default they use StandardEncoding, if that's what you mean? | 15:31.06 |
| | Postscript fonts are accessed by glyph name, they really have a "standard encoding" | 15:31.47 |
| ray_laptop | henrys: he asked about "code sets". PS has "Encodings". Doesn't PCL have code_sets ? | 15:31.59 |
| chrisl | ray_laptop: that's what made ask whether they might be considering trying to use our fonts in their PCL | 15:32.31 |
| marcosw | Robin_Watts: I was looking at your latest clusterpush which had differences in files that bmpcmp didn't find. I can't recall, does bmpcmp ignore single pixel differences? | 15:32.36 |
| henrys | chrisl: I thought they would make some effort to emulate adobe and not have access to the the PCL glyphs | 15:32.38 |
| Robin_Watts | marcosw: It does not. | 15:32.50 |
| henrys | that could be done by not having postscript encoding access the pcl glyphs | 15:33.05 |
| chrisl | henrys: you can write custom encodings to map a code to any glyph name, so | 15:33.25 |
| Robin_Watts | marcosw: I cannot explain such differences. | 15:33.41 |
| henrys | chrisl: well that would fall under "clever" | 15:33.42 |
| | see above | 15:33.46 |
| marcosw | Robin_Watts: does it correctly deal with multi-page ppmraw files? The differences it missed are on pages after the first. | 15:33.53 |
| Robin_Watts | marcosw: I believe it does... | 15:34.08 |
| chrisl | henrys: but there are no standard encodings that give access to these extra glyphs (at least, the ones I've checked) | 15:34.19 |
| marcosw | Robin_Watts: well those are the obvious answers; I'll investigate further. | 15:34.44 |
| chrisl | henrys: you don't need anything clever to access the *font* but something clever (like a custom encoding, or using glyphshow) would be required to access the extra glyphs | 15:35.21 |
| henrys | chrisl: is this test difficult to do. It would be interesting to use the urwfonts - pcl true types as the resident set and see what is missing? | 15:38.17 |
| chrisl | henrys: the difficult bit (or time consuming bit) there is creating the mapping from the font names to the fonts files. The actual test takes less than a minute to run | 15:39.22 |
| henrys | chrisl: but I think we have enough to respond just tell him the extra glyphs are primarily for pcl for which we have different fonts. | 15:40.54 |
| chrisl | henrys: Okay. Should I go ahead with the performance tests, or wait until we get a response about that? | 15:41.33 |
| henrys | chrisl: very quick to hoist a mapping out of plftable.h with fancy search-replace stuff. | 15:42.07 |
| ray_laptop | It would be quite a bit of work for them to call our (FT) font scaler instead of the UFST calls they make now. I'm not surprised that Y didn't bring that up, but I can imagine the howls from the engineers | 15:42.16 |
| chrisl | henrys: the problem there is that the PCL names aren't exactly the same as the Postscript ones | 15:43.09 |
| ray_laptop | for GS, it's not a problem, but unless they totally dump their PCL and PS, it is a problem | 15:43.10 |
| henrys | chrisl: yes I think we have enough and just say the speed performance is compatible but for "size" we suck. | 15:43.40 |
| ray_laptop | henrys: or is this part of switching over to Artifex PDL's entirely ? | 15:43.55 |
| | Miles keeps trying to get them to do that | 15:44.26 |
| henrys | ray_laptop:we are giving them the fonts - anyone can have the fonts who has purchased a license for the pdl. | 15:44.48 |
| | ray_laptop:yes we worked on that. | 15:45.01 |
| chrisl | ray_laptop: that's another area that left me unclear - at least question sort of sounded like "how did you solve this, 'cause we could do the same" | 15:45.01 |
| ray_laptop | chrisl: Oh, no!!! They're not considering something like FAPI are they ???? | 15:45.59 |
| | although it's a lot cleaner now than before | 15:46.20 |
| chrisl | ray_laptop: I really don't know, but asking about supporting Intellifont in Freetype made me wonder...... | 15:46.39 |
| ray_laptop | henrys: yeah, I saw that (and your reply) | 15:47.05 |
| chrisl | henrys: but not for the PCL font set, surely - they haven't licensed PCL, so they don't have a *right* to the PCL font set - although I would understand if we opted to make them available | 15:47.19 |
| ray_laptop | oops, that reply was to chrisl | 15:47.22 |
| chrisl | Well, it was henrys's reply... | 15:47.48 |
| henrys | chrisl: yes we opt to make them available | 15:48.11 |
| | chrisl: so I think I can cobble together a font name mapping for the pcl fonts. I'd like to test that as a separate project anyway. Good to know if that would buy us much more. | 15:50.21 |
| | chrisl: although I remember building Postscript with truetype resident fonts broke a lot of windows driver files which did rude stuff. | 15:51.23 |
| chrisl | henrys: yes, lots of PS programs do things like adding glyphs to fonts, assuming they are type 1, and that won't work in a type 42 :-( | 15:52.33 |
| henrys | I guess we could special case those but that could get nasty | 15:53.41 |
| chrisl | That would not be straight forward, in fact, in would be freakin' horrid | 15:54.25 |
| ray_laptop | chrisl: BTW, their is a recent simulator if you want in "ForRay" on their (U.S.) FTP site. Dated 2013-10-18. Just in case you wanted to have a look. | 15:54.35 |
| chrisl | ray_laptop: thanks, I'll get it - I've been a bit wary, though, as I seem to have a huge fight to get each new one I download to build and run :-( | 15:55.17 |
| henrys | ray_laptop:could you email the ftp info to me. | 15:55.37 |
| chrisl | henrys: so the MT FCO + "plugin" for the PCL/PS2 80+ font set is ~932k compared with our 82 TTF set which is 9.6 Mb | 15:57.14 |
| ray_laptop | chrisl: all I really do is modify the "setsim.bat" to force the selection of VS 2008 and things build nicely. The other key point is the argument given to setsim.bat (alphard2 for that sim) | 15:57.25 |
| | So, the file I modify before starting it up (by invoking the setsim.bat) is 2l6_ctl\projectroot\element\ren\ren_rip\SIM\BAT\setsim.bat | 15:58.28 |
| chrisl | ray_laptop: the last update I had wouldn't open on anything older than VS2010, and didn't work on Express | 15:58.43 |
| | ray_laptop: I suspect it strongly depends on who uploads it | 15:59.28 |
| ray_laptop | henrys: I re-sent the FTP site to you (and cc'ed tech) | 16:00.38 |
| | chrisl: this was from Len, and I usually use VS 2008, changing the line: REM set OVERRIDE_VS_VERSION=%VS90COMNTOOLS% to remove the "REM " | 16:01.48 |
| chrisl | ray_laptop: I do the same, but usually for 2005, but that one gave the "this has been opened with a newer version....." and then failed to open. | 16:03.03 |
| ray_laptop | henrys just lost power (he sent me a text) | 16:03.12 |
| Robin_Watts | ray_laptop: Do you want to look over the latest commits? Or shall I just push them ? | 16:03.32 |
| ray_laptop | Robin_Watts: I'll take a quick look.... | 16:03.59 |
| kens | Night all | 16:07.36 |
| Robin_Watts | night kens | 16:07.41 |
| henrys | back sorry about that. | 16:08.29 |
| Robin_Watts | henrys: rats ate the power cable? | 16:08.54 |
| henrys | electrician fiddling | 16:09.53 |
| Robin_Watts | There are 2 devices in 801s code. gdevXXXX.c and gdevXXXXgraph.c | 16:10.27 |
| | but the graph one doesn't seem to do anything - print_page_copies just does a printf and returns. | 16:10.57 |
| henrys | yes I don't think graph is of much concern. | 16:12.45 |
| chrisl | henrys: so, did you want to create the Ghostscript fontmap for the PCL TTF font set, or shall I? | 16:16.12 |
| ray_laptop | Robin_Watts: I'm a bit confused. the fpng dso adjusts the band height using the downscale_factor. Isn't that a composite of an "up" digit and a "down" digit (eg. 23 = 2/3) ? | 16:16.18 |
| Robin_Watts | ray_laptop: You're right. | 16:16.46 |
| | Will fix. | 16:16.57 |
| henrys | chrisl: I'll do it, but we don't need it for the response right? or did you want to try it first? | 16:17.07 |
| ray_laptop | Robin_Watts: hurray! Code review actually worked ! ;-) | 16:17.15 |
| Robin_Watts | Generally the factor is 'n', but we have 2 special factors, 32 and 34. | 16:17.19 |
| | ray_laptop: Code review is really good :) | 16:17.36 |
| chrisl | henrys: I don't think it's relevant - my feeling is that the size will be too much of an issue..... | 16:17.44 |
| henrys | chrisl: I do believe we can get all the pcl fonts in t1 format from urw without much pain. | 16:17.44 |
| | avoiding building a ps product without TT's. | 16:18.16 |
| | chrisl: possibly so. | 16:18.45 |
| chrisl | henrys: as a "simple" test, I could probably write a fontforge script to convert the TTs to T1s - we probably wouldn't want to ship them, but..... | 16:21.08 |
| | henrys: good news is that I think the Post tables are complete in the PCL TTF font set | 16:22.50 |
| ray_laptop | henrys: I have the URW 136 in TTF _and_ T1 | 16:22.55 |
| henrys | ray_laptop: right and I thought that font set had the same coverage as the pcl fonts. | 16:23.25 |
| ray_laptop | henrys: that I don't know offhand | 16:23.56 |
| henrys | ray_laptop: maybe chris should test with that set of fonts. | 16:24.18 |
| chrisl | Ah, I was assuming they had the same coverage as the 35 base fonts..... | 16:24.38 |
| henrys | we really should have these fonts under version control btw | 16:24.42 |
| chrisl | I believe there are unresolved issues mapping Adobe name-> URW name -> file name | 16:25.52 |
| ray_laptop | henrys: where do we put private repos | 16:25.55 |
| | ? | 16:25.57 |
| Robin_Watts | ray_laptop: Git or svn? | 16:26.20 |
| | We have no private git repos currently. | 16:26.28 |
| henrys | ray_laptop: there aren't private AFPL, right? | 16:26.37 |
| ray_laptop | henrys: I am uploading the fonts to /home/ray/public | 16:26.38 |
| Robin_Watts | but adding a directory in the 'tests_private' svn repo is easy enough | 16:26.48 |
| ray_laptop | henrys: AFAIK these are NOT AFPL. Just available for Artifex to license to customers | 16:27.12 |
| henrys | ray_laptop: oh okay then private. | 16:27.33 |
| chrisl | henrys: at first glance, the 136 font set are still lacking glyphs compared to the PCL font set - I need to check more comprehensively, though | 16:32.17 |
| ray_laptop | chrisl: the 136 T1's that I had have finished uploading. I don't know if what you have is the same. | 16:32.58 |
| | casper:/home/ray/public/urw136.t1 | 16:33.25 |
| chrisl | ray_laptop: version 1.10, copyright 2006? | 16:33.33 |
| henrys | chrisl: 691213 this should be deja vu'ish | 16:34.21 |
| chrisl | henrys: I know, but I've never actually looked at it | 16:35.12 |
| Robin_Watts | ray_laptop: New fixed version on robin/master | 16:36.06 |
| ray_laptop | chrisl: just looking at one of the set "a008003i", that's the version and date I have | 16:36.11 |
| chrisl | ray_laptop: yep, they are all the same version etc, so we're good | 16:36.36 |
| ray_laptop | henrys: chrisl: so who's going to put them into a repos ? | 16:37.12 |
| chrisl | ray_laptop: I only have the type 1's but I can add them tomorrow | 16:37.48 |
| henrys | chrisl:I have urw136 t1 and tt in my home directory and an old email to you telling you they are there but I don't remember much more than that. | 16:38.04 |
| | chrisl: is the repo man ;-) | 16:38.22 |
| ray_laptop | chrisl: the TTF's are up on casper now as well casper:/home/ray/public/urw136.ttf | 16:38.24 |
| chrisl | OKay, I'll put them somewhere appropriate tomorrow morning - I'm stopping soon | 16:38.54 |
| henrys | those should be the same as in my home directory on casper. I hope. | 16:38.55 |
| ray_laptop | chrisl: you should be able to just ln to them or cp them and do it on casper (avoiding another round of net delays) | 16:39.23 |
| | henrys: find . -exec cmp "{}" /home/ray/public/urw136.t1/"{}" \; | 16:40.55 |
| | henrys: might be worth checking to make sure yours aren't "new and improved" | 16:41.46 |
| Robin_Watts | ray_laptop: OK for me to push, or do you want to look over them again? | 16:45.25 |
| chrisl | ray_laptop, henrys: I'll check the versions before I put the fonts in a repo - really have to go now...... | 16:45.53 |
| henrys | chrisl: sounds good sorry to keep you | 16:46.12 |
| ray_laptop | Robin_Watts: No, OK to push (clean off your desk before the end of the day ;-) ) | 16:46.15 |
| Robin_Watts | Unleashed! Thanks ray. | 16:46.39 |
| chrisl | henrys: no problem - I don't usually have to rush off quite this early on Tuesdays, but today got fouled up.... | 16:49.32 |
| ray_laptop | my office is going to warm up a bit with all of those commits from Robin_Watts :-) | 16:51.16 |
| | Going to run an errand. bbiab | 16:52.01 |
| henrys | Robin_Watts: you can ask miles for a charitable donation from artifex for Musicke Companye. We have a fixed amount set aside for charities. | 16:53.09 |
| Robin_Watts | henrys: That's very nice of you, but we do quite well enough out of Miles as it is. | 16:53.38 |
| | The nice thing about easyfundraising.org.uk is that once you set it up, it's basically money for nothing. | 16:54.12 |
| henrys | he's contractually obligated to peter to give out x dollars per year to charities so he's not out anything just another charity might be out. | 16:54.46 |
| Robin_Watts | oh, wow. | 16:55.31 |
| henrys | bbiab - house showing. | 17:08.26 |
| Robin_Watts | http://techcrunch.com/2013/10/22/apple-ipad-live-blog/ | 17:20.14 |
| ray_laptop | Miles used to send out requests to staff for "favorite charities" around Dec. Haven't seen one in a while, tho' | 17:22.52 |
| Robin_Watts | New OS X update (Mavericks) will be free. | 17:24.20 |
| | free to upgrade either from Mountain Lion or later. And it's available today. | 17:24.53 |
| Robin_Watts | watches the internet crash... | 17:25.00 |
| | ray_laptop, henrys: They have bent the tiff devices too... | 17:34.55 |
| | and they've bent the spot handling functions. | 17:57.34 |
| | mvrhel_laptop: You here? | 18:07.54 |
| mvrhel_laptop | I am. Fixing 694731 | 18:08.33 |
| | surprised to find this | 18:08.38 |
| | oh crap. I updated to windows 8.1 and now vmware needs to be reinstalled for some reason | 18:10.44 |
| Robin_Watts | mvrhel_laptop: So, 801 have extended the spot color mapping functions. | 18:10.51 |
| | as well as gray, rgb and cmyk, they have an additional one too. | 18:11.08 |
| | Is this them doing something the wrong way? | 18:12.08 |
| | Or are they running up against a design constraint in gs ? | 18:12.22 |
| mvrhel_laptop | I don't know what the question is | 18:13.03 |
| Robin_Watts | mvrhel_laptop: They've extended the core of gs to cope with additional spot color mapping functions. | 18:13.33 |
| mvrhel_laptop | I also don't know what they want to do for color management (if any) | 18:13.34 |
| Robin_Watts | Is there a better way for them to be doing that? | 18:13.49 |
| | Essentially, we'd like them to keep their hands and feet in the car at all times. | 18:14.07 |
| mvrhel_laptop | well, to me, the best way is to assign a 5 color icc profile to their device | 18:14.23 |
| | I don't know though how they are generating the extra color though | 18:14.41 |
| Robin_Watts | It looks to me like they've copied the devn device and have hacked on it. | 18:15.24 |
| ray_laptop | They've also built on old code that had the compressed_color crap in | 18:16.08 |
| Robin_Watts | I thought the devn device was an internal one that device authors wouldn't touch | 18:16.12 |
| mvrhel_laptop | Robin_Watts: for example, tiffsep and psdcmyk both handle n-color ICC profile | 18:16.14 |
| Robin_Watts | ray_laptop: Right. | 18:16.23 |
| | ray_laptop: That's exactly the code I was talking about that came from the devn stuff I think. | 18:16.48 |
| mvrhel_laptop | ick. they really should have used tiffsep or psdcmyk as the sample device | 18:16.48 |
| ray_laptop | That's the FIRST thing to rip out. They don't need it (or want it since they need planes anyway) | 18:16.51 |
| mvrhel_laptop | even better for using tiffsep or psdcmyk as the prototype device | 18:17.10 |
| Robin_Watts | They have done their own tiff device too by bending one of ours. | 18:17.30 |
| | ray_laptop: Ah. process_page with planes... hmm... :( | 18:17.46 |
| mvrhel_laptop | Robin_Watts: is doing the new process_page slow when you have planes? | 18:21.56 |
| Robin_Watts | mvrhel_laptop: I've not tried doing planes. | 18:22.09 |
| | It might be fine | 18:22.13 |
| mvrhel_laptop | ok | 18:22.16 |
| Robin_Watts | It should be fine I think. | 18:22.29 |
| | but until I've tested it I won't feel confident :) | 18:22.38 |
| mvrhel_laptop | I need to reboot | 18:23.10 |
| | Hyper-V vs. VMware fun again | 18:23.47 |
| Robin_Watts | I had hoped I could pull in their device and just rejig it, but either I need to bend gs 9.10 in the same way they have bent 9.07, or I need to somehow fix it so I don't need to bend it. | 18:23.55 |
| | mvrhel_laptop: Joy. | 18:24.00 |
| mvrhel_laptop | brb | 18:24.06 |
| | and hyperV is again disabled. need to upgrade vmware though | 18:30.50 |
| | so Robin_Watts they really should not need to make changes in the devn device | 18:31.40 |
| | to have 5 color support | 18:32.07 |
| Robin_Watts | mvrhel_laptop: OK. Are the color_mapping_procs basically hangovers from pre-ICC color support ? | 18:32.09 |
| mvrhel_laptop | yes. exactly | 18:32.48 |
| | wife needs me for something now. i think lunch. | 18:33.05 |
| | bbiab | 18:33.08 |
| Robin_Watts | Ok, so it sounds to me like there needs to be a separate discussion with them persuading them to move to ICC based working. | 18:33.28 |
| mvrhel_laptop | ok back | 18:38.07 |
| | Robin_Watts: yes that is what I would recommend. | 18:38.20 |
| Robin_Watts | ok, so I'm not sure where that leaves me... | 18:38.52 |
| mvrhel_laptop | what is it that you have to accomplish? | 18:39.51 |
| ray_laptop | mvrhel_laptop: we are trying to keep their customization corralled in their device code | 18:40.17 |
| mvrhel_laptop | right | 18:40.25 |
| ray_laptop | rather than peppering the library code with stuff | 18:40.45 |
| mvrhel_laptop | yes | 18:40.50 |
| | I don't know what all they have done, but it would seem that the tiffsep device would work as prototype device and go from there | 18:41.20 |
| Robin_Watts | mvrhel_laptop: Well, the first thing I was hoping to accomplish was to pull the modifications they had done within the clist threading stuff back into their device. | 18:42.11 |
| | using process_page. | 18:42.18 |
| | I guess I could rebend 9.10 in the same way that they have done. | 18:42.39 |
| | and then pull that back in. | 18:42.47 |
| | And then after we have had discussions with them over ICC I can pull that out. | 18:43.09 |
| | Or I can just reimplement their device from scratch. | 18:43.22 |
| mvrhel_laptop | I think the later may be easier | 18:43.31 |
| ray_laptop | Robin_Watts: except starting from scratch may tweak some noses | 18:45.19 |
| Robin_Watts | ray_laptop: Indeed. | 18:45.31 |
| | But honestly, duplicating all the devn stuff is just bonkers | 18:45.50 |
| ray_laptop | the culture is sensitive to maintaining "face" | 18:45.53 |
| Robin_Watts | We would be careful not to say "we were appalled by your code so rewrote it" | 18:46.26 |
| ray_laptop | Robin_Watts: agreed. so "simplifying" it, might fly if there are little snippets of their code you can leave in :-) | 18:46.31 |
| mvrhel_laptop | right | 18:46.55 |
| Robin_Watts | We would say something like "to test our new code structure, we implemented a new device" | 18:47.20 |
| ray_laptop | Robin_Watts: right. "That attempts to do what your previous code did, using the new methods" | 18:57.19 |
| Robin_Watts | ray_laptop: Right. | 18:57.28 |
| ray_laptop | Robin_Watts: "We think this will make it much easier for you to move forward with future updates to the graphics library with less work involved in moving to a later release" | 18:58.54 |
| Robin_Watts | ray_laptop: Right. We can all work on the exact wording and polish it. | 18:59.15 |
| | I'm sure Takane-san can help us avoid ruffling feathers here. | 18:59.32 |
| ray_laptop | would be nice to get Takena-san involved in explaining it | 18:59.37 |
| mvrhel_laptop | yes. definitely | 18:59.44 |
| Robin_Watts | I wish I could understand how this 5th component gets used. | 19:01.14 |
| ray_laptop | I think it gets used to enhance the gamut, but am not sure | 19:01.40 |
| | but they could have a 5 component device ICC profile without needing a named spot color | 19:02.06 |
| | unless they are trying to allow for host color correction | 19:02.27 |
| Robin_Watts | ray_laptop: That's what mvrhel_laptop was saying I think. | 19:02.33 |
| | but we're pushing the gamut of my understanding here :) | 19:02.51 |
| ray_laptop | I just the compress what I'm hearing to fit within the gamut of my understanding ;-) | 19:03.46 |
| Robin_Watts | ray_laptop: For me that involves a large degree of information loss when dealing with color science. | 19:04.36 |
| ray_laptop | henrys: welcome back to having power :-) | 19:06.17 |
| Robin_Watts | Is 801 using postscript, PCL or PDF? | 19:06.22 |
| ray_laptop | Robin_Watts: yes -- all 3 | 19:06.30 |
| | and maybe even XPS | 19:06.38 |
| Robin_Watts | OK, so presumably they could get access to the 5th colorant by specifying it directly in PS or PDF. | 19:07.07 |
| ray_laptop | Robin_Watts: yes. That's what they would do for host based color correction -- send CMYK+5th color data | 19:07.51 |
| | I don't know what they do in PCL land (that was henrys' headache) | 19:08.43 |
| henrys | the use the 5th in pcl as well. | 19:08.57 |
| Robin_Watts | But if that's the only way to access it, then we might as well just do a planar device. | 19:09.02 |
| henrys | ray_laptop:I only lost power for a few minutes - I was away for a house showing. | 19:09.33 |
| Robin_Watts | Presumably there must be some 'magic' somewhere (in the pre-ICC code) that says how to convert from one of the other colorspaces to CMYK+Octarine | 19:09.52 |
| ray_laptop | Robin_Watts: even with a 5 component ICC profile, what goes into the render buffer(s) is after the ICC mapping | 19:10.02 |
| | Robin_Watts: well, luckily, they never started with pre-ICC code. I think 9.07 was their initial port | 19:11.07 |
| henrys | Robin_Watts: there is a command line in the read me for the pcl stuff I looked at - using their profile many simple rob values are mapped to 5 colors | 19:11.11 |
| Robin_Watts | henrys: Ah, ok. | 19:11.25 |
| henrys | s/rob/rgb | 19:11.28 |
| Robin_Watts | So, they do have a 5 color icc thing. | 19:11.47 |
| | So I'm really confused as to why they felt the need to extend the gs spot color functions then. | 19:12.03 |
| henrys | see the readme in the top level. | 19:12.33 |
| ray_laptop | Robin_Watts: they would need that for PS or PDF that wanted to paint CMYK+5th directly | 19:12.35 |
| | a 5 component DeviceN space woud let them do that | 19:13.10 |
| | henrys: that Readme only addresses the "normal" mode of letting the OutputProfile generate the 5 components. Was there something else that they gave that needed the device to present 5 compnents (support DeviceN) ? | 19:16.52 |
| henrys | there device is 5 components but I don't know if it don't know how thorough it is. | 19:18.10 |
| | try that again: their device is 5 components | 19:18.46 |
| ray_laptop | henrys: you can have 40-bit output colors (5 components) that looks to the graphics lib like a CMYK device. | 19:19.43 |
| | henrys: what it wouldn't let you do is _directly_ control the 5th component. It would only be generated by the OutputICCProfile | 19:20.19 |
| Robin_Watts | ray_laptop: I could imagine that they would want to allow direct access to the separations from PS and PDF. | 19:20.30 |
| ray_laptop | mvrhel_laptop: speak up if I'm spouting gibbereish | 19:20.33 |
| Robin_Watts | but I don't see why they've had to clone the devn device to achieve that. | 19:20.44 |
| | The tiff devices manage to allow extra properly addressable spot colors without having to extend the core of gs, right? | 19:21.35 |
| mvrhel_laptop | back from lunch | 19:21.38 |
| henrys | well gdevXXXX.c is a 5 component device. ray_laptop: probably good if you review that source as your expertise will likely be needed. | 19:21.48 |
| ray_laptop | Robin_Watts: you have to start with some devn capable device to allow direct access to the separations, but as mvrhel_laptop said, starting from tiffsep or psdcmyk is cleaner | 19:21.48 |
| | henrys: I have looked at it, but I just had some lunch and don't want to look at it again just now on a full stomach | 19:22.31 |
| | ;-) | 19:22.37 |
| henrys | ;-) | 19:22.40 |
| Robin_Watts | ok, so I'm basically done for the day. I'll start with a reimplementation based on psdcmyk or something like that tomorrow. | 19:23.09 |
| ray_laptop | Robin_Watts: OK. Thanks for doing it. | 19:23.45 |
| mvrhel_laptop | so with tiffsep and psdcmyk, you can specify on the command line the names of the colorants in the icc profile (if it is deviceN). If the source file encounters those, they pass through. If instead the source color was rgb or cmyk it gets mapped to the N-colors using the profile | 19:25.23 |
| | not sure if that was super clear | 19:25.44 |
| | basically, the extra spot color can pass through and will be place in the same planar data as that generated by the icc profile assuming the name of the icc profile colorants were specified | 19:27.15 |
| ray_laptop | mvrhel_laptop: sounds like the best of both worlds | 19:27.57 |
| mvrhel_laptop | hmm I wonder why I got so many timeouts on my cluster push | 19:28.34 |
| ray_laptop | so their ICC profile can generate 5 colors, or a DeviceN/Separation aware file can diddle with all 5 colorants | 19:28.38 |
| mvrhel_laptop | ray_laptop: yes | 19:28.49 |
| ray_laptop | bbiab. Have to wait for my clusterpush anyway | 19:29.23 |
| mvrhel_laptop | bbiab | 21:34.33 |
| | Forward 1 day (to 2013/10/23)>>> | |
IRC Logs