| | <<<Back 1 day (to 2012/09/04) | 2012/09/05 |
| alexcher | marcosw: What's mu that you mentioned in the bug about unsupported PDF encryption? | 03:01.18 |
| marcosw | we used to ship a product called mupdf but then someone decided that since it also read xps files mupdf wasn't a good name so now it's called mu | 03:48.39 |
| mvrhel | really? | 03:48.54 |
| | but everyone pronounces it as moo | 03:49.30 |
| marcosw | I assume so, mupdfdraw -> mudraw, so clearly mupdf -> mu | 03:49.33 |
| mvrhel | interesting. looking at dictionary.com they give a myoo and moo pronunciation. also I see that mu is slang for marijuana | 04:13.06 |
| | never heard that one before | 04:13.14 |
| kens | Robin_Watts : ping | 08:48.34 |
| tim__ | hi any ghostscript developer here to ask some questiones? | 08:56.14 |
| kens | Yes, several | 08:56.21 |
| tim__ | ok | 08:56.26 |
| | first i want to know if ghostscript is able to convert PDF to XPS | 08:56.51 |
| kens | Currently, no, there is no xpswrite device yet, its in development | 08:57.12 |
| | Well, there is a sort of working construct, but I wouldn't trust it | 08:57.26 |
| tim__ | ok i found some solutions that use adobe reader and print the pdf file to xps but i dont want a save file dialog to be opened | 08:58.11 |
| | anyone know other soltuions for that? | 08:58.33 |
| | the printing process should be proceeded without any user interaction | 08:59.07 |
| kens | http://www.verydoc.com/pdf2vector/pdf-to-xps.html | 09:00.39 |
| tim__ | yes found that too but this is very expensive | 09:01.11 |
| | but thanks for your help guys | 09:01.19 |
| Robin_Watts | kens: pong | 09:11.45 |
| kens | morning Robin_Watts | 09:11.52 |
| | You sent me a file which was one page and no 'web optimised' | 09:12.04 |
| | I think I know how to fix it, can you tell me where to get another copy ? | 09:12.18 |
| Robin_Watts | let me look | 09:13.28 |
| | hehe. All my attempts to generate a 1 page file are coming out as linearised now :/ | 09:16.02 |
| kens | Interesting.... | 09:16.10 |
| | I do now know why my files weren't, and I have fixed it. | 09:16.27 |
| Robin_Watts | What was it? | 09:17.15 |
| kens | Oh, you'll like htis one.... | 09:17.27 |
| | Any file less than 4k is not recognised as linear | 09:17.42 |
| | Add white space to make my file 4k and it works | 09:17.58 |
| Robin_Watts | Ah... | 09:18.14 |
| | That makes sense, as my files here are > 4K. | 09:18.23 |
| kens | I wondered that | 09:18.30 |
| Robin_Watts | jeez. | 09:18.32 |
| kens | Yes, exactly, optimise for web viewing by making the file bigger (ROFL) | 09:18.48 |
| | 2 days fo laborious scraping at PDF files by hand to find that little gem | 09:19.19 |
| | As far as I can see it is not documented anywhere either | 09:19.33 |
| | I'm about to go out, when I get back I'll work on my hint tables some more. At least the damn files show up as linearised now. | 09:20.49 |
| paulgardiner | Robin_Watts, tor8: ping | 10:07.28 |
| tor8 | paulgardiner: hey | 10:07.41 |
| paulgardiner | I have an api for mupdf to report events to the app. I was at first trying to avoid using a callbacks because I don't think most apps will be able to respond to events immediately and will need to queue and poll later. | 10:10.16 |
| | But then I realised that mupdf would have to queue and it's difficult to know when to free queued items if the app isn't interested in them. | 10:10.57 |
| Robin_Watts | paulgardiner: Urm... I was imagining any queueing would be done in the app. | 10:11.25 |
| | What events are we talking about here? | 10:11.33 |
| paulgardiner | So I've ended up with a callback but some extra features that should make it very easy for the app to either ignore or queue events | 10:11.34 |
| Robin_Watts | "The Javascript has requested a print dialogue" | 10:11.48 |
| paulgardiner | events: submit openurl maildoc print | 10:12.02 |
| Robin_Watts | OK. So those are all of the form: "The javascript has requested that you do X" | 10:12.33 |
| paulgardiner | can come from javascript or a pdf action or someone clicking a link (I think we should swap link handling to work via this) | 10:12.40 |
| | Robin_Watts: Yesish | 10:12.53 |
| Robin_Watts | So no response is required to any of them? | 10:13.11 |
| paulgardiner | something, possibly javascript, has invoked something. | 10:13.15 |
| Robin_Watts | So why might we need to queue ? | 10:13.30 |
| paulgardiner | The api is on paulg/master | 10:13.30 |
| | Because within the callback you might have locks taken and not want to drop them, you can't reenter some code, you may be in a v8 call. | 10:14.21 |
| | You don't want to stall the whole app | 10:14.41 |
| | I mean v8 may be in the backtrace of the callback | 10:15.22 |
| Robin_Watts | Right. I'd imagined that the callback from lib to app would be a purely informational thing. | 10:15.42 |
| paulgardiner | Yes | 10:15.52 |
| Robin_Watts | The app would record that it had had such a callback and then immediately return to the lib. | 10:16.04 |
| paulgardiner | Yes | 10:16.11 |
| Robin_Watts | So the app would ALWAYS defer actually doing any work. | 10:16.23 |
| | but whether it does so or not is down to the app, and none of the libs concern. | 10:16.43 |
| tor8 | Robin_Watts: do you trust customers like Raed to be able to remember all that? | 10:16.48 |
| paulgardiner | Possibly always, but you may be able to do it immediately in some cases | 10:16.50 |
| | Robin_Watts: yes | 10:17.02 |
| Robin_Watts | tor8: I trust anyone capable of writing an app, yes. | 10:17.23 |
| | because if they don't, it'll fall into a heap pretty quickly. | 10:17.37 |
| tor8 | so basically all apps will have to implement their own js event/request queue | 10:17.59 |
| paulgardiner | The difficulty with returning immediately is there may be a lot of data you need to store and own - different for each event, so I've tried to make that very easy | 10:17.59 |
| Robin_Watts | All it needs to make it (more) idiot proof is a note saying; do not call back into mupdf from the callback. | 10:18.02 |
| paulgardiner | I've given the event objects "keep" and "drop" methods, plus a next property so the app can easily queue them. | 10:19.13 |
| Robin_Watts | so they are ref counted? | 10:20.01 |
| paulgardiner | Yep | 10:20.09 |
| Robin_Watts | and you've hidden the refcount out of the structure ? | 10:20.25 |
| paulgardiner | yep | 10:20.32 |
| Robin_Watts | So when Raed copies the struct and then 'keeps' it... | 10:20.59 |
| paulgardiner | The caller sees only "type" and "next". For eash type of event there is a function to get at the rest of the data | 10:21.05 |
| | No need to copy. Just keep | 10:21.21 |
| | May be worth looking at paulg/master | 10:21.52 |
| Robin_Watts | I am. | 10:22.00 |
| | I know this is a strange reversal for me to be the one arguing for simplicity, but I think all this should be done by the app. | 10:22.30 |
| paulgardiner | I quite like how it as turned out, but I can imagine it might not be to everyone's tastes | 10:22.40 |
| Robin_Watts | I mean, how much data is there ever actually to store? | 10:22.57 |
| | If we are going to expose a queue like this, then why not really expose it as a queue ? | 10:23.36 |
| tor8 | if it were me I'd have fz_next_doc_event(idoc) that the app would poll until its empty | 10:23.44 |
| paulgardiner | Robin_Watts: Little but is difficult for the app to know what to store and how to store it. The app doesn't know that some things are pointers to owned info and others need freeing | 10:23.49 |
| Robin_Watts | the callback could mean "There is a new element in the queue" | 10:24.00 |
| paulgardiner | It's not a queue. They are independent events that are easily queued | 10:24.13 |
| tor8 | and if the app doesn't care about the event, it'd just drop it | 10:24.14 |
| Robin_Watts | and we could have a "give me the next element in the queue". | 10:24.17 |
| | what tor8 said. | 10:24.29 |
| paulgardiner | Robin_Watts: if mupdf queues the events, it is difficult for mupdf to know when to free things, especially if the app is not interested in events | 10:25.10 |
| tor8 | paulgardiner: while (evt = fz_next_doc_event(idoc) != NULL) { if (evt->type == MY_CUP_OF_TEA) do_stuff(); fz_drop_doc_event(idoc); } | 10:26.17 |
| Robin_Watts | Or we have the callback of the form: int callback(event); where the callback can return 0 for 'ignore', 1 for 'dealt with' and 2 for 'queue for later'. | 10:26.30 |
| tor8 | Robin_Watts: no. that's too complicated. | 10:26.49 |
| paulgardiner | tor8: Yeah, that was a version I went through. Could do that way. I prefered my later version because it still works if the app doesn't bother to poll | 10:26.53 |
| tor8 | paulgardiner: we could check that the queue is empty every loop (at some convenient entry point) and fz_warn | 10:27.33 |
| | or just have a max limit and warn if it's getting long | 10:27.40 |
| Robin_Watts | tor8: So are you suggesting that we do away with callback entirely, and just have a queue ? | 10:27.44 |
| tor8 | Robin_Watts: correct. | 10:27.57 |
| paulgardiner | I like the polled queue, except that we force the app to poll even if it isn't interested in any events. That was my only reason for the "seemingly" more complicated api | 10:28.10 |
| tor8 | paulgardiner: we could give fz_interactive a flag whether an app is interested in events or not | 10:28.37 |
| paulgardiner | Polled queue is where I started. And I do like it. | 10:28.39 |
| | tor8: Yep. That's a possibility. | 10:28.53 |
| Robin_Watts | Polled queue is certainly simpler conceptually. | 10:28.55 |
| paulgardiner | Maybe that is better | 10:28.57 |
| tor8 | although I'd imagine if an fz_interactive is created, it will be wanting to poll | 10:29.14 |
| paulgardiner | I don't think what I have is complicated. It's just unusual. But that alone may be a reason not to use it. | 10:29.38 |
| tor8 | paulgardiner: what's on paulg/master now requires a bunch of boiler plate code for hooking up callbacks etc, for something that is otherwise done in one line | 10:30.39 |
| Robin_Watts | runs. back soon. | 10:30.44 |
| paulgardiner | I also liked the idea of being able to respond immediately without queuing in some cercumstances: i.e., in windows, it is common to call the message poll queue recursively | 10:30.47 |
| tor8 | paulgardiner: I'd imagine the app at the top level calling some js/forms functions when it gets a system mouse/keyboard event, and directly after that it'll poll for doc events before going back to wait for another system event | 10:31.28 |
| | possibly by juggling things over worker threads | 10:31.48 |
| | the worry as you said is what to do if the caller forgets to empty the queue | 10:32.42 |
| paulgardiner | tor8: yes true. Ok, I'm pretty convinced. I did think of having the "i'm interested in events" flag, but didn't like it for some reason (which I'm now not sure of) | 10:32.52 |
| | tor8: Yep. Completely convinced. I was trying to avoid mupdf having an internal queue, but I think it's better for it to have one. | 10:33.56 |
| | I think we were all trying to avoid that to start with, but it's not worth the extra complication of the api and the boilerplate | 10:34.51 |
| | I'll alter the api, and stick it up again. | 10:35.18 |
| | tor8, Robin_Watts: Ok. Pushed a new version. | 10:52.22 |
| tor8 | paulgardiner: looks agreeable :) | 11:16.43 |
| paulgardiner | Eek! That's going to be awkward: the app.alert method displays an alert dialog and returns an indication of which button is pressed! Not sure how that's going to be possible to implement. | 11:17.11 |
| | So contrary to what I stated earlier, not all these events can be thought of an information only. Some need to return a result based on the app's response to the event. | 11:18.47 |
| tor8 | paulgardiner: eek indeed :( | 11:19.38 |
| paulgardiner | I think I know how to do that in windows... although I'd need to be handling the events on a callback to do it. | 11:20.25 |
| | And it would still have a feeling of danger to it: calling back into windows from v8! | 11:21.24 |
| | Recursive message poll loops are common in windows apps, or at least used to be before windows had threads. | 11:22.15 |
| | The only other way I can imagine its being possible, is if I ran javascrip actions on a separate thread. | 11:23.54 |
| | In android the dialog would be possible to display in the main thread, while stalling mupdf, because in the android app, all mupdf execution is done on a separate thread. | 11:26.25 |
| tor8 | paulgardiner: are there any other exceptions? | 11:26.33 |
| paulgardiner | app.launchUrl doesn't return a value but is supposed to throw a javascript exception if it fails. | 11:29.08 |
| | Also, I'm only currently looking at DOM usage from our test files. Not sure if I can predict if there would be many other cases where mupdf needs a result from the app | 11:30.22 |
| | There's app.execDialog. | 11:30.58 |
| | field.buttonImportIcon needs to provoke an "open file" dialog to get the path to an image file. | 11:31.58 |
| | So it'll need the returned result. | 11:32.09 |
| | Ah! Idea" Possibly horrible. What about if I throw an exception in the javascript to kill it off, and then rerun the action | 11:33.19 |
| | No, that could do repeated state updates in the javascript. | 11:33.39 |
| | Sorry, I should have realised this before. | 11:35.17 |
| tor8 | paulgardiner: I take it we can't save a suspend state and resume later? like a coroutine kind of thing. | 11:46.50 |
| | then I think we'll just have to do it the callback (and no queueing allowed) way... ugh. | 11:47.27 |
| paulgardiner | Can do coroutines with setjmp and longjmp but you have to be able to create new stacks and it's very jucky. | 11:48.33 |
| | Unless v8 has support for it. | 11:48.53 |
| | But then we don't want to be married to v8 | 11:49.04 |
| | The api I presented before allowed for dealing with some events immediately and some queued. | 11:49.36 |
| | ... although if some have to be dealt with immediately, perhaps it makes sense to try to do all that way... although we can't stall while we print e.g. | 11:50.37 |
| Robin_Watts | ass | 11:51.44 |
| paulgardiner | Quite | 11:51.51 |
| Robin_Watts | And double ass. My cluster test of the pdfwrite stuff is failing, and I can't reproduce it :( | 11:52.25 |
| paulgardiner | So perhaps I should go back to a callback and forget the queuing completely for now? | 11:55.29 |
| Robin_Watts | That's the simplest route, and simplest wins, generally. | 11:58.43 |
| | (seems odd for it to be me advocating the less complex route...) | 11:59.07 |
| paulgardiner | :-) | 11:59.40 |
| tor8 | Robin_Watts: are you ill? ;) | 12:24.53 |
| Robin_Watts | not ill, just annoyed. | 12:30.07 |
| | Could I trouble one of you to pull my pdfwrite mods from my repo and do a test build/run please? | 12:30.48 |
| | 2000ish files fail under the cluster, but even using the clusters binary on peeves I can't make them fail. | 12:31.27 |
| paulgardiner | Robin_Watts, tor8: another version pushed. I've also added the app.alert event just to show how values are returned. | 12:39.39 |
| Robin_Watts | sebras: disagreements in #gstreamer ? | 12:45.05 |
| sebras | Robin_Watts: yes indeed. | 12:45.19 |
| | Robin_Watts: they blew me off publicly. so ARGH! on them. :-P | 12:45.59 |
| | unfortunately my temper made me write /quit instead of /part... :-) | 12:47.04 |
| Robin_Watts | I guessed. I make similar mistaked. | 12:47.41 |
| | mistakes. geez. | 12:47.47 |
| Robin_Watts | wonders what he has done to make the gods of the cluster hate him so. | 12:48.25 |
| sebras | Robin_Watts: it's more fun to work on mupdf. you guys are friendlier and the process is faster and slimmer (except when there are copyright assignments messing things up). and the quality of the code is superior and it has less framework crap. sometimes I wonder why on earth I'm working on gstreamer. | 12:49.00 |
| Robin_Watts | oh, I see the problem, I think. | 12:54.34 |
| | The cluster gets us to write to files like: this__is__the__input_file.pdf.ppm.0.blah and I spot the .pdf and assume it's a pdf write. | 12:55.32 |
| kens | Robin_Watts : did you ever look at what Acrobat produces for a hint table ? | 14:33.59 |
| Robin_Watts | I did. | 14:39.11 |
| kens | Its terrible | 14:39.19 |
| Robin_Watts | I got half way through writing my code, and then decided the spec wasn't clear. | 14:39.34 |
| kens | Loads of stuff is explicitly (and incorrectly) set to 0 | 14:39.41 |
| Robin_Watts | so I took an acrobat one to bits. | 14:39.42 |
| kens | Eg (implementation note 183(: | 14:40.21 |
| | "In Acrobat, items 6 and 7 in the header section of the page offset hint table are set to 0. As a result, item 6 of the per-page entry effectively does not exist; its value is taken to be 0. That is, the sequence of bytes constituting the content stream for a page is described as if the content stream were the first object in the page, even though it is not." | 14:40.22 |
| | and 184: | 14:40.41 |
| | "Acrobat 4.0 and later versions always set item 8 equal to 0. They also set item 9 equal to the value of item 5, and set item 7 of each per-page hint table entry (Table F.4) to be the same as item 2 of the per-page entry. Acrobat ignores all of these entries when reading the file." | 14:40.41 |
| Robin_Watts | Yes. | 14:40.49 |
| | I think I do the same. | 14:40.54 |
| | On the grounds that if acrobat doesn't do it, why should I bother. | 14:41.09 |
| kens | TO be honest, I'm feeling that way about the whole mess | 14:41.27 |
| | Acrobat clearly ignores practically all of it anyway | 14:41.36 |
| | And since it writes it incorrectly nothing else can rely on it, so what's the poiont ? | 14:41.52 |
| Robin_Watts | Indeed. I figured 'shoot for the simplest thing that keeps acrobat happy and seems correct to me'. | 14:42.10 |
| kens | ROFL | 14:42.18 |
| | Just write the hints as all 0 that works. | 14:42.25 |
| Robin_Watts | yeah, but that didn't seem right to me :) | 14:42.38 |
| tor8 | sounds like the best solution to me! :D | 14:42.51 |
| kens | Its nice and simple though :-) | 14:42.52 |
| | Well I will persever with finishing it the way I think it shoudl be | 14:43.21 |
| | Since nothing uses it nobody will ever know if its wrong. | 14:43.32 |
| | I will need to talk to marcosw about being able to run a cluster test with a much longer timeout though | 14:44.02 |
| sebras | kens: I do think that poppler actually parses some of the hint stream. | 14:48.53 |
| Robin_Watts | paulgardiner: That latest patch seems sane to me, btw. | 14:55.27 |
| paulgardiner | Robin_Watts: Ah right. good. | 14:55.54 |
| kens | sebras, but it can't rely on the contents of much of them, according to the implementation notes in the 1.7 spec. Mostly those notes tell you which bits of the hint stream Acrobat gets wrong, fills in with random data or simply ignores altogether. | 14:56.28 |
| Robin_Watts | tor8: New versions of the patches from last night online (of the last 3, ignore the latest one as it's still a work in progress) | 14:56.29 |
| kens | I was quite taken with implementation note 188: | 15:00.11 |
| | "In a document consisting of only one page, items 1 and 2 in the shared object hint table are not meaningful; Acrobat writes unpredictable values for these items." | 15:00.12 |
| sebras | kens: oh. how nice. one wonders why they bothered to implement it at all... | 15:31.17 |
| sebras | notes that this is not his most cheerful day, bear with me... | 15:32.40 |
| henrys | damn it I can't believe how stupid I am - I booked friday to sunday. | 15:33.31 |
| kens | henrys holiday :-) | 15:34.47 |
| | sebras, I'm wondering pretty much the same thing | 15:35.03 |
| | I suspect that the people who implemented it in Acrobat took one look at the spec and said 'what's the easiest way to make something work' and then implemented that. And tehn got it wrong.... | 15:35.40 |
| Robin_Watts | henrys: Can you not just drive it? :) | 15:40.24 |
| kens | thinks that's actually quite a long way | 15:40.41 |
| Robin_Watts | Better shorten the agenda :) | 15:40.47 |
| kens | Well Monday is Mile's day | 15:41.02 |
| chrisl | Is that a public holiday in th US? | 15:41.20 |
| kens | So as long as we get done in good time on Sunday..... | 15:41.24 |
| chrisl | :-) | 15:41.25 |
| kens | thnks it probably ought to be | 15:41.40 |
| Robin_Watts | Google says 19 hours. | 15:41.47 |
| kens | That seems like a long way to me | 15:42.13 |
| henrys | I changed it, it's not a big deal domestically | 15:50.17 |
| | I lose a few bucks but I deserve it. | 15:50.37 |
| kens | easy mistake | 15:50.52 |
| | OK off to eat, goodnight all | 16:04.07 |
| Robin_Watts | iPhone 5 to be launched on Sept 12th. Looks like we'll be getting out of SF just as all the journos arrive. | 16:05.08 |
| henrys | Did you guys pay much more to fly on Monday? | 16:17.01 |
| | or I guess you normally fly Monday. | 16:17.34 |
| chrisl | We normally fly Sunday night - it was quite an expensive ticket, but I reckon that's more down to the time of year | 16:18.17 |
| Robin_Watts | henrys: The big price bump is saturday night. | 16:18.50 |
| | As long as we stay a saturday night, it's much cheaper. (so Sunday/Monday and Saturday/Sunday meetings work equally well for us). | 16:19.23 |
| henrys | everytime I do the agenda I have some sort of brainstorm that usually turns out to be not such a great idea after some thought - but why are we using banding at all on hosts? I have to imagine with reasonable locality a full frame allocated as file mapped memory (mmap) would be faster and more robust than banding. | 17:08.21 |
| Robin_Watts | 32bit systems have trouble mmapping anything too large. | 17:15.06 |
| | 4Gig is the ultimate limit of course, but most run into problems before 2. | 17:15.24 |
| | And I think "reasonable locality" is a big killer. | 17:16.17 |
| | Imagine a page that plots a series of full frame rectangles. | 17:16.37 |
| | That's going to slave through the whole file swapping it into/out of memory as many times as there are rectangles. | 17:17.01 |
| henrys | true but there are lot of pathological cases for banding also. | 17:17.12 |
| Robin_Watts | swapping kills performance on multicore systems. | 17:17.55 |
| | (you can have multiple cores handling different bands nicely, but there is no way to make multiple cores accelerate full frame stuff) | 17:18.32 |
| henrys | that's a good point | 17:18.45 |
| | It would be interesting to see some numbers though. | 17:20.00 |
| Robin_Watts | but there is the flip side of the argument too... given that we have to support banding for embedded systems, what is gained by not allowing it to be used on hosts? | 17:23.24 |
| henrys | speed and robustness is why I suggested it. | 17:24.29 |
| | and I thought PAE gets you more than 4 gigs | 17:25.35 |
| chrisl | PAE still restricts you to 4gig *per process* | 17:26.02 |
| Gigs- | not per process | 17:26.04 |
| | think about it, pointers are still 32 bits | 17:26.26 |
| henrys | oh okay | 17:26.30 |
| | right | 17:26.32 |
| chrisl | I don't think I'd want to try to render a cairo PDF @ 1200dpi with all the buffers mmap()'ed....... | 17:27.23 |
| Robin_Watts | PAE is an x86 abomination. They didn't learn from segment registers... | 17:28.39 |
| mvrhel | henrys: so the fast thresholding is not enabled for all the planar devices. now I can add in the stuff to decide about prerendering when going to the clist | 17:29.02 |
| | s/is not/is now/ | 17:29.11 |
| Robin_Watts | mvrhel: Excellent! | 17:29.20 |
| | Did you solve the phase/level problems ? | 17:29.27 |
| mvrhel | yes. the subtractive threshold was inverted | 17:29.38 |
| chrisl | henrys: besides, given banding is used in the embedded area, we gain by having it "QA'ed" on the workstation builds..... | 17:29.41 |
| Robin_Watts | mvrhel: That explains the level differences. | 17:30.01 |
| | What about the phase differences? | 17:30.09 |
| mvrhel | and the phase. the turn on sequence was flipped | 17:30.31 |
| Robin_Watts | Ah. Fab. | 17:30.41 |
| | Nice one. | 17:30.56 |
| mvrhel | Gigs: I am working on your chili label now | 17:31.57 |
| Gigs- | cool | 17:32.08 |
| | yeah I saw the update | 17:32.12 |
| henrys | mvrhel:great okay I do notice you have a customer project (the one you visited) should that come first? | 17:32.39 |
| mvrhel | henrys: yes I do need to get that finished up too | 17:32.59 |
| henrys | chrisl:yes I thought of the QA too, indeed a downside. | 17:33.33 |
| Gigs- | Robin_Watts: at least the people who designed ipv6 weren't in charge of CPU architecture, or we'd have 512 bit systems that no one used :P | 17:33.36 |
| mvrhel | I am trying to work on all in parallel but likely I should devote more time to the color stuff for the customer | 17:33.46 |
| | henrys: ^^ | 17:34.15 |
| henrys | Now I'm reading about AWE I imagine that is a disaster but would allow you more than 4 gigs per process thought a windowing scheme like the old overlay hell. | 17:35.52 |
| | s/thought// | 17:36.09 |
| | okay probably a bad idea back to the agenda | 17:37.12 |
| Gigs- | awe is a lot like the old dos memory | 17:37.13 |
| | extended memory over 640k etc | 17:37.24 |
| henrys | Gigs- right - that's what I meant by the "old overlay hell" - technical term for it. | 17:38.03 |
| Gigs- | yeah | 17:38.36 |
| Robin_Watts | Such things keep paulgardiner in business emulating them on newer machines :) | 17:39.57 |
| aleray | hi, I just wanted to make sure that gosthscript urw font were GPL. Could someone confirm this? | 17:44.09 |
| | I'm asking for the font antique olive in particular | 17:44.39 |
| Gigs- | I don't believe they are | 17:46.50 |
| mvrhel | this is an interesting comment in the code | 17:50.01 |
| | * Perform actions required at set_color time. Since PatternType 2 * patterns specify a color space, we must update the overprint * information as required by that color space. We temporarily disable * overprint_mode, as it is never applicable when using shading patterns. | 17:50.07 |
| aleray | Gigs, from scribus wiki: There are some great freely licensed URW fonts from Artifex (makers of Ghostscript and GhostPCL) that are well worth grabbing. There are some good quality fonts in there, like Clarendon, URW Bookman, and Antique Olive. | 17:50.11 |
| mvrhel | I think this is the source of the chili problem | 17:50.39 |
| Robin_Watts | aleray: I believe, that they are aladdin licensed, not GPL, but I can't be sure. | 17:50.44 |
| henrys | the truetype fonts are afpl | 17:50.48 |
| Gigs- | don't tell debian | 17:51.02 |
| | :P | 17:51.03 |
| aleray | Gigs, so they aren't free ? | 17:51.17 |
| Gigs- | depends on your definition of free | 17:51.26 |
| Robin_Watts | No. Tell debian. If it causes the dogmatic gits problems, so much the better :) | 17:51.27 |
| Gigs- | also no one really cares about font licensing | 17:51.35 |
| Robin_Watts | Gigs: Except the people that license fonts. | 17:51.47 |
| Gigs- | yeah hehe | 17:51.50 |
| aleray | Gigs, I do :) | 17:51.51 |
| Gigs- | aleray: unless you are selling the fonts themselves, I doubt you will run into trouble | 17:52.08 |
| | of course anyone can sue for anything but really fonts have a lot of gray area | 17:52.26 |
| henrys | wikipedia has a good page about AFPL | 17:52.27 |
| aleray | henrys, ok let me check | 17:52.46 |
| Gigs- | the AFPL doesn't really make sense for fonts | 17:53.09 |
| aleray | Gigs, well it become problematic if I want to alter the font and redistricute it | 17:53.15 |
| Gigs- | if I sell a PDF with embedded fonts, I guess I'm technically violating it | 17:53.24 |
| Robin_Watts | Gigs: Well, he has to be careful. If he wants to use them for his own personal use there is probably no problem. If he wants to modify or redistribute them, or use them for commercial gain then that may be a problem. | 17:53.36 |
| Gigs- | a lot of font licensing issues are like that | 17:53.40 |
| henrys | Of course ghostscript is now GPL, it used to be AFPL, I've asked URW to change the license on their fonts but they like the AFPL for obvious reasons. | 17:56.29 |
| Gigs- | It would be nice if copyright law were changed on fonts. At least no one seems to sue over embedding.. yet | 17:57.17 |
| Robin_Watts | OK. This afternoons conundrum. Why doesn't acrobat like http://ghostscript.com/~robin/out.pdf ? | 17:59.43 |
| Gigs- | it doesn't open in evince either | 18:00.05 |
| henrys | chrome (foxit) likes it. | 18:00.16 |
| Robin_Watts | so does gs and mupdf. | 18:00.24 |
| Gigs- | evince says "failed to read the document catalog" | 18:00.33 |
| | is the xref offset weird or something | 18:00.47 |
| Robin_Watts | oh, wait, I see it. | 18:01.02 |
| aleray | Gigs, Robin_Watts , henrys thanks. So if I understand correctly appart the fact that I can't sell the modified version it is like GPL, right? Also I'm wondering what is considered the source code for a font? | 18:03.55 |
| Gigs- | hinting and anything algorithmic | 18:04.36 |
| | font faces are not copyrightable | 18:05.07 |
| | So a raster font is not really protected very much. It's the hinting and things other than the face itself that gets copyright protection. | 18:05.44 |
| aleray | Gigs, yes. I meant is a ttf file a source file? | 18:07.12 |
| Robin_Watts | aleray: Yes. | 18:07.34 |
| aleray | Robin_Watts, thanks | 18:07.39 |
| Gigs- | I can't speculate as to how the AFPL would work for fonts if that's what you are asking... I think it's an inappropriate license to use for that :) | 18:07.44 |
| aleray | But in practice this is the choice that was made for urw fonts in ghostscript... was it a deliberate choice, or just some kind of default choice since ghostscript was AFPL licensed at that time? | 18:09.29 |
| Robin_Watts | OK, new version of out.pdf online. Acrobat still doesn't like it. | 18:09.29 |
| Gigs- | Robin_Watts: evince renders it now | 18:09.44 |
| Robin_Watts | aleray: It was the default choice. The font foundry have declined requests to relicense it to GPL since. | 18:10.19 |
| aleray | Robin_Watts, thanks for those explanations | 18:10.51 |
| henrys | the ghostscript type 1 fonts are GPL, the Truetype fonts which were actually constructed to implement our PCL product are AFPL | 18:11.03 |
| Gigs- | http://www.tug.org/fonts/deutsch-urw.txt | 18:11.06 |
| | yeah what henrys said | 18:12.14 |
| | I just found that right as he said it | 18:12.22 |
| aleray | henrys, sorry, what does PCL stand for? | 18:14.12 |
| henrys | Printer command language | 18:14.44 |
| | HP thing | 18:14.47 |
| Gigs- | kind of a de facto standard now | 18:15.18 |
| | very few printers are native postscript anymore, except high end ones | 18:15.30 |
| aleray | henrys, ok, so logically, if I convert the type 1 fonts, I can get a GPLed version of it? | 18:15.35 |
| | I mean I can get a GPLed TTF version of it | 18:15.53 |
| Gigs- | it's going to be ugly | 18:16.03 |
| Robin_Watts | aleray: Theoretically, yes. | 18:16.52 |
| aleray | why that Gigs ? (i'm not expert at all on that topic) | 18:16.59 |
| Gigs- | not in appearance but in terms of the TTF code produced | 18:17.01 |
| Robin_Watts | If you get something as GPL then whatever you do to it you end up with something GPL. | 18:17.21 |
| Gigs- | TTF is like a programming language, so it's going to be generated code which may not be very elegant | 18:17.43 |
| Robin_Watts | But 1) converting Type 1 -> TTF is not a trivial process if you want to get nice output. | 18:18.09 |
| aleray | I interact with font only through fontforge, so the machinary is a little bit hidden to me | 18:18.48 |
| henrys | well theoretically no, not all T1 curves can be represente in TTF | 18:18.54 |
| Robin_Watts | and 2) I thought (though I have no idea where I got this impression and I could easily be wrong) that the urw TT fonts were not the same families as the Type1 fonts. | 18:19.15 |
| henrys | quadratic vs cubic. | 18:20.20 |
| aleray | oh ok, I could go for OTF instead, would that be better? | 18:20.49 |
| henrys | bbiab | 18:21.09 |
| aleray | I just want to be able to use this font for a print publication made in scribus | 18:21.12 |
| Robin_Watts | TTF only offers quadratics ? | 18:21.38 |
| Gigs- | aleray: if you aren't distributing the font itself, it doesn't much matter what the license is | 18:22.19 |
| henrys | truetype is quadratic and type 1 cubic | 18:22.30 |
| aleray | Gigs, henrys, Robin_Watts thanks for these good information. I think I need to explore wether AFPL is acceptable or not in my case, and if not if t1 to OTF/TTF conversion makes sense. | 18:26.38 |
| | nice to discuss with you :) | 18:27.06 |
| mvrhel | it appears that there are 2 issues going on with this chili label bug | 18:35.28 |
| | one is that with type2 patterns we were not allowing overprint and it looks like the separation color map is wrong once I fixed that issue | 18:59.03 |
| henrys | mvrhel:does somebody need to look at all these differences for the fast threshold change? | 19:18.24 |
| mvrhel | henrys: I stepped through a lot of them | 19:18.36 |
| | but another set of eyes can't hurt | 19:18.44 |
| henrys | I'll put it on the agenda - something to talk about | 19:19.13 |
| mvrhel | yes | 19:19.19 |
| | ugh. the saved imager state in the pattern object does not have the proper color map for the separation space of the pattern | 19:28.30 |
| | bbiaw | 19:45.22 |
| | aha. now I see what is going on. the overprint drawn components mask is not getting updated when we set the pattern | 20:54.50 |
| | bbiaw | 20:55.02 |
| jen_ | What's the syntax to watermark a JPG file using GS? | 21:29.57 |
| mvrhel | grumble grumble. this is turning into an interpreter problem | 23:43.16 |
| | alexcher are you around? | 23:43.23 |
| | Forward 1 day (to 2012/09/06)>>> | |
IRC Logs