| | <<<Back 1 day (to 2015/02/03) | 20150204 |
| kens | henrys (for the logs) I hacked up a quick test of the suggestion I was making for a 'form cache' for high level devices.What I'm doing is executing the form PaintProc once, storing a value in the Implementation, and then when we nextg see the form, if the Implementation is not null I simply don't run the form. | 09:26.24 |
| | This leaves all the non-form content alone, of course it doesn't actually *paint* the form, so a real implementation which caused pdfwrite to emit a 'Do' for the stored form would be very slight (probably imperceptibly) slower. | 09:27.29 |
| | However, the time taken to write the PDF file (for the full 4984 pages) dropped from around 20 minutes to 14 seconds. | 09:28.04 |
| | The customer says Acrobat takes 16 seconds so we're pretty much in touch. | 09:28.33 |
| chrisl | kens: can I suggest that if you go ahead with this, you make the /Implementation entry a dictionary, and put the "form ID" in there? Just in case we decide to do more with forms in the future...... | 09:29.31 |
| kens | chrisl can do, its more that I wanted to demonstrate the fact that it is the form PaintProc which is taking all the time, and that this is how Acrobat Distiller achieves such high performance. | 09:30.11 |
| | RIght now we always add an Implementation, but we make its value the null object | 09:30.28 |
| chrisl | kens: I realise that, it just occurred to me earlier that a dictionary would be preferable - ideally, a no-access dictionary, but that might make life difficult | 09:31.14 |
| kens | If henry decides we shold go ahead with it, I'll pass it round for comment when its done. | 09:31.46 |
| | IMO its worth doing for this customer, it makes a huge difference to this file, and I assume (form the hand-crafted PostScript) that they do a lot of this, or intend to | 09:32.32 |
| | chrisl do you want to add anything to the mail about setpagedevice ? If not I'll send it on to the customer, Marcos said it wasn't offensive :-) | 09:36.33 |
| chrisl | just a sec - on phone | 09:36.54 |
| kens | No rush | 09:37.00 |
| chrisl | kens: okay, I thought the mail for Zoltan was fine. It's clearly idiotic to expect us to break Postscript just to suit their needs, especially when with a little thought and Postscript hacking, there is a workable solution. | 09:40.57 |
| kens | OK then I'll go ahead and send it to them. | 09:41.11 |
| chrisl | And prepare for their demand that you do it for them, their way, and no other!! | 09:42.07 |
| kens | Yep, but that's OK I cna ignore them easily, I've had practice :-) | 09:42.24 |
| chrisl | reboots | 09:42.54 |
| henrys | kens: yes go ahead with it. Given the amount of work I don't think we should go for an NRE on this one. Seems like we should just do it. | 14:31.39 |
| kens | OK I'll put this aside and get started. SHoud be done by the end of the week. FWIW the PDF file comes out at 4Mb instead of 68 Mb, the final result will be a little larger though. | 14:32.19 |
| henrys | kens: great that was faster than I thought. | 14:38.28 |
| kens | Its not especially hard to do, just the pdfwrite end that will take a bit of pounding, I'm not certain how hard that will be. | 14:39.02 |
| henrys | kens: for the customer we should probably tell them end of next week or preferably wait for a release. I'll ask marcosw to tell them. | 14:44.44 |
| kens | OK fair enough | 14:44.55 |
| henrys | or I'll just write to them it would take more time to explain it to marcosw | 14:46.43 |
| kens | :-) | 14:46.49 |
| | I was slightly surprised not to have heard back from Zoltan already :-) | 14:47.16 |
| henrys | kens: don't get your hopes up it's probably just going to be a very long response ;-) | 14:48.07 |
| kens | :-( | 14:48.17 |
| henrys | chrisl: about the download truncations: do we have download stats? I think we discussed this before but obviously if we have a huge number of successful downloads it's not as important. | 15:20.33 |
| kens | I think we don't know whether the downloads are truncated or not (I oculd be wrong). It certainly seems like the people complaining don't know that they have broken downloads. | 15:21.27 |
| henrys | well urw sent us the otf cff's with font name filenames, not the usual serial numbers so I guess that resolves the naming issue. | 15:24.39 |
| Robin_Watts | henrys: We download *gigs* per week. | 15:25.31 |
| | I'd guess at least a gig a day. | 15:25.39 |
| | so for every truncated one, there are probably 1000s that work. | 15:25.56 |
| | and I wouldn't like to guess how many of those are down to user error. | 15:26.41 |
| chrisl | henrys: wot Robin_Watts said...... | 15:29.21 |
| henrys | chrisl: well if you knew that why did you want to talk about it. I didn't think the downloads were nearly that many so I thought this might be an issue to be fixed. | 15:30.54 |
| | chrisl: that was a question, sorry. | 15:31.30 |
| Robin_Watts | We've had trouble getting hosting before because of our bandwidth usage. | 15:31.54 |
| chrisl | henrys: I'm concerned because we seem to getting more instances of it than we used to, and at least one potential customer has suffered the problem - which doesn't look good | 15:31.58 |
| henrys | chrisl: well we've spoken to them, are you suggesting we do it again or just start shopping? | 15:34.00 |
| Robin_Watts | Arguably we should have 2 download sites. | 15:34.32 |
| | downloads.ghostscript.com and downloads2.ghostscript.com maybe. | 15:34.45 |
| | One could be on godaddy and one on some other hosting service. | 15:34.56 |
| chrisl | henrys: I was hoping to solicit opinions: it's not really something I know much about and, as Robin_Watts said, our bandwidth means we have struggled in the past | 15:35.05 |
| Robin_Watts | That way we'd have protection against one of them having problems. | 15:35.26 |
| chrisl | Robin_Watts: the problem is, we can't tell when there are problems.... and it *seems* that the downloads from GoDaddy are failing without an error - hence people not realising it's failed | 15:36.26 |
| henrys | I wish I has a sense of what the error rate should be for something like we are doing. I don't understand what you mean bandwidth wise - even with that many downloads we'd pale in comparison to multimedia stuff or even other open source projects. | 15:38.49 |
| Robin_Watts | henrys: Most hosting sites like godaddy are setup using shared hosting. | 15:39.30 |
| | 1 computer hosting multiple sites. | 15:39.47 |
| chrisl | henrys: multimedia vendors pay per Gb.... | 15:39.54 |
| Robin_Watts | We absolutely cane whatever server we are on. | 15:40.19 |
| | It's not much CPU to just shift binaries, but we take huge amounts of bandwidth. | 15:40.42 |
| | Most download services charge per Gb as chris says, and they load balance over multiple servers. | 15:41.05 |
| | But that would be orders of magnitude more expensive than what we're currently paying. | 15:41.24 |
| chrisl | Or we go back to using something like sourceforge...... | 15:42.29 |
| henrys | chrisl: that's an interesting thought. | 15:43.12 |
| chrisl | henrys: we just dropped sf because of all the other problems it caused, and our lack of control over it | 15:43.52 |
| Robin_Watts | right. sourceforge load balances, and makes money off us via advertising and by pulling eyes we provide into other stuff they do. | 15:44.40 |
| henrys | We could probably do customer downloads off casper. Very little load with that. | 15:45.20 |
| Robin_Watts | henrys: Noooo! | 15:45.32 |
| chrisl | We do customer downloads from casper already | 15:45.36 |
| Robin_Watts | Oh, customers, sorry. | 15:45.40 |
| henrys | chrisl: oh I thought it was all on GoDaddy | 15:46.07 |
| chrisl | henrys: no, we keep the commercial releases on casper because of the non-GPL code in them | 15:46.39 |
| henrys | chrisl: anything else on godaddy? | 15:47.15 |
| chrisl | henrys: the artifex site might still be hosted there | 15:47.49 |
| henrys | chrisl: huh I just thought we password protecting them on godaddy all this time. | 15:48.01 |
| | chrisl: I do like the idea of going back to sourceforge but I'm not sure all the negatives are occurring to me ;-) | 15:50.20 |
| chrisl | henrys: how about the way they propagated malware and spyware with their downloads - I'd say that was a good reason not to go back | 15:51.25 |
| henrys | chrisl: denver agenda good enough? | 15:53.59 |
| chrisl | henrys: Yes, I don't think it's critical, I just think it's something we need to be aware that we might have a problem | 15:54.41 |
| Robin_Watts | chrisl: You'd be against the idea of having an alternate hosting solution as a mirror? | 15:55.33 |
| | 2 links on the download page rather than just 1 for each product/version/platform etc. | 15:56.01 |
| chrisl | Robin_Watts: it depends on who. I have a specific problem with sourceforge, and it would have to be something we could easily get a consistent link to (not one of these sites that dynamically create the URL). | 15:57.04 |
| kens | Hmm, I'm not convinced that 'ATS fiules use a large amount of memory' bug should be assigned to me, I doubt its really the PDF interpreter | 15:58.33 |
| henrys | kens: he's back, I knew he couldn't be knocked down with one punch. | 15:59.53 |
| Robin_Watts | chrisl: I was thinking of another godaddy equivalent. | 16:00.03 |
| kens | Yeah, I'm not giving in though | 16:00.06 |
| Robin_Watts | We've used ix before, and they kicked us off. | 16:00.16 |
| chrisl | Robin_Watts: I wouldn't have a problem with that, but it wouldn't necessarily solve the failed downloads issue | 16:01.06 |
| | henrys: are we expecting a complete base 35 set of OTFs from URW at some point? | 16:06.40 |
| henrys | chrisl: in the future yes, but not GPL for the expanded glyph set. | 16:08.47 |
| chrisl | henrys: I just meant for what we have now - we got a complete set in Type 1, and then just the ones with the expanded glyph set in OTF | 16:09.42 |
| henrys | chrisl: right I can ask them for an otf release of the old fonts or we can just process them with fontforge. | 16:11.15 |
| chrisl | Okay, I guess it's probably easier just to convert them ourselves | 16:11.59 |
| henrys | I think so... I spoke to him about having 2 font sets - one with GPL in the copyright in the font bu they didn't want to do that. I'd like a fontforge script to do that too, but if you feel like it will be easier to just have one set of fonts that's fine too | 16:14.16 |
| | now that I think about it we shouldn't modify their copyright though so I guess that's not a good idea anyway. | 16:15.36 |
| chrisl | henrys: all the distro people I've had contact (including Debian) were happy with the COPYING and LICENSE file in the distro (both the fonts themselves and gs), and the font copyright still just having URW+ as the holder. | 16:16.42 |
| henrys | chrisl: sure my concern is protecting them. if they are embedded in a proprietary product it would be possible to detect their use with "strings" or something. With this arrangement we have no way of telling the fonts apart. | 16:55.36 |
| chrisl | henrys: it's not really our problem | 16:56.55 |
| henrys | chrisl: we can tip URW off... and they give us a finder fee or a deal on fonts. But yes that is a pretty minor consideration in the overall scheme of things. | 17:00.19 |
| chrisl | henrys: we could easily add a comment or something to the fonts we ship (both AGPL and commercial) - if it's found in a commercial product that doesn't come from a Artifex customer, we'd know it was dubious - no need to have separate font sets. | 17:02.28 |
| kens | Night folks | 17:04.04 |
| henrys | chrisl: well that's not much different than changing the copyright in the fonts is it? It would be a different font set generated from the originals with new font info, which I would count as 2 fonts sets... | 17:06.31 |
| chrisl | henrys: I meant we wouldn't be shipping two different font sets | 17:06.57 |
| henrys | chrisl: oh I see what you mean. Yes that does make sense. | 17:09.13 |
| | chrisl: I'm fine with that. | 17:09.42 |
| chrisl | henrys: Of course, if we can add a recognizable string, anyone else can remove it again...... | 17:10.37 |
| rayjj | kens: sorry about that "premature" bug -- somehow my browser focus shifted fromthe "Comments" window so when I hit <enter> it submitted the bug. | 17:13.11 |
| henrys | chrisl: I also like to ship an exact match ... I don't know | 17:13.37 |
| chrisl | henrys: Personally, I feel that if URW don't feel the need for extra protection, we'd be better working towards just shipping what they give us | 17:14.39 |
| henrys | chrisl: fair enough | 17:16.11 |
| rayjj | arghh... I just spent hours pulling together a file for the 'RAM usage' bug, and the whole shell crashed, taking the editor (vim) with it. I re-opened the file (which I had been saving) and it warned me that there was a saved "work in progress", so I said "Recover". IT RECOVERED WITHOUT MY SAVES !!!! | 17:48.59 |
| | I blame Windows | 17:49.08 |
| | there's probably a lost file around somewhere, but it would take longer to look for it then to do the info over | 17:49.53 |
| Robin_Watts | I blame vim. | 18:01.45 |
| rayjj | Robin_Watts: I found the file !!! (or rather vim did). When I opened it again and didn't say "Recover" it came back as I had last saved it. So, you are right, it was 'vim' messing up the "Recover" action | 18:06.47 |
| | Robin_Watts: but it's probably not vim that caused the shell to crash and take its child process (vim) with it | 18:09.07 |
| | I've had vim encounter errors before and the shell stays around | 18:09.39 |
| | unless I was just lucky | 18:10.08 |
| henrys | chrisl, kens (logs) : I was thinking we could release the Type 1 set this release and see if we get feedback on the new glyphs. | 18:14.51 |
| chrisl | henrys: the Type 1 fonts with the revised glyph sets are committed, so those will go into the release | 18:15.43 |
| henrys | nobody tells me anything ;-) | 18:16.35 |
| chrisl | henrys: there are practically no differences between the old and new fonts for the pre-existing glyphs, so there's almost no risk in updating | 18:17.32 |
| | I have to go - nite all! | 18:19.04 |
| rayjj | henrys: OK. Version 2 of the email in work. After analysis of the spreadsheet data, and the 'pdf_info' on the files, turns out that we want the _Save ATS files. The others have been processed and transparency (if any) flattened, which is *not* needed by gs | 18:31.29 |
| | henrys: Then there are many fewer files to consider and they are more "real world" -- but still looking to make sure I've picked up all of the "original" files (before being munged by Writer or Distiller or PDFACT) | 18:40.17 |
| mvrhel_laptop | oh found a gc memory goof up in the named color code | 22:03.01 |
| | argh. and another issue with the named color stuff. it has suffered a little bit rot over the years | 22:19.00 |
| | oh actually I had a warning in the code about this particular issue | 22:25.08 |
| | I will leave it at that | 22:25.11 |
| rayjj | mvrhel_laptop: bit rot sucks | 22:34.43 |
| mvrhel_laptop | rayjj: In fact it was an issue I had spotted early and forgotten about. trying to fix a slightly different issue now with the named color stuff | 22:35.27 |
| | stefan has a case where he has an 8 color device and a CMYK output profile and that is causing a couple minor issues | 22:36.09 |
| rayjj | mvrhel_laptop: yeah, I saw the emails. DeviceN and N-color devices is rather, uhh.., "frail" | 22:37.06 |
| mvrhel_laptop | yes. that is an understatement | 22:37.17 |
| | especially if you mix in his special processing | 22:37.34 |
| rayjj | mvrhel_laptop: at least the compressed color stuff is no longer needed | 22:38.05 |
| mvrhel_laptop | yes true | 22:38.16 |
| | sigh. this is going to take a little thinking | 23:09.59 |
| | Forward 1 day (to 2015/02/05)>>> | |
IRC Logs