| <<<Back 1 day (to 2015/09/23) | 20150924 |
chrisl | Robin_Watts: top commit in my ghostpdl repo - fix for the downscaler crash | 10:06.37 |
jjs_abb | Hi all, first time on, I've been struggling with image inserting. I want a client to be able to change the logo on some documentation, so I'd like to avoid having to convert to hardcoded postscript. I tried viewJPEG which ships with gs, but couldn't work out how to size/arrange the image on a page, anybody have any pointers? | 10:19.15 |
| Any/all help much appreciated | 10:19.36 |
chrisl | jjs_abb: that's not really what Ghostscript is for - you should edit the original document | 10:21.44 |
kens | jjs_abb : I'm not sure how you think viewjpeg will help you | 10:23.50 |
| I'm also not clear on exactly what you are starting weith and how you want to alter it | 10:24.41 |
Robin_Watts | chrisl: Ok. Can't immediately see how that would cause the reported problem, but if it fixes it, great! | 10:29.44 |
| Thanks for that. | 10:30.23 |
chrisl | Robin_Watts: if you look at gx_downscaler_init_planar(), it only allocates the interim buffer if upfactor > 1 so in gx_downscaler_get_bits_rectangle() using "if (upfactor)" means we try to use the buffer that doesn't exist | 10:31.53 |
Robin_Watts | Right, but that would suggest it should crash in the upfactor = 1 case. | 10:32.22 |
| Where the bug says that upfactor 1 works, but 2,3,4 etc don't. | 10:32.33 |
kens | Robin_Watts : the guy on gs-devel grumbling that gximono. c won't compile, that seems to be your commit 'special case the spp_out == 1 case'. But I don't understand the code well enough to know what he's talking about. | 10:33.06 |
chrisl | *DownscaleFactor* 1 works, | 10:33.09 |
kens | Actually, I may be wrong there | 10:33.39 |
chrisl | I assumed it was Ray's | 10:33.54 |
kens | So did I | 10:33.59 |
| Yeah I thnk I'm confusing myself | 10:34.30 |
| Its not Robin's | 10:34.36 |
chrisl | I also think his suggested fix is spot on | 10:35.00 |
kens | Well the code certainly looks dodgy to me | 10:35.21 |
chrisl | I looked at how the color cache gets setup | 10:35.46 |
kens | AH OK you're way ahead of me then | 10:36.00 |
chrisl | Frankly, I'm astonished it doesn't cause a crash the way it is just now | 10:36.07 |
kens | Well that's pretty much what I was thinking yes | 10:36.21 |
| WHat's thre now just looks wrong | 10:36.27 |
chrisl | I'd already clusterpushed what he suggested, and it seems to be okay | 10:36.48 |
kens | OK then I guess we go with that. | 10:37.02 |
jjs_abb | chris1: thanks for your help. I moved the viewJPG code into my file, and thought it would be a straightforward way to display the image from within the file, but it looks like I've grasped the wrong end of the stick. Is there an accepted way to display an image within a document in postscript without prior conversion? | 10:37.04 |
kens | You cannot take an image file and add it to a PostScript program | 10:37.35 |
| You can add image data, but not an image *file* | 10:37.50 |
| viewjpeg.ps simply does the job of converting the JPEG image file into an acceptable image data format for PostScript, and prints the resulting image | 10:38.17 |
chrisl | You *could* use viewjpeg.ps as a template for reading image data out of a JPEG file - but working out the positioning and scaling to accurately place it in a document is going to be challenging | 10:39.30 |
jjs_abb | kens: ok, I guessed that was the only logical way to do it, so I guess I need to use/modify a converter to inject the image data into my document? | 10:40.30 |
kens | I have no idea, what do you mean by 'your document' ? | 10:40.53 |
| PostScript programs aren't 'documents', they ar eprograms | 10:41.11 |
jjs_abb | postscript file, apologies, I've learnt the tiny bit I know on the web | 10:41.27 |
kens | OK then that's a PostScript *program* | 10:41.40 |
| If you want to change a program, you need to learn to write code in the programming languuage | 10:41.56 |
| In ths case, PostScript | 10:42.04 |
| Alternatively, you could create an EPS file from an image file, and inser the EPS | 10:42.37 |
| EPS = Encapsulated PostScript | 10:42.53 |
Robin_Watts | chrisl: If you've tested the 1,2,3 cases and they now all work, then great. It does sound like you've found a problem. | 10:42.55 |
chrisl | Robin_Watts: I did test them, and even looked at the output ;-) | 10:43.28 |
Robin_Watts | Wooooah. That's above and beyond :) | 10:43.44 |
kens | jjs_abb : but as chrisl correctly says, the correct way to deal with this is to go back to the original source, modify the source document, and recreate the PostScript program. | 10:43.56 |
jjs_abb | Sounds like it, I was just checking to see if I could use the small amount of postscript I know (basic layout commands) to do what I want. The EPS is how I'm doing it for the single logo at the moment, not quite as flexible as I wanted though. | 10:44.43 |
kens | Unless you re pretty good at PostScript programming, altering a program is difficult. | 10:45.15 |
| Best to recreate it | 10:45.20 |
| chrisl, I can now alter the PDF Document info with a pdfmark expressed in PJL :-) | 10:45.50 |
chrisl | kens: cool! | 10:46.00 |
kens | Yeah, pretty happy with that now. | 10:46.13 |
jjs_abb | Thanks for all your help guys, I think I'll go for the EPS route. Guess I'll be learning a lot more postscript in the near future, if you know of any good books/resources then I'd be very grateful for pointers | 10:46.27 |
chrisl | jjs_abb: you have the PLRM I suppose? | 10:46.42 |
kens | I wouldn't reccomend trying to build a complex Table Of Contents with it, but the pdfmark stuff in PJL seems to be pretty good. Now for ditillerparams :-( | 10:46.45 |
| I'd reccomend John Deubert's acument training journal, as well as the Blue and Green books | 10:47.17 |
| Blue book: | 10:47.48 |
| http://www-cdf.fnal.gov/offline/PostScript/BLUEBOOK.PDF | 10:47.49 |
jjs_abb | chris1: Yep, it's been quite useful, if a little dense to begin with! | 10:47.49 |
chrisl | jjs_abb: it is one of the better manuals I've used! | 10:48.07 |
kens | Green Book: | 10:48.21 |
| http://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF | 10:48.22 |
| John Deubert's journal: | 10:48.50 |
| http://www.acumentraining.com/acumenjournal.html | 10:48.51 |
jjs_abb | kens: thanks! | 10:49.00 |
| chris1: I guess I've just had the luxury of having knowlegable people around to get me started on other languages | 10:49.48 |
chrisl | jjs_abb: the biggest challenge for most people is the stack based nature of PS | 10:51.19 |
henrys | Robin_Watts, chrisl great you guys have such a a deep understanding of the scaling code ;-) | 13:02.29 |
chrisl | henrys: press random buttons until it works...... | 13:03.07 |
kens | henrys I just pushed the latest code for extending PJL to my local repo: | 13:03.32 |
| http://git.ghostscript.com/?p=user/ken/ghostpdl.git;a=shortlog;h=refs/heads/dynamic_PJL_allocs | 13:03.32 |
Robin_Watts | henrys: I wrote the downscaler, but it's all fallen out of cache. It'll be on my office floor somewhere... | 13:03.35 |
kens | With that, I can make a PDF/A-1b file directly from PCL, and also add Document Info to the resulting PDF file. I expect other pdfmarsk to work as well, though I don;t reccomend trying to do extensive work with them, like a TOC | 13:04.17 |
henrys | Robin_Watts: or you've Kernighaned it: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? | 13:06.04 |
Robin_Watts | henrys: I'm not that smart to start with. | 13:06.26 |
tor8 | henrys: font meeting now or in an hour? my timezones are all confused. | 13:08.02 |
kens | I thought 2 hours ? | 13:08.25 |
chrisl | Yeh, I thought two hours | 13:08.38 |
henrys | 2 hours | 13:08.54 |
| but I don't care if you guys are ready we can do it early. | 13:09.07 |
kens | Maybe Ray wants to contribute as well ? | 13:09.30 |
henrys | kens: having problems reaching the repo is git.ghostscript.com good for you? | 13:09.36 |
| nvm working now | 13:09.51 |
kens | henrys it was 2 minutes ago, let me try again | 13:09.52 |
| Oh OK | 13:09.56 |
chrisl | henrys: I've been getting occasional gateway timeouts all day | 13:10.20 |
henrys | kens: yea good point | 13:10.25 |
kens | henrys if you want to try it out I can send you a PJL file and a sample command line | 13:10.26 |
chrisl | And my cluster job just aborted...... | 13:10.53 |
tor8 | henrys: I just wanted to say that I'd like a better default font for EPUB than Times, | 13:10.58 |
kens | connectivity problems then I guess | 13:11.03 |
tor8 | if we can get them to extend a decent looking font like century schoolbook with the same character sets as we got for the base 14 that'd be great | 13:11.10 |
henrys | kens: put it in the cluster should fail now and pass later right? | 13:11.12 |
kens | Err, sorry, didn't follow.... | 13:11.34 |
| THat code passes cluster testing | 13:11.43 |
| And there are jopbs which make us of PJL in the cluster tests | 13:12.02 |
henrys | kens: I thought you had new PJL strings that would not be supported now but will be supported when the code is committed to master. | 13:13.37 |
| kens: anyway just send me the test too | 13:14.27 |
kens | There is one new PJL string define 'PDFMARK' which takes a "" delimited string of arguments. THose get processed into multple pdfmark operations and sent via putdeviceparams to pdfwrite. | 13:14.37 |
| OK I'll send the setup file and command line | 13:14.47 |
henrys | kens: don't you want this to work wit PXL and XPS? | 13:15.39 |
kens | It works with PXL, XPS would be nce but I haven't tried to get that working | 13:16.10 |
henrys | kens: I just saw all the code in pcjob.c ... | 13:17.24 |
kens | Yes indeed, seems to work with PXL as well though | 13:18.10 |
| One of the files I tested was a PXL file | 13:18.22 |
henrys | by virtue of xl and pcl sharing devices and pcl is started first. | 13:18.31 |
kens | I guess so, there didn't seem to be an equivalent place to do the work in PXL, but I only started in on that ths morning | 13:19.03 |
| So I might have missed it | 13:19.13 |
chrisl | PCL and PXL have separate methods for setting stuff from PJL?? Really?? | 13:19.38 |
kens | Well I couldn't see anywhere in the PXL interpreter to set stuff rom PJL, but like I say, I could have missed it | 13:20.05 |
henrys | well if it were set with the other options in plmain.c you'd get xps automatically but all that stuff is changing | 13:20.11 |
kens | I assumed it was meant to work this way..... | 13:20.27 |
| OK henrys mail gone to you | 13:20.50 |
| You can let me know what I missed :-) | 13:21.03 |
chrisl | It should be pretty easy to add PJL to the XPS build, if it's not there already.... it already includes pl.dev | 13:21.17 |
kens | Ah, obviously this won't do anythign useful without the code in my repo | 13:21.28 |
henrys | chrisl: pjl is in the xps build now. | 13:22.37 |
kens | Then I guess it ought to work, I could give it a try. | 13:22.52 |
kens | goes off to buuild gxps | 13:23.09 |
henrys | kens did the code in pcl only, it works for pxl because pcl and pxl share a device | 13:23.11 |
kens | If you can point me at a shared area I'm happy. Or tell me where the equivalent work is done in the PXL interpreter | 13:23.53 |
henrys | kens: I'm not sure if chrisl changed xps to use a different device, if he didn't then it will work. | 13:24.02 |
| kens: but still rather peculiar the code sits in pcjob.c | 13:24.18 |
chrisl | henrys: xps is standalone, so it can't share a device at all | 13:24.53 |
kens | Well I had ot put it somewhere :-) I figuresd I was going to need to find 3 places for this, one each for PCL, PXL and XPS | 13:24.57 |
| So I started with PCL and then discovered it 'just worked' for PXL but that was only a few hours back when I started poking at PXL for the first time. | 13:25.36 |
henrys | kens: pxl only collects and stores state in strings, then the languages run and query XL | 13:25.47 |
kens | Umm, you mean PJL there ? | 13:26.08 |
henrys | kens: I do yes pjl | 13:26.21 |
chrisl | Which still leaves the open question of *where* PXL does that | 13:26.36 |
kens | Yeah that's the way I saw it. But I couldn't see where PXL queried the PJL | 13:26.38 |
marcosw | chrisl: sorry to do this, but I found an issue with rc1: http://bugs.ghostscript.com/show_bug.cgi?id=696223 | 13:26.47 |
| itâs a regression from a few weeks ago, so I should have caught it earlier. | 13:26.59 |
chrisl | marcosw: I'm just testing a fix for that - someone else found it earlier | 13:27.16 |
henrys | search for pjl_ in pxsessio.c, but good god I don't want to duplicate this everywhere. | 13:27.28 |
kens | Oh no, we donn't want to duplicate it, it needs to go somewhere more central | 13:28.02 |
chrisl | Well, logically the guts can go somewhere in pl and then each language just calls it | 13:28.14 |
kens | Exxcept that's not how PJL Is handled now | 13:28.32 |
henrys | kens: it depends does it need a graphics state | 13:28.36 |
| ? | 13:28.43 |
| or just a device | 13:28.51 |
kens | I don't thnk it requires a graphics state, but it does need the device to be running | 13:29.02 |
| Oh drat, I was on the wrong branch :-( | 13:29.50 |
kens | curses and rebuilds | 13:29.58 |
| gs_state_putdeviceparams needs a gstate, but I used that because it was what was used in the PCL code, it should be possible to just use the device thoguh, I think that routine only uses the gstate for the device | 13:31.01 |
chrisl | I still think having a common method in "pl" is going to be the most sensible solution | 13:32.25 |
kens | Yes, it only uses the device from the gstate, could use gs_putdeviceparams() instead | 13:32.33 |
henrys | it should go in pl_main_universe_select() | 13:33.04 |
kens | I thnk that's a problem | 13:33.22 |
henrys | not "in it" but that's where the gs_putdeviceparams() is | 13:33.27 |
kens | Because the device isn't open | 13:33.29 |
henrys | kens: okay you need an open device? | 13:33.46 |
kens | I'm almost completely certain that won't work | 13:33.46 |
marcosw | chrisl: i wasnât sure how gs found he icc profiles with âdisable-compile-inits before 8fcea1f. they are stored in ./iccprofiles but itâs not necessary to specify that directory the command line whereas -IResource/Init is needed. | 13:33.54 |
kens | henrys, yes absolutely | 13:33.56 |
| None of thsi works unless the device is already opened | 13:34.35 |
chrisl | marcosw: it checks first in %rom% and then looks for "iccprofiles" as a sibiling of Resource - it's a bit hacky IMHO | 13:34.45 |
henrys | kens well after the ps_set_device() call in that same routine the device is open | 13:35.11 |
| sorry pl_set_device() | 13:35.23 |
chrisl | marcosw: TBH, I'm a bit baffled, because I definitely tested --disable-compile-inits after I made those changes.... | 13:35.48 |
kens | Well I was trying to follow the existing code, so doing PJL Processing at the time the existing code does PJL processing | 13:35.49 |
henrys | sigh all of this is changing though... | 13:36.05 |
kens | I figureed that yes | 13:36.13 |
| I don't have a problem with moving any of it, it was hte 'principle of least surprise' to try and keep it in the same place as all the other code that processes PJL | 13:36.55 |
| Actually that only works properly with PJL if I exercise the PCL interpreter, otherwise it doesn't | 13:38.31 |
| WHch I guess is to be expected | 13:38.44 |
henrys | kens: I'm fine with doing it in pcjob.c for now. | 13:39.30 |
kens | It does mean I'll have to do something similar in pxsessio.c as well though :-( | 13:39.52 |
| I'd *really* like to not duplicate ths code..... | 13:40.07 |
| Especially since I have more complex code to do in order to handle ditsillerparams :-( | 13:41.04 |
| I'l think about it some more | 13:41.17 |
chrisl | Does it just take a string and some method of reaching the device? | 13:41.46 |
kens | Not at the moment. | 13:41.59 |
| But I was thinking of that approach :-) | 13:42.06 |
| I could shift all the processing into pdfwrite and just pass the strings | 13:42.20 |
| With a special_op probably | 13:42.41 |
chrisl | Well, I'd prefer it in pl but you could equally put it in the graphics library | 13:43.02 |
kens | The 'problem' with putting it in pl is that the PJL code never sets anything, it just parses stuff out and passively supplies it to the other interpreters to deral with | 13:43.43 |
chrisl | So, you put the *code* in pl and each interpreter calls it | 13:44.07 |
| The logic is still driven from the language, but with common functions | 13:44.40 |
kens | Right now that's not how it works. CHanging it is, sort of, an API changem, and I'm not sure how Henry would feel about it. | 13:45.21 |
| If I put it in pdfwrite then I could make PCL/PXL/XPS do a simple one-line 'special_op' to pass the string and have p[dfwrite deal with it | 13:45.52 |
henrys | and why can't it be done exactly as device parameters are done on the command line? | 13:47.48 |
kens | Well for starters you cna't have dictionaries on the command line | 13:48.06 |
| At least, not without using the -c ... -f syntax to execute PostScript, which is a non-starter | 13:48.52 |
henrys | I just meant the settings not the parsing | 13:48.54 |
kens | Have you looked at the length of the settigns required ? | 13:49.11 |
| And I don't see how it would help | 13:49.31 |
| Because at the time the settings are parsed and acted upon, the device isn't open | 13:49.44 |
henrys | kens: the settings can be stored in gs_c_parameter_list crap and everything gets set later when the device is open. That's what happens today. | 13:51.23 |
kens | It didn't seem to be working that way when I looked into it. THe putdeviceparams was being called before the device was opened | 13:53.20 |
| If you call putdeviceparams with those parameters, and the device isn't open, then you get a crash | 13:53.57 |
henrys | kens: ah right there are two calls to gs_putdeviceparams() .... one open and another later after it's open if the parameters weren't see. | 13:54.57 |
| kens: ah right there are two calls to gs_putdeviceparams() .... one open and another later after it's open if the parameters weren't set. | 13:55.00 |
kens | That seems to be the case yes. | 13:55.14 |
| We cna live with setting the parameters twice, we can't handle setting them when the device isn't open | 13:55.30 |
henrys | the geometry params are kind of a pain to set after the device is open because that reallocates everything... | 13:55.30 |
| so I think it would be nice if we could somehow send the parameters with a closed device. | 13:56.15 |
kens | No, that's not at all possible | 13:56.24 |
| The structures we need to modify don't even exist until after the device is opeened (pdfwrite) | 13:56.41 |
henrys | kens: I meant just store the strings in the parameter list and you'd do all the work in pdfwrite | 13:57.15 |
kens | I don't understand. Those parameters are executed immediatley that they are sent to pdfwrite (liek all params), if the device isn't open then there are various structures which don;t exist, and if we try to access them then we will crash | 13:58.42 |
| Ths can't happen in the PostScript world, because these are PostScript operators, but in PCL/PJL it is possible, and we must make sure it doesn;t happen | 14:00.54 |
henrys | kens: I'm saying store the entire pdfmark what you have in pdfa.pjl in the parameter list as a string and do what you want with it later in pdfwrite. | 14:04.07 |
kens | Store it at which end ? THe device ? THat isn't really going to work | 14:04.42 |
henrys | as chrisl said you can pull all that code out of pcjob.c put in pl (separater file) and call it from pxsessio.c, pcjob.c and wherever xps does that business... | 14:19.49 |
kens | I don;t mind doign that, but it is somewhat of a departure from the existing PJL parsing code, whcih doesn't set anything | 14:20.25 |
henrys | pl does much more than pjl parsing, way too much ;-( | 14:21.14 |
kens | Like I said, mnore than happy to put the parsing somewhere central. | 14:21.39 |
chrisl | It's not really that big a departure, since it would all still be *driven* from the languages | 14:22.40 |
kens | I'll look for a more central location, it won't really affect the operation of the code in any significant way | 14:23.14 |
henrys | why don't you create plparams.[ch] add it. Then I can add other common pararameter stuff I factor out of the languages to that. | 14:23.19 |
kens | OK I can do that, and then let you refactor it to fit with your own changes. | 14:23.56 |
henrys | kens: then it should be trivial to get xps working as well. | 14:24.36 |
kens | Well, I hope so...... | 14:24.45 |
| I was going to look at that last | 14:24.52 |
chrisl | rayjj: something came up from the release candidate, I'm guessing it's a type: proposed fix: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=16b84931 | 14:44.59 |
rayjj | I just noticed in an email from "Silver" that the SO the Artifex version is still called picselwin32.lib. Is this ever going to change | 14:45.08 |
chrisl | rayjj: Oh, and good morning ;-) | 14:45.13 |
Robin_Watts | rayjj: We own 'picsel' now :) | 14:45.38 |
| I suspect it'll change for NUI. | 14:45.42 |
rayjj | chrisl: yep, that looks like a typo, and the fix looks OK. Do you know what regression diffs show up (i.e., have you run one)? If so, can you run a bmpcmp | 14:47.00 |
| chrisl: good morning to you, as well | 14:47.17 |
henrys | chrisl: I wonder if that rc should hang out a little longer than usual. | 14:47.19 |
rayjj | morning, Robin_Watts | 14:47.22 |
| chrisl: I'm surprised that testing didn't show that up -- I would have expected that several files show that | 14:48.11 |
chrisl | rayjj: the only diff on the cluster were also files that have been indeterminate since the halftone fixes went in, so hard to judge. They don't look any more or less wrong than before..... | 14:48.16 |
rayjj | chrisl: are there still indeterminate files (since I fixed 09-40) ? | 14:48.56 |
chrisl | rayjj: several | 14:49.03 |
kens | Oh yes | 14:49.03 |
rayjj | goes to look at recent regression runs... | 14:49.29 |
kens | Here's a few: | 14:49.39 |
| tests_private/pcl/pcl5cats/Subset/AC6ZHSC3.BIN.pbmraw.600.1 pcl bohrs kilometers | 14:49.39 |
| tests_private/pcl/pcl5cats/Subset/AC6ZISC3.BIN.pbmraw.600.1 pcl lines fermis | 14:49.39 |
| tests_private/pcl/pcl5cats/Subset/AC6ZKSC3.BIN.pbmraw.600.1 pcl i7 miles | 14:49.39 |
| tests_private/pcl/pcl5ccet/29-11.BIN.pbmraw.75.0 pcl lines macpro | 14:49.39 |
| tests_private/pcl/pcl5efts/fts.2291.pbmraw.600.1 pcl lines macpro | 14:49.40 |
| tests_private/xl/pcl6cet/c315.bin.pbmraw.75.0 pcl furlongs picas | 14:49.40 |
chrisl | Oh, and the files that showed differences on the cluster, *none* of them went through the code I changed in gximono.c | 14:49.59 |
| I was pretty disappointed, as I hoped that might be the source of the indeterminisms | 14:50.48 |
henrys | kens: did marcos valgrind those, are there bug? | 14:51.02 |
kens | henrys I don't htink so, no | 14:51.15 |
rayjj | chrisl: well, the fix to gsht.c was definitely leaving some areas uninitialized. | 14:52.09 |
| or rather, prior to the latest fix there were UMR's | 14:52.30 |
henrys | geez an indeterm in the pcl fts is bad. | 14:52.39 |
| oh but they are all pbmraw? so halftoning probably? | 14:53.44 |
chrisl | rayjj: anyway, the main thing just now is that you're okay with the gximono.c change - I'd like to get it on the release branch | 14:53.44 |
rayjj | chrisl: yes, please go ahead | 14:55.41 |
chrisl | Thanks | 14:55.46 |
tkamppeter | I am looking through the new gs 9.18. Have you really done away with libtrio now? | 14:55.57 |
chrisl | tkamppeter: yes | 14:56.20 |
tkamppeter | chrisl, thanks, great, one lib less in Ghostscript (or are there others added in 9.18?). | 14:57.48 |
chrisl | tkamppeter: no, trio removed, no new ones added | 14:58.04 |
rayjj | that new segfault bug looks serious enough to hold off the customer release (bug 696222). Do we want to hold off the AGPL release so we don't have two releases again ? | 14:58.44 |
kens | henrys yes, hal;ftoning in every case, which is why Ray's change introduced it originally (halftoning changes) and we'd hoped the later one would fix it | 14:58.59 |
chrisl | rayjj: I think depends on whether it's our problem , or luratech's | 14:59.25 |
rayjj | I'll have a look at those today, then | 14:59.31 |
kens | rayjj the 'good' thnk aout it is that many of them are different on every run | 15:00.23 |
rayjj | I'll have a look at the indeterminisms. | 15:00.24 |
kens | THe AC6 ones seem to be anyway | 15:00.40 |
rayjj | kens: I was able to detect the 09-40 issue by running a debug build with an without -Z@ | 15:00.59 |
kens | I'd have to guess its uninitialised memory again though | 15:01.01 |
rayjj | since -Z@ initializes memory to a specific value | 15:01.33 |
kens | That would probably do it | 15:01.41 |
chrisl | I did run a couple of files through valgrind, and didn't see a problem... *but* I noticed at least place where we memset a buffer to zeros in a debug build - kind of feel that's not ideal | 15:02.40 |
tkamppeter | chrisl, thanks. | 15:02.44 |
henrys | I don't think 696222 should block, they just reported it and it's not a regression | 15:02.47 |
| tor8: what font were you thinking of, and is it in our font collection now (sot, pcl, postscript and whatever else) | 15:03.36 |
| ? | 15:03.37 |
chrisl | What license do we have for the SOT fonts? | 15:03.59 |
henrys | oh of course we do want gpl for that font so that narrows the field quite a bit | 15:04.30 |
chrisl | I'd have thought one of the google fonts, or the newly free Adobe based ones would be a good default for epub | 15:05.25 |
henrys | tor8: I don't know if I can get GPL from URW | 15:05.29 |
tor8 | henrys: I was thinking of the Century Schoolbook family, if we can get it in GPL and with the same character set as our new Base 14 fonts | 15:05.56 |
| we have Century Schoolbook L in ghostscript | 15:06.35 |
| but that's not GPL and it's only got latin | 15:06.57 |
chrisl | It *is* GPL, but only has latin | 15:07.47 |
tor8 | chrisl: oh! I thought those were still AFPL. | 15:08.00 |
Robin_Watts | tor8:Have you looked at the SOT fonts? | 15:08.04 |
tor8 | Robin_Watts: I have not. | 15:08.08 |
chrisl | Robin_Watts: what's the license? | 15:08.15 |
henrys | chrisl I thought the pending order awaiting customer financing would be good enough ... URW wants to double the price for each font for GPL, I'll see what I can do with Miles on that. | 15:08.16 |
Robin_Watts | There are some LibreOffice fonts there that might do. | 15:08.45 |
rayjj | I have to run my son to school. bbiab | 15:08.48 |
Robin_Watts | chrisl: The libreoffice fonts are permissive enough, I think. | 15:08.57 |
chrisl | henrys: As I keep saying, I always felt that GPL for all the 35 was a long shot, but worth asking.... | 15:09.17 |
henrys | chrisl: they'll do it, I don't know if Miles will. | 15:09.35 |
chrisl | I'm actually surprised they even consider it. | 15:10.00 |
henrys | chrisl: for double the price... | 15:10.16 |
| really GPL has come to be frowned upon in the font universe these days | 15:10.41 |
| but better than AFPL | 15:11.01 |
chrisl | Would they be open to another font license? | 15:11.07 |
henrys | chrisl: definitely not | 15:11.29 |
tor8 | OFL is the most common font license I think, but I doubt they'd be willing to go that far | 15:11.39 |
| it's essentially a BSD license for fonts | 15:11.47 |
| chrisl: henrys: so these prices, are they for just licensing the existing fonts as GPL or extending the glyph coverage? | 15:12.20 |
chrisl | The existing fonts are GPL | 15:12.35 |
| The base 35, that is | 15:12.48 |
henrys | chrisl: so we have to consider the non latin improvements for all the other fonts that we haven't filled in yet. Is that worth it? | 15:13.25 |
tor8 | henrys: I would say that it'd be worth it for the four remaining font families in the base 35 set, if you're asking for a vote of hands mine are both up in the air :) | 15:14.25 |
chrisl | henrys: from an engineering perspective, I don't think so, no. From a marketing point of view - dunno | 15:14.30 |
henrys | tor8: I meant beyond the 35 | 15:14.50 |
tor8 | henrys: ah, so are we committed to doing greek and cyrillic for all the 35 already? | 15:15.14 |
chrisl | henrys: how many enquiries have we had to license the 136 PS3 fonts? | 15:15.27 |
henrys | tor8: well for the fonts that it makes sense to do it. | 15:16.00 |
tor8 | henrys: ah! so we may actually already have what I want. | 15:16.27 |
chrisl | tor8: but those won't be GPL | 15:16.44 |
| Only what we have now will be GPL | 15:17.02 |
tor8 | chrisl: so the greek+cyrillic base 35 won't be GPL? | 15:17.51 |
henrys | chrisl: I don't see how a potential printer customer ships with less than 136 | 15:17.52 |
| tor8: I don't know they will be double the price and I have to convince miles | 15:18.12 |
chrisl | henrys: many, many "Level 3" printers don't include the 136 fonts | 15:18.20 |
kens | That's a check box from the past | 15:18.31 |
| everyne embeds fotns these days | 15:18.38 |
chrisl | tor8: we'll have the base 35 with the current 3 font families with Greek and Cyrillic in GPL | 15:19.05 |
henrys | kens: we have the 136 now, the question is do we need to expand them, I think not | 15:19.51 |
tor8 | chrisl: okay. I'd like to add greek and cyrillic in GPL to the remaining 4 font families in the base 35 set. after that, I have no opinion. I doubt we need to expand anything beyond the base 35. | 15:20.12 |
kens | I would say as chrisl did, from an engineering POV defintely not | 15:20.14 |
| From a marketing perspective I would also say not, but people mat disagree | 15:20.42 |
henrys | obviously we don't have to worry about dingbats, symbol | 15:22.03 |
chrisl | henrys: I've seen Postscript printers that only ship with two multiple master fonts - rare, but it happens | 15:22.16 |
henrys | chrisl: I can assure you the marketing department will want to sport 136 | 15:22.48 |
| I believe it is in our literature | 15:23.15 |
chrisl | henrys: I can only speak from experience, and that is that, when told there will be cost involved, most are less keen on the idea | 15:23.40 |
henrys | anway are we missing anything to be compatible with a modern PS printer coverage wise in the base 35, other languages? | 15:24.10 |
chrisl | I don't think so, the problem was always PDF rather than Postscript | 15:24.43 |
henrys | okay so I guess we'll go with the order we already have and I'll try to get GPL | 15:26.15 |
| Robin_Watts: SOT font needs? | 15:26.38 |
Robin_Watts | henrys: As far as I am aware, we don't need anything more than we have. | 15:26.52 |
chrisl | There are a few other things I'd like for URW in terms of deliverables..... | 15:27.12 |
Robin_Watts | I mean, it'd be nice to be able to offer clones of every office font known to man, but realistically? That's not a goer. | 15:27.40 |
henrys | tor8: have you looked at epub fonts and seen what they support language wise? Is greek and cyrillic enough? | 15:27.51 |
| well looked at epub implementations like Apple's... | 15:28.16 |
Robin_Watts | Random thought; do we know what tool urw uses to create the fonts? Is it feasible to get the fonts in the source format, so that if we have to do editing ourselves in the future, we can ? | 15:28.32 |
| I mean, I hope we don't need that, but if urw are folding into GG, we might want to protect ourselves. | 15:28.59 |
| Are there other font foundries out there we could talk to? | 15:29.12 |
henrys | chrisl: if it's complicated an email is best, I'll likely screw it up otherwise ;-) | 15:29.15 |
chrisl | henrys: okay.... no problem | 15:29.27 |
henrys | Robin_Watts: no their internal format is private secret sauce stuff. | 15:30.00 |
| Robin_Watts: yeah I'll be talking to miles about that too, other font sources. We do have a few connections. | 15:30.55 |
chrisl | Getting GPL fonts from elsewhere is unlikely..... | 15:31.43 |
henrys | it would be interesting to see what the free community has as well, For example I imagine we could replace courier with Google's clone. | 15:32.12 |
kens | Robin_Watts : URW uses their own IKARUS system (or did) | 15:32.30 |
henrys | kens: who supplied GG fonts when you guys worked there? | 15:33.02 |
chrisl | I've been poking around, but I haven't found convincing alternatives for most the of the 35 fonts | 15:33.04 |
kens | henrys, Jaws used fontsw licenced from Stream | 15:33.21 |
| Harlequin used fotns from AGfa Monotype I htink | 15:33.36 |
chrisl | I thought HQN used Bitstream.... | 15:33.59 |
kens | Oh yeah, you may be right | 15:34.07 |
| Though I have a suspicion they used multiple sources for the 136 fonts | 15:34.27 |
chrisl | I suspect I know the answer to this but..... should we consider a pair of multiple master fonts, too? | 15:35.08 |
henrys | chrisl: when did you last study the open source 35 situation, google has been quite active recently, I've not been following other sources closely. | 15:35.17 |
chrisl | henrys: it's a while since I did a full sweep - but I had a hunt around earlier today for a Helvetica alternative, and came up empty. | 15:36.06 |
| I don't think it's worth the effort unless we can replace all the 35 fonts | 15:36.42 |
henrys | chrisl: agreed | 15:37.05 |
| and we can always draw our own ;-) | 15:39.10 |
chrisl | Go ahead, we'll review your work! | 15:39.35 |
mvrhel_laptop | I was telling my son about all of this. he said he wants to start a font company... | 15:39.44 |
henrys | I did lineprinter for pcl ;-) | 15:39.50 |
| but that's an easy one | 15:39.58 |
Robin_Watts | mvrhel_laptop: Change the fonts on his machine to comic sans. | 15:40.22 |
mvrhel_laptop | :) | 15:40.28 |
henrys | I did want artifex to buy urw when we had the chance, but I understand Miles not wanting to get into that mess. | 15:40.52 |
Robin_Watts | As I flew out to a staff meeting I saw a "Typography Monthly" magazine at Heathrow. | 15:41.00 |
| I was wondering just how big the circulation to that could possibly be. | 15:41.20 |
kens | Have you watched 'Have I Got News For You' ? | 15:41.37 |
mvrhel_laptop | This article which I read last year in the economist is interesting | 15:42.25 |
| http://www.economist.com/news/international/21605924-fast-changing-market-fonts-ways-words | 15:42.27 |
chrisl | The problem is, the font market is now quite vibrant, *but* I doubt there'd be much interest in recreating type faces from days past | 15:43.29 |
henrys | chrisl: I am surprised google hasn't put out a helvetica alternative... surprising | 15:44.12 |
chrisl | And let's face it, you're not going get rich licensing to loads of Postscript vendors these days! | 15:44.16 |
| henrys: I will check more thoroughly - when I'm not being distracted by release related stuff | 15:44.44 |
henrys | rayjj: have a look at the logs and let me know if you have more to add about the fonts, thanks. | 15:44.47 |
| chrisl: your multiple master request got crickets so I assume we're good there. | 15:45.16 |
chrisl | henrys: that was the answer I expected! | 15:45.36 |
| We should be able to get replacements for Times New Roman and Courier - but I haven't actually tested how good they are | 15:48.07 |
rayjj | henrys: no, I don't really have anything to add on fonts | 15:48.21 |
chrisl | henrys: I guess we could reiterate the request from the open source world about the wording of the embedding exemption - getting it changed to allow formats other than PS and PDF | 15:49.21 |
henrys | or marcosw do you have anything? I know you are a font afficionado | 15:50.01 |
| chrisl: good point I'll add that. | 15:50.09 |
| chrisl: the embedded exemption | 15:50.27 |
rayjj | chrisl: we have the Stream MM fonts. The problem is the rest of it -- coming up with the design vectors to approximate the target font | 15:50.37 |
chrisl | rayjj: Oh, I didn't realise that.... | 15:51.03 |
rayjj | chrisl: that we had the Stream fonts, or that just having the MM font is 20% of the issue ? | 15:51.52 |
chrisl | rayjj: that we had the Stream MM fonts | 15:52.15 |
kens | Yeah but we've never come up with any metrics for them, I've never had the time. | 15:53.28 |
rayjj | ideally, we'd use the available AFM for the target fonts and be able to come up with reasonable design params, but then it takes "eyeballs" to tweak them to make sure they are reasonable | 15:53.36 |
kens | MM fonts will never be as good as the real fonts, though they can make decent fallbacks | 15:54.05 |
rayjj | kens: right. Although I don't know what glyph coverage we have in the MM fonts we have | 15:54.31 |
kens | No idea :) | 15:54.38 |
chrisl | Anyway, that's all I had wrt to URW | 15:54.41 |
| And I have to head off..... | 15:58.11 |
rayjj | darn. The -Z@ trick didn't work with the PCL fts file. :-( | 16:27.34 |
| at least with tests_private/pcl/pcl5efts/fts.2291 | 16:28.04 |
Robin_Watts | rayjj: Try a memento build? That fills with a different value :) | 16:28.37 |
henrys | rayjj: are you running 600, clist? | 16:29.19 |
rayjj | henrys: yes | 16:29.32 |
| first I'll try repeated runs on peeves and see if I can trip it | 16:29.56 |
| and compare the results from peeves to the results from windows | 16:30.12 |
henrys | rayjj: 600 doesn't do clist for me, 1200 does | 16:34.27 |
| rayjj: and with 1200 I get lots of valgrind problems | 16:36.07 |
| from the clist | 16:36.12 |
| rayjj: I didn't fool with maxbitmap | 16:40.00 |
rayjj | henrys: sorry, I was not paying attn. I used -dMaxBitmap=10000 (as the cluster tests do) | 17:05.09 |
| and verified with -Z: (on a debug build) that I was getting clist mde | 17:05.30 |
| Robin_Watts: and if I can't find anything with other testing, I'll try a memento build | 17:06.05 |
fdncred | i'm using mudraw.exe v1.7a 64-bit. there used to be an option -x (i think) to generate xml of how the document would be rendered. is there another option in this version that does something similar? | 17:15.11 |
Robin_Watts | fndcred: Urm... we haven't removed that option. It might have been renamed... | 17:18.57 |
| Run mudraw with no params, and it'll list the options. | 17:20.13 |
| You want the one that says "show display list" or something. | 17:20.27 |
fdncred | looking | 17:21.02 |
| -D disable use of display list | 17:21.29 |
| that's the only thing i see | 17:21.37 |
Robin_Watts | ok, in the current version, we use mutool draw instead of mudraw. | 17:25.51 |
| and then it would be: mutool draw -F trace | 17:26.14 |
fdncred | i'm sorry to say that mutool doesn't take those params | 17:28.04 |
| it just returns the help string | 17:28.10 |
Robin_Watts | fdncred: OK, so that came in after 1.7a then. | 17:29.57 |
| Try: mudraw -F trace ? | 17:30.03 |
fdncred | i just get the standard help screen with clean, extract, info, pages, poster, show | 17:30.51 |
Robin_Watts | fdncred: No, mudraw -F trace, not mutool draw -F trace | 17:31.14 |
fdncred | oh sorry, i thought you said mutool. mudraw -F trace <pdf> works. | 17:32.10 |
| thanks. sorry to be a hassle. | 17:32.14 |
Robin_Watts | no worries. | 17:33.03 |
mvrhel_laptop | ok. taking break from gsview now to work on 695622. Everything is working from wise except for listbox and digital signatures. will do those after I fix this bug | 18:30.14 |
| s/from/form/ | 18:30.23 |
henrys | here's what I got now for urw: http://twiki.ghostscript.com/do/view/Ghostscript/URWFontWork | 18:40.26 |
mvrhel_laptop | profiling this thing is pointing to shading being the hot spot | 18:48.10 |
Robin_Watts | What sort of shading is it? | 18:49.48 |
mvrhel_laptop | hmm hold on | 18:57.49 |
| Axial shading. It is calling A_fill_region a zillion times | 18:59.20 |
| and writing lots of fills into the clist | 18:59.31 |
| spending 96 percent of its time in A_fill_region | 19:00.39 |
| oh it is a DeviceN color space | 19:02.05 |
| there are a lot of shadings in this file. I will cut it down to see which one is the issue | 19:03.56 |
| its deviceN but there are no spot colors in the file | 19:04.27 |
| heading to lunch now. | 19:05.52 |
| bbiaw | 19:05.55 |
| ok. one thing that I do see is that this thing is going through a fair amount of color mapping nonsense that could likely be short circuited. | 20:01.24 |
| all the tests for linearity in the shading | 20:01.53 |
| I am thinking that a source based test for cs_is_linear for the DeviceN colorants when the output device is a sep device makes a lot more sense. There is no reason for us to go through all the remappings | 21:34.50 |
| let me do a simple one and see what happens | 21:35.23 |
| the only other thing is the transfer function. so if we don't have a transfer function and we have a sep device, this test for linearity can be greatly simplied | 21:41.31 |
| which should help | 21:41.46 |
| nice. with this change I have planned. this thing should go from taking 5 mins 15 secs on my laptop to 15 seconds | 22:26.27 |
| that is a bit of a win | 22:26.30 |
| henrys: so I should have a fix for this tomorrow | 22:27.20 |
henrys | mvrhel_laptop: great mvrhel_laptop | 22:27.28 |
| nice | 22:27.31 |
| I just did a clean build of gs and got GPL Ghostscript GIT PRERELEASE 9.19: Can't find initialization file gs_init.ps | 23:05.08 |
| actually it happens when I do make debug ... make gsdebug is good | 23:09.43 |
| with only 135 targets to choose from you'd think I'd get the right one ;-) | 23:13.01 |
mvrhel_laptop | henrys: so when is the release going to happen? | 23:16.26 |
| or did it already? | 23:16.45 |
Robin_Watts | chrisl has done the rc, but no final release. | 23:17.09 |
mvrhel_laptop | ok | 23:17.12 |
henrys | mvrhel_laptop: rc is out so I think a patch is better for your code. | 23:17.13 |
mvrhel_laptop | ok | 23:17.17 |
henrys | mvrhel_laptop: was that a dave lewis bug? | 23:19.06 |
mvrhel_laptop | yes | 23:19.11 |
henrys | he was naggin me in chicago... he'll be pleased | 23:19.32 |
mvrhel_laptop | wtf. I screwed up something here. need to take a break for abit | 23:33.21 |
henrys | we could give the luratech crash to shelly for a bounty it doesn't crash for us with openjpeg but I suspect it's out fault. | 23:38.59 |
mvrhel_laptop | ok. found my problem. will finish this up tonight likely. def. need to take a break now. | 23:43.47 |
| Forward 1 day (to 2015/09/25)>>> | |