| | <<<Back 1 day (to 2012/02/29) | 2012/03/01 |
| henrys | mvrhel:forwarded on a new customer's questions to you, they were very much color oriented so I thought it best to send it along. | 05:36.33 |
| mvrhel | henrys: ok | 06:07.30 |
| henrys | thanks hopefully we'll get this one. | 07:07.40 |
| kapouer | Hi, do anyone know how to link a program using libgs and libwebkit ? I get a segfault because of http://bugs.debian.org/653061 | 09:33.56 |
| kens | I don't think we can help with that, we know nothing of libwebkit | 09:34.19 |
| kapouer | libwebkit uses libjpeg8 shared lib | 09:34.37 |
| kens | You could maybe try building libgs with shared JPEG libraries | 09:35.08 |
| kapouer | that is what is done in debian package | 09:35.45 |
| | this explains the issue very precisely : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653061#30 | 09:35.59 |
| | i bet they already asked ghostscript devs some help | 09:36.21 |
| kens | No, they didn't | 09:36.31 |
| kapouer | well then, it's done :) | 09:36.57 |
| | mind that it's not only with libwebkit, it's with any lib that uses shared jpeg8 | 09:38.01 |
| kens | I haven't had time to read the whole thread, but 'b' isn't going to happen in the GS source. We want all the memory in our memory manager | 09:39.02 |
| | TBH I don't understand the problem, as I haven't studied it. If someone wants to raise a bug report it will get looked at, otherwise nothgin will change. | 09:39.38 |
| kapouer | ok, i'll see that with debian maintainers, thank you | 09:40.14 |
| kens | Possibly the problem is the fact that the system is building GS with shared libraries, we wish people wouldn't do that anyway. | 09:40.28 |
| chrisl | kapouer: the bug is really with libjpeg in that it doesn't provide a proper way to use the calling app's memory management - most other libraries do provide that capability. | 09:42.04 |
| | kapouer: actually, I have an idea about how we could work around it - if you can have the debian guys raise a bug in our bugzilla and set it as a "build" problem, I'll look at it | 09:45.48 |
| kapouer | ok, i am forwarding that right now | 09:47.20 |
| | chrisl: i filled #692891 | 09:57.05 |
| chrisl | kapouer: okay, I'll try to look at it tomorrow, or early next week. | 09:58.01 |
| kapouer | chrisl: thank you | 10:01.58 |
| chrisl | Aha, it looks like recent libjpeg versions *do* have the facility to override memory management functions...... | 10:06.47 |
| kapouer | lucky :) | 10:09.36 |
| chrisl | I don't know if it actually *works*, though! | 10:13.31 |
| kens | Presumably we'd need to update to the latest libjpeg, or do we haev tha already ? | 10:13.57 |
| chrisl | OOps, didn't mean to leave! | 10:14.37 |
| kens | Scared off by the question ? :-) | 10:14.48 |
| kapouer | jpeg is at 8d, gs9.05 has 8c | 10:15.22 |
| chrisl | Yep, we're very near the latest, we *should* be fine | 10:15.47 |
| kapouer | were you referring to jpeg_mem_src and dest ? | 10:16.12 |
| chrisl | Huh? | 10:16.32 |
| kens | I may *finally* have a solution for this stupid PCL downloaded TreuType font problem.... About to test, one..more..time.... | 10:16.47 |
| | cd /c/ghostpdl | 10:16.57 |
| | oops, wrong window | 10:17.04 |
| Robin_Watts | tor8: The _setjmp/_longjmp stuff solved the customers performance problems. | 13:35.57 |
| kens | That's good. | 13:36.12 |
| Robin_Watts | but we are now having crashes in the threaded handling of images with masks. | 13:36.23 |
| kens | :-( | 13:36.31 |
| Robin_Watts | I think I know what's going on, but I'm having trouble visualising a solution. | 13:37.17 |
| | at the moment, pixmaps have an optional pointer to a 'mask' pixmap. | 13:37.39 |
| | The problem is that when we come to need an image at a given size, we may want to throw away that mask and redecode one at a larger size. | 13:38.10 |
| | IF we do that, and something is using the current one, we cause a SEGV. | 13:38.32 |
| | The problem is the reference counting can't help us here. | 13:38.42 |
| | I think that maybe I need to move the mask pointer out of the pixmap, and into the image. Any thoughts ? | 13:39.02 |
| | In fact, it may be easier to move to always passing the image and the mask images separately. | 13:44.08 |
| Robin_Watts | goes for lunch and hopes tor8 will see this by the time he comes back. | 13:44.23 |
| tor8 | Robin_Watts: yes, the mask should be part of fz_image / pdf_image not the pixmap | 13:57.53 |
| | it's only used by the PDF interpreter | 13:58.08 |
| | the device (iirc) doesn't know about the mask argument in fz_pixmap | 13:58.46 |
| Robin_Watts | Ah, in which case, I think I like the idea of having 2 fz_images, one for the mask, one for the image. | 14:29.38 |
| tor8 | yes. do you want to put the mask image in the pdf_image subclass? | 14:33.37 |
| Robin_Watts | Not sure. I'll see what way the code falls out. | 14:39.04 |
| Robin_Watts | confused; I just removed mask, and all the places where it's kept/dropped/assigned... and it all compiled. | 14:43.38 |
| | I can't see where it was ever actually used. | 14:43.46 |
| tor8 | Robin_Watts: pdf_show_image() is where it's used | 14:47.59 |
| Robin_Watts | I suspect I only use image->mask now rather than pixmap->mask. | 14:48.24 |
| tor8 | so I guess you just forgot to remove it from fz_pixmap when you moved that into fz_image | 14:48.27 |
| Robin_Watts | Which means I can drop it with no problems. | 14:48.29 |
| tor8 | yeah :) | 14:48.34 |
| Robin_Watts | git push | 14:48.46 |
| | ahem. | 14:48.52 |
| tor8 | git shove ;) | 14:48.58 |
| henrys | hey chrisl I am not seeing the japanese fonts in the ufst svn-private, at least the repo I'm hooked up with doesn't seem to have it: URL: svn+ssh://svn.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/ufst | 15:32.42 |
| | maybe you put the entire cd elsewhere? | 15:33.04 |
| Robin_Watts | tor8: OK, that all sanes out fine. customer is testing now. | 15:37.16 |
| | Damn. Still crashing | 15:39.36 |
| mvrhel | I am going to be out for a bit this morning | 16:38.49 |
| | henrys: from Scotts email I guess I should hold off on another reply to the inquiry? | 16:39.18 |
| henrys | right | 16:39.31 |
| mvrhel | ok | 16:39.47 |
| Robin_Watts | OK, mupdf customers crashes have gone away (at least for today) | 16:44.42 |
| | Just time to make tea before javascript conversation... | 16:44.56 |
| kens | what fun... | 16:49.46 |
| henrys | I figure if we can also port this to ghostscript we could easily top 1000 bugs ;-* | 16:51.33 |
| kens | each ? | 16:51.58 |
| Robin_Watts | henrys: Looking at the very simple pcl file you sent... | 16:53.51 |
| | That makes 2 paths. | 16:53.56 |
| | 19 787 moveto 19 47 gapto | 16:54.15 |
| | Then strokes that. | 16:54.19 |
| henrys | write the hp and the previous code does not stroke that first part. | 16:55.14 |
| Robin_Watts | Then 19 787 moveto 19 787 gapto closepath 95 787 moveto 95 711 lineto 19 711 lineto 95 787 lineto | 16:55.15 |
| | then strokes that. | 16:55.19 |
| henrys | s/write/right | 16:55.36 |
| Robin_Watts | Right, well, I'm not in control of when you call stroke :) | 16:55.41 |
| henrys | so basically gl/2 is not allowed to call stroke even if the pen is in the "up" state ... | 16:57.34 |
| | with the new code. | 16:57.49 |
| Robin_Watts | I don't understand GL2 enough to have an opinion. | 16:58.21 |
| henrys | I would think moveto - gapto wouldn't produce anything in stroke mode since there is no lineto but I'm probably trying to apply my gl/2 understanding to postscript. | 16:58.49 |
| Robin_Watts | Indeed, moveto gapto shouldn't render anything. | 16:59.17 |
| | but moveto gapto closepath will. | 16:59.31 |
| henrys | hmm that doesn't seem right why is that? | 17:00.19 |
| Robin_Watts | Because closepath closes the current shape with a line. | 17:00.39 |
| | Maybe that's bad in hpgl mode. | 17:01.10 |
| henrys | yes hp strokes if the pen is down think of a plotter. | 17:01.53 |
| Robin_Watts | How is the closepath generated ? | 17:02.21 |
| ray_laptop | oh boy -- pen plotters :-) (I still have one that runs) | 17:02.34 |
| henrys | does yours draw a line when the pen is up ;-)? | 17:02.52 |
| paulgardiner | :-) | 17:03.00 |
| Robin_Watts | i.e. is there a concept of 'close with pen up' or 'close with pen down' ? | 17:03.05 |
| henrys | I'm puzzled about the closepath | 17:03.07 |
| Robin_Watts | Random thought here. | 17:03.19 |
| | Are you maybe making a new path, doing moveto gapto, and stroking that. | 17:03.37 |
| henrys | normally I look at the first and last point in the subpath if they are close enough I do a closepath. | 17:03.42 |
| Robin_Watts | Then rather than binning the path and making a new one, you're doing a closepath and continuing ? | 17:03.59 |
| henrys | the only reason to do the closepath is to get the join right. | 17:04.19 |
| Robin_Watts | Which is why the second path starts with the first. | 17:04.27 |
| | Right. So presumably you shouldn't do a closepath if the pen was up ? | 17:04.46 |
| tor8 | paulgardiner, Robin_Watts: so, about the javascript project, go forward with what we agreed on yesterday or do we need to discuss it more? | 17:05.03 |
| ray_laptop | henrys: mine only draws when the pen is up if the pen is leaking ;-) | 17:05.20 |
| henrys | tor8:I had a few things, maybe trivial. | 17:05.34 |
| Robin_Watts | tor8: Sorry, yes, javascript... | 17:05.44 |
| henrys | the goal is not really javascript but forms - so what about the rest of chapter 8.6.4 of the pdf manual? | 17:06.25 |
| | will that work be done by tor8 in parallel with paulgardiner's work? | 17:06.44 |
| paulgardiner | Ah good. Was going to be my first question. | 17:06.45 |
| tor8 | henrys, paulgardiner: Robin and I basically came to the conclusion that we'll need to (a) have basic forms without javascript in place, and (b) know more about what the javascript bindings require, to progress | 17:06.46 |
| paulgardiner | i.e. Is it mainly forms? | 17:07.03 |
| Robin_Watts | The impetus for this work is that one of our competitors in the space has "form filling" as one of it's capabilities. | 17:07.31 |
| paulgardiner | Do we display forms already to some degree? | 17:07.33 |
| Robin_Watts | And we don't. | 17:07.34 |
| tor8 | ...and for forms to be actually useful (as opposed to just a checkbox item) they'll need javascript support | 17:08.08 |
| henrys | so it sound like paulgardiner should hold off for a bit. | 17:08.10 |
| Robin_Watts | We've never done form filling before because 1) it requires javascript for validation to be useful, and 2) it requires a more complex interface to applications. | 17:08.19 |
| | i.e. we need to allow form fields to be displayed and edited. | 17:09.02 |
| henrys | tor8:so we don't have enough information for paul to start without a & b in place? | 17:09.41 |
| tor8 | henrys: I'm in favour of letting paul handle form support too, if paul is not vehemently opposed to the idea | 17:09.48 |
| Robin_Watts | I suspect that all this stuff is tied up together; the extensions required for form display/filling are going to be intimately related to the extensions required for handling javascript. | 17:10.21 |
| tor8 | henrys: i.e. paul could start by doing a and b would be my suggestion; since that'll flow on with further work on the actual javascript bindings | 17:10.35 |
| paulgardiner | I was imagining I'd be involved in that part too. | 17:10.53 |
| Robin_Watts | (i.e. we have to cope with updates going into/out of some form data structure, either driven by javascript or by application input). | 17:10.54 |
| henrys | are you good with that paulgardiner? | 17:10.58 |
| Robin_Watts | As such I'd think that it's all part of the same job (at least the specification should include both parts). | 17:11.22 |
| paulgardiner | Yes. Definitely. At a high level it probably all should be planned together. | 17:11.33 |
| Robin_Watts | So I'm taking a long time to agree with Tor here :) | 17:11.41 |
| henrys | There are the 4 pieces in 8.6.4 | 17:11.42 |
| | right? | 17:11.44 |
| | but some of this stuff looks as hairy as javascript XFA etc. | 17:12.11 |
| ray_laptop | forms _definitely_ require javascript, but javascript is used for lots of other stuff besides forms | 17:12.23 |
| kens | Goodnight all. | 17:12.30 |
| paulgardiner | I'm reading the wrong doc. I have 8.6.4 as Device color spaces. | 17:12.35 |
| ray_laptop | bye, kens | 17:12.37 |
| Robin_Watts | Submit forms/Reset forms/Import data/Javascript actions. | 17:12.39 |
| | paulgardiner: You need the 1.7 pdf spec. | 17:12.47 |
| | hold on... | 17:12.51 |
| paulgardiner | I think that's what I have | 17:12.59 |
| | PDF 32000-1: 2008 | 17:13.10 |
| Robin_Watts | Ah, no, that's the ISO spec. | 17:13.22 |
| | It's the same stuff with the sections renumbered. | 17:13.29 |
| henrys | ray_laptop:right but we are targeting forms as the goal of this project - presumably if we want to use js for other stuff we can add it later. | 17:13.34 |
| Robin_Watts | Look for Interactive Features => Form Actions | 17:13.50 |
| paulgardiner | There seems to be quite a lot of interaction that PDF can do without javascript too. | 17:14.01 |
| henrys | tor8:where will all this plugin - to the point will it move over to ghoscript when the parser is brought over. | 17:14.01 |
| tor8 | henrys: there's also the issue of people wanting to print out the filled out pdf... | 17:14.05 |
| | henrys: I see it as a layer separate from the graphics library | 17:14.32 |
| paulgardiner | Robin_Watts: Ah good "Form Actions" is what I've been mostly reading today | 17:14.36 |
| henrys | wants to check if printing really works. | 17:15.19 |
| ray_laptop | henrys: I don't know what the priority is for customers, but the other thing javascript does is appearance change on viewer 'mouseover' and click, etc. | 17:15.38 |
| | henrys: this is for annotations | 17:15.52 |
| henrys | ray_laptop: the goal is to be competitive with chrome's builtin. | 17:16.08 |
| tor8 | henrys: the mupdf parser for the ghostscript graphics library will be done as a mupdf device that bridges mupdf graphics calls to the gs graphics library | 17:16.11 |
| | at least that's what my prototype of that code does | 17:16.25 |
| paulgardiner | It seemed to me that form filling was a very restricted form of document editing. The doc describes the form data being stored in the PDF's dictionaries and being saveable back to a file | 17:16.30 |
| Robin_Watts | Normally, we treat PDF content as unflowed graphics etc. When we come to do editing, at least bits of the document (the form editable bits) will need to exist in a parallel data structure as editable content. | 17:17.00 |
| paulgardiner | I mean the PDF ref describes | 17:17.07 |
| ray_laptop | tor8: presumably a mupdf device w/o the fitz display list, right ? | 17:17.11 |
| henrys | I found some toy pdf forms here, the calculator is interesting:http://www.planetpdf.com/developer/article.asp?ContentID=6575 | 17:17.20 |
| Robin_Watts | And the changes to that will need to relay out into the static graphics data representation. | 17:17.36 |
| tor8 | ray_laptop: yes. the fitz display list is "just another fitz device". | 17:17.37 |
| Robin_Watts | tor8: And ghostscript would be 'just another device' too ? | 17:18.04 |
| ray_laptop | tor8: so the 'bridge' device is a fitz device ? | 17:18.16 |
| tor8 | ray_laptop: correct. | 17:18.22 |
| paulgardiner | Robin_Watts: the reference manual seems to describe it as an operation on the dictionaries. I don't know if it is important that it is done like that. | 17:18.23 |
| tor8 | a fitz device that translates the fitz drawing commands into gs graphics library calls | 17:18.46 |
| ray_laptop | tor8: sounds good ! | 17:18.57 |
| Robin_Watts | paulgardiner: Some things aren't in dictionaries, aiui. | 17:19.28 |
| tor8 | ray_laptop: I have a prototype that does vector graphics and fonts, but it's incredibly hacky and bit rotted by now | 17:19.34 |
| Robin_Watts | but I could be wrong. | 17:19.41 |
| | but essentially, yes, the PDF dictionaries may be the 'editable format' that I was referring to. | 17:20.07 |
| tor8 | Robin_Watts: we may want to bring better handling of annotations into this project, since they also have all this mouse hover events (and javascript hooks I would assume) | 17:20.16 |
| paulgardiner | There is a description of the form data being turned into a "appearance stream" | 17:20.23 |
| ray_laptop | tor8: I'm not surprised -- you (and Robin_Watts) have been reworking a lot of mupdf and it's been a while since it had any priority | 17:20.30 |
| Robin_Watts | Right. I almost said "appearance stream", but I bottled it. | 17:20.46 |
| | AIUI, our annotation support is limited because we don't do much in the way of appearance stream synthesis. | 17:21.27 |
| ray_laptop | tor8: but, personally, I'd like to see it and have it in available to deal with performance issues like cust 532 has. For one thing, I expect that it will run WITHOUT a GC memory allocator | 17:21.28 |
| paulgardiner | And it describes appearence streams being assigned back to dictionaries and the ability to save the whole lot back to a file. I don't know if that is important or not. | 17:21.50 |
| Robin_Watts | So this sounds like an ideal opportunity to solve that too. | 17:21.52 |
| | paulgardiner: Well, we already have code to spit PDF files to disc. | 17:22.19 |
| | (our repair tool reads the file into memory then writes it out again) | 17:22.33 |
| paulgardiner | My worry is that the JavaScript may be able to access the appearance streams, and if we haven't created them, then it might fail. | 17:22.38 |
| tor8 | ray_laptop: yes. it shouldn't be too hard to revive. one of the main stumbling blocks is not the actual bridge device, but getting the main loop and page setup working (and then there's the build system) | 17:22.41 |
| chrisl | henrys: sorry, I've been out today (and going out again shortly...) | 17:22.48 |
| | henrys: svn+ssh://svn.ghostscript.com/var/lib/svn-private/ghostpcl/trunk/ufst-6.2/fontdata/ttfonts | 17:22.58 |
| henrys | the meeting about pdf forms should be over shortly. | 17:23.12 |
| Robin_Watts | paulgardiner: I think we *should* be creating appearance streams. | 17:23.16 |
| ray_laptop | tor8: well, we can leave the build system up to chrisl ;-) | 17:23.17 |
| tor8 | ray_laptop: you're evil :) | 17:23.31 |
| paulgardiner | On the other hand, it would be much simpler to handle form data at the static render list level if possible | 17:23.45 |
| tor8 | Robin_Watts, paulgardiner: I know the sumatra folks have some appearance stream synthesis going on | 17:24.51 |
| henrys | The other thing I had in my notes were to ask about security concerns - obviously JS opens a can of worms. Is anyone up on these issues? | 17:24.55 |
| Robin_Watts | henrys: Well, it depends what javascript functions we implement. | 17:25.28 |
| tor8 | henrys: if we don't expose the "launch an exe file" api we should be fine :) | 17:25.33 |
| Robin_Watts | If we implement the javascript functions for reading/writing from local disc, then we're in trouble. | 17:25.56 |
| tor8 | and IMO the javascript hooks should be build optional, and have a toggle to turn off at runtime as well | 17:26.06 |
| henrys | okay so we'll just deal with that "as it comes" so to speak. | 17:26.14 |
| Robin_Watts | but if we stick to only allowing access within the file itself then there is no real data leakage possible. | 17:26.28 |
| paulgardiner | tor8: yes | 17:26.29 |
| Robin_Watts | yeah. | 17:26.30 |
| henrys | I'm playing with http://www.planetpdf.com/codecuts/pdfs/tutorial/calc.pdf | 17:27.05 |
| | prints okay even after entering new data. | 17:27.22 |
| Robin_Watts | The = function is b0rked though. | 17:28.33 |
| | 123 = 0 apparently. | 17:28.38 |
| henrys | that's all I had for now but to be honest I haven't carefully read 8.6 I'm sure things will come up as we go forward. | 17:29.00 |
| | I just skimmed it. | 17:29.30 |
| Robin_Watts | I meant to read that and the Acrobat Javascript API document today, but was buried by the mupdf customer. | 17:29.57 |
| paulgardiner | Me too, but there was enough to keep me going in the main reference manual. | 17:31.00 |
| henrys | I feel like we are putting paul in neverland without good direction. | 17:31.30 |
| paulgardiner | I wasn't really expecting this meeting to lead to a clear way forward. I imagined a number of discussions would be needed. | 17:31.53 |
| Robin_Watts | I expected the initial part of the project to be laying out a roadmap. | 17:33.32 |
| paulgardiner | I'm happy to be the one finding out what the issues are. But also happy to hold off if you feel someone with more MuPDF knowledge might be better starting it off. | 17:33.38 |
| henrys | we can also look at it bottom up - we can implement "submit form actions" with tor doing a little steering but I'm afraid we'll miss something. | 17:34.08 |
| paulgardiner | I'm happier with top down... as much as that is possible. | 17:34.37 |
| | I don't think we can make many decisions without a clear understanding of how JavaScript interacts with documents i Acrobat. | 17:35.11 |
| Robin_Watts | Submit Form actions shouldn't be hard to do, but its utility is predicated on us having 'selected interactive form fields' to submit. | 17:35.55 |
| paulgardiner | Do we even *display* forms? | 17:36.36 |
| henrys | from my skimming as far as forms go javascript just looks like a calculator for the data. | 17:36.50 |
| tor8 | paulgardiner: we have *no* forms support at all today | 17:37.17 |
| Robin_Watts | AIUI, most forms have a standard PDF file, with a bunch of annotation like things for fields. | 17:37.26 |
| tor8 | we have limited annotation support (only annotations with defined appearance streams) | 17:37.28 |
| henrys | it seems like we shouldn't even be talking about javascript just yet we need the basic form support first. | 17:38.07 |
| Robin_Watts | So if you display a form in mupdf you see the form - but you have no way of interacting with where the data goes in. | 17:38.15 |
| paulgardiner | Ok. The way Javascript interacts with forms might force a particular way to implement them. | 17:38.56 |
| | s/Ok.// | 17:39.11 |
| ray_laptop | almost all forms (afaiu) use javascript to process the data being entered for the form (check type of response, range, etc.) | 17:39.15 |
| henrys | paulgardiner:true that's what I was just going to ask tor8 about. | 17:39.20 |
| Robin_Watts | henrys: Right. The only reason we need to think about javascript initially is that we need to ensure that whatever scheme we come up with responding to application input etc can cope with javascript making changes too. | 17:39.29 |
| Robin_Watts | needs to type faster. Or less verbosely. | 17:39.42 |
| paulgardiner | I'm limited in what I can say at this stage because I've yet to read the PDF JavaScript API. | 17:40.02 |
| | Robin_Watts: Yes (to last but one statement :-) ) | 17:40.38 |
| ray_laptop | the other important part in form filling is to be able to save the resulting filled in form as a 'flattened' PDF. So the values that were entered become what is seen in the saved PDF | 17:41.04 |
| Robin_Watts | ray_laptop: If it's just a matter of writing things back to the dictionaries used to define the form fields, I think we're good. | 17:41.36 |
| | Because (as I said above), we already have code that saves out a PDF file from the memory representation. | 17:42.03 |
| paulgardiner | The whole process might most naturally work on the dicstionary structure. | 17:42.10 |
| ray_laptop | Robin_Watts: what I don't know is if the resulting PDF is expected to no longer support editing. I haven't looked at what Acrobat does | 17:42.30 |
| paulgardiner | Although if it does,, that might not make it easy to unify PDF and GhostScript | 17:42.34 |
| Robin_Watts | pdfclean already uses that to read in objects, make changes to them (uncompress/repair/unencrypt) then write it out. | 17:42.45 |
| henrys | tor8:I am having trouble imagining how a good form framework without knowledge of javascript would be a design problem with javascript but maybe I'm not being imaginative enough. | 17:42.46 |
| Robin_Watts | I suspect that ghostscript would remain non-interactive. | 17:43.10 |
| | i.e. forms are not an issue for the gs integration. | 17:43.35 |
| | henrys: Well, it's only a problem in that there are several different things all accessing data at the same time. | 17:44.14 |
| tor8 | henrys: well, a form framework will need callbacks and hooks for whatever GUI is used (win32, gtk+, ios, android, whatever) and the javascript bindings used in PDF may have some demands on that as well | 17:44.35 |
| paulgardiner | henrys: the problem I can envisage is implementing without JavaScript in mind, might lead us to work at the "display list" level, only to find out that JavaScript more naturally works on the dicitionaries directly. | 17:44.57 |
| tor8 | so I think we'll want to read through the javascript enough to know whether any approach we decide on will paint us into a corner or not | 17:45.00 |
| henrys | fair enought | 17:45.23 |
| paulgardiner | tor8: yes exactly. | 17:45.24 |
| tor8 | and then there's the whole thing as paul just pointed out, which level do the javascript bindings actually work on. do they touch the pdf objects and dictionaries directly, or operate on a higher more abstracted level? | 17:45.49 |
| ray_laptop | it's been a few years since I looked, but I think it works on the PDF structures | 17:46.57 |
| paulgardiner | tor8: Yes. And it may take a fair bit of planning before we can be sure which is best. | 17:47.10 |
| ray_laptop | but ignore that because it's been so long | 17:47.13 |
| henrys | okay let's all have a read of js api and get together again, say monday? Does that make sense? | 17:47.50 |
| ray_laptop | will take some time to look at the docs as well (with my "ghostscript" glasses on, even tho' mupdf is the primary target) | 17:47.59 |
| paulgardiner | henrys: yes. Sounds good. | 17:48.16 |
| henrys | same time of for everyone 9:00 PST 5:00 UK? | 17:48.36 |
| tor8 | henrys: okay. | 17:48.39 |
| Robin_Watts | Sure. | 17:48.41 |
| ray_laptop | henrys: it's more fun talking about something with almost no knowledge. That's why people go into politics ;-) | 17:48.47 |
| Robin_Watts | I may have to shoot off to pick up Helen at 5:30ish on monday. | 17:49.01 |
| tor8 | I'm popping out for an hour or so | 17:49.03 |
| Robin_Watts | Oh, no, wait, she's going to be later, that's OK. | 17:49.14 |
| henrys | ray_laptop:yeah no fun reading first | 17:49.58 |
| | ray_laptop:I'm sure you're on this but I looked at the profile from your customer and I still see clist calls. | 17:50.40 |
| | maybe BandAlways in these devices? I just looked at the "main" program they sent. | 17:51.18 |
| paulgardiner | henrys: I've spend most of my working life in neverland, so don't worry about sending me there for my sake. :-) | 17:51.28 |
| Robin_Watts | ray_laptop: Are you responding to Erics mail with "Just change the -dBandHeight call!" ? | 17:52.06 |
| ray_laptop | henrys: the WWTT profiles from yesterday morning ? If so, then yes, I realized what was causing that and asked Eric for another go with -dMaxBitmap=20000000 | 17:52.06 |
| | Robin_Watts: yes | 17:52.15 |
| henrys | paulgardiner:that's why they pay us the big bucks ;-) | 17:53.35 |
| ray_laptop | henrys: I don't see BandAlways in their gs_main.c -- where did you see it ? | 17:54.11 |
| henrys | I didn't I don't have access to the devices referenced in their main. | 17:54.35 |
| | my read of the conversation was he set the maxbitmap to a very large value and they still got banding. maybe I read it wrong. | 17:55.06 |
| ray_laptop | henrys: did you see my email reply to Eric sent 2/29 at 9:49 PST ? That explains why they were still in clist mode | 17:55.26 |
| | henrys: I just had him remove the -dMaxBitmap= calls initially but forgot that the default MaxBitmap is 10M, and they need > 17M for 1200 dpi | 17:56.26 |
| | so in the follow up email, I requested that he restore the -dMaxBitmap= option with -dMaxBitmap=20000000 | 17:57.14 |
| henrys | ah sorry I did miss that, thanks | 17:57.28 |
| ray_laptop | but haven't seen any response | 17:57.29 |
| Robin_Watts | So, if we're off forms/javascript for a bit... | 17:58.01 |
| | henrys: can we carry on with this HPGL stroking stuff ? | 17:58.14 |
| henrys | I thought the ball was in my court not to closepath if the pen is up? | 17:58.40 |
| Robin_Watts | Ah, OK. | 17:59.02 |
| ray_laptop | in the meantime, I'm working on their other critical performance issue. The file they have takes them 24 min for 243 pages on the target, but less than 4 minutes on the simulator on my laptop, and standalone gs 8.71 only takes 45 seconds | 17:59.04 |
| Robin_Watts | I'm happy then :) | 17:59.12 |
| henrys | Robin_Watts:I can do that change independently as it's probably good anyway | 17:59.37 |
| ray_laptop | henrys: I'm hacking on their source to build standalone gswin32c with their stuff removed so I can run without the simulator to see why it (the simulator) is slower than 8.71 | 18:00.42 |
| | henrys: unfortunately, when the team in japan does stuff, they don't parcel it out nicely -- just go hacking things in wherever they feel like :-( | 18:01.32 |
| henrys | chrisl:hmm - my local repository points to the right place but svn up doesn't seem to grab that ttfonts directory. | 18:02.12 |
| ray_laptop | I have better control over the team out here, and have sometimes been able to get them to change stuff that came from japan to make it more modular. | 18:02.14 |
| Robin_Watts | henrys: I can commit what I have with the pcl change backed out of it you want. | 18:02.38 |
| henrys | yes go ahead. | 18:02.55 |
| chrisl | henrys: let me check..... | 18:03.01 |
| ray_laptop | bbiab. | 18:03.15 |
| henrys | my svn is rusty | 18:03.47 |
| | bbiam | 18:04.17 |
| chrisl | henrys: you are checking the ufst-6.2 directory? | 18:04.19 |
| henrys | right that's it | 18:05.17 |
| | thanks | 18:05.29 |
| | wow the do have a good collection of cjk fonts. | 18:07.12 |
| | s/the/they | 18:07.33 |
| chrisl | Yes, it's pretty decent. I'm going to try tomorrow to check whether one of the Japanese fonts is a good substitute for MS-Gothic | 18:09.53 |
| henrys | well the idea was to approach urw about making these fonts, I wasn't planning on mortgaging artifex to do it. you think the japanese fonts would be a good start. | 18:10.46 |
| | ? | 18:10.56 |
| ray_laptop | cust 532 is happy with the ufst japanese fonts | 18:11.39 |
| | so this other outfit should be as well | 18:11.50 |
| chrisl | Like I say, I'd like to have a play with them, and get a feel for it before I give an opinion, but (as Ray just said) if cust 532 are okay with them, I'm leaning towards thinking they're okay | 18:12.15 |
| | I'd also say that the quality of the Japanese fonts in there is better than the quality of the western fonts in the Microtype collections! | 18:13.24 |
| Robin_Watts | sebras: ping ? | 18:13.48 |
| henrys | okay, for now I think I'll get estimates for the japanese fonts from urw | 18:13.51 |
| chrisl | henrys: it looks like URW already have Japanese fonts in their library, so it might be worth asking both them and Monotype for licensing costs? | 18:14.56 |
| | henrys: I need to head out again - I think (whatever else we do) getting info from URW is worth doing. | 18:16.33 |
| henrys | I'm looking to buy the fonts from urw and in the past we've directed other customers to check with monotype - monotype won't license stuff to us. | 18:16.40 |
| | woops | 18:16.46 |
| chrisl_away | No saw the reply - as I said, I think URW should be our first port of call anyway | 18:17.10 |
| chrisl_away | really off now..... | 18:17.31 |
| Robin_Watts | henrys: Has there previously been Artifex/Monotype friction then ? | 18:17.41 |
| | or do they just not want to license to a company for them to relicense again? | 18:18.14 |
| henrys | no they license to the company that finally uses them I assume their price is a function of revenues company size etc. | 18:18.47 |
| Robin_Watts | Right. Makes sense. | 18:19.29 |
| henrys | ray_laptop:is is possible to get 532's font list to include asian fonts? | 18:29.31 |
| ray_laptop | henrys: I don't understand the question ? | 18:30.02 |
| henrys | a list of resident fonts for the printer | 18:30.21 |
| | does it include say hggothic or other japanese fonts? | 18:31.01 |
| | hgmincho? | 18:31.08 |
| ray_laptop | chrisl_away: would probably know how to find that more easily than I. They've hacked mightily on the font and CIDFont mechanisms | 18:31.30 |
| henrys | okay I'll ask him. | 18:31.45 |
| | or better yet I'll assume he'll read the logs | 18:32.31 |
| ray_laptop | henrys: that's better management style -- assume what your staff will do ;-) | 18:33.48 |
| | I learned that from the pointy haired guy ;-) | 18:34.25 |
| | well, I FINALLY got the standalone gswin32c for cust 532 building. Now I have to dig into all of the places they hacked up the init files :-( | 18:41.13 |
| | wait a minute -- I can just put the standard 8.71 ones alongside in a different directory. | 18:41.40 |
| henrys | well I can get prices on mincho and gothic and that will tell us what we're in for money wise. | 18:43.48 |
| ray_laptop | HURRAY. I have it running with 872_pre-icc initfiles :-) | 18:54.01 |
| | now to check the timing... | 18:54.11 |
| sebras | Robin_Watts: jao..? | 19:24.56 |
| Robin_Watts | I'm just adding documentation to fitz.h for the store. | 19:25.13 |
| | Wanted to check that I wasn't about to conflict with you. | 19:25.24 |
| sebras | Robin_Watts: nope, I'm aiming to work more on the docs tomorrow and during the weekend, but probably not tonight. | 19:25.58 |
| | Robin_Watts: so go ahead. | 19:26.11 |
| Robin_Watts | I've done the store and images. Doing bitmaps now. I suspect Context and Threading is the next bit. | 19:26.16 |
| | tor8, sebras: Are we intending to split fitz.h into fitz.h and fitz-internal.h ? | 19:26.50 |
| sebras | ok, would it make sense to add my MT-example next to example.c? | 19:27.19 |
| | example-threaded.c | 19:27.30 |
| tor8 | Robin_Watts: eventually, but not before 1.0 | 19:27.38 |
| Robin_Watts | Probably. | 19:27.42 |
| | tor8: Ah, well, I was thinking that before 1.0 would be when we wanted to do it. | 19:27.59 |
| | because that way stuff in fitz.h would be 'frozen' and stuff in fitz-internal.h wouldn't. | 19:28.20 |
| tor8 | Robin_Watts: clients would still only include <fitz.h>? | 19:28.30 |
| Robin_Watts | Yes. | 19:28.34 |
| | In other words, we filter out everything that our apps currently call into fitz.h and put the rest in fitz-internal.h | 19:29.17 |
| sebras | our apps and sumatrapdf. | 19:30.57 |
| tor8 | Robin_Watts: could do. | 19:31.00 |
| Robin_Watts | It would mean that all the typedef struct blah_s blah; can go in the public one, and the actual definitions of struct blah_s can go in the internal ones. | 19:33.44 |
| | Otherwise we are effectively publishing the contents of the structs, and we don't really want that, do we? | 19:34.03 |
| tor8 | no, we want opaque types wherever possible | 19:34.56 |
| | which should be around half of our types | 19:37.43 |
| Robin_Watts | finds the swedish - in doc/overview.txt | 19:41.19 |
| sebras | Robin_Watts: you can remove it if you want to. :) | 19:41.37 |
| | Robin_Watts: or try to translate it into something meaningful... | 19:41.50 |
| Robin_Watts | I can't do that. I don't know what it says. | 19:41.52 |
| | It might say "Do not remove." | 19:41.59 |
| sebras | Robin_Watts: now that you mention it... | 19:42.16 |
| tor8 | maybe we should formalise some sort of code review system so we don't let swedish and whitespace errors through ;) | 19:42.25 |
| Robin_Watts | I'm sorry about whitespace errors; I always try to check my stuff before I push, but... | 19:43.06 |
| sebras | I was hoping that Robin would spot the Swedish, but alas... :) | 19:44.04 |
| | or well, he did just now. | 19:44.26 |
| | anyway, feel free to remove it, it's just random ramblings about threads and probably factually inaccurate. | 19:44.52 |
| Robin_Watts | tor8: I was supposed to move the antialiasing stuff into the device, wasn't I? | 19:46.59 |
| tor8 | Robin_Watts: not a high priority. can you think of a cleaner way to do it than the global context? I'm not sure I can... | 19:47.46 |
| Robin_Watts | Now I shall suffer the indignity of having my english corrected by the Swedes :) | 19:47.49 |
| sebras | Robin_Watts: I already corrected some of your typos. I almost corrected centre as well... :) | 19:48.49 |
| Robin_Watts | tor8: Having the antialiasing stuff in the device rather than the context 'feels right', as it's only needed in that particular device. | 19:50.25 |
| | but I suspect that that may mean one or two functions deep down have to pass an extra param. | 19:50.47 |
| tor8 | Robin_Watts: yeah, but I think it means passing along more arguments to the already argument heavy painting/plotting functions | 19:51.04 |
| | or maybe it stops just short of those | 19:51.13 |
| | yeah, I think it stops at the scan conversion function actually | 19:51.31 |
| | so it shouldn't be too bad | 19:51.41 |
| | "The ADBC plug-in allows JavaScript in PDF documents to access databases through a consistent object | 19:53.00 |
| | model. ADBC is a Windows-only feature and requires ODBC to be installed on the client machine." ugh... bloated this spec is | 19:53.00 |
| Robin_Watts | tor8: Yeah. I figured we'd ignore as much of it as we could. It may be worth us taking some files apart to see what's actually commonly used. | 19:53.52 |
| sebras | Robin_Watts: I proposed this to tor8 over dinner just now. | 19:54.16 |
| Robin_Watts | Like, I imagine we're not particularly fussed about the ability to create whole new documents. | 19:54.27 |
| tor8 | yeah, the whole "batch processing documents" seems a bit overkill, as well as the "let's control the acrobat application" calls | 19:55.06 |
| Robin_Watts | Yes; useful for people wanting to script acrobat to extract images (mentioning no marcosw's), but useless for what we want, I think. | 19:55.48 |
| tor8 | annotations are exposed as a high level javascript object, not tying in to the pdf dictionaries | 19:55.48 |
| | var gannot = this.getAnnot(0, "myNote"); | 19:56.49 |
| | gannot.contents += "\r\rDonât forget to check with Smith"; | 19:56.50 |
| Robin_Watts | Right, but how closely does that mirror the structure of annotations? | 19:57.29 |
| sebras | tor8 Robin_Watts: there also appears to be a way to specific forms using XML in PDF... | 19:57.44 |
| tor8 | seems to map fairly one-to-one on the dict structure, thankfully | 19:57.49 |
| Robin_Watts | sebras: I saw examples of defining forms entirely from javascript in the docs :( | 19:58.35 |
| | But that may be a rarely used thing - as I say, we may need to look at some files. | 19:58.56 |
| sebras | right, the XML is also used to handle rich text in input fields. | 19:59.04 |
| tor8 | Robin_Watts: urgh. the 'app' object can be used to create GUI dialogs dynamically from JS. | 19:59.24 |
| | and the lovely app.execMenuItem("SaveAs") type of things | 20:00.06 |
| | drop the P in PDF already! | 20:00.27 |
| Robin_Watts | Yeah, but we can ignore that kind of rubbish I'm sure. | 20:00.37 |
| tor8 | I certainly hope so! | 20:00.45 |
| sebras | drop the D as well, since video and U3D that is no longer the focus... | 20:01.05 |
| | somehow MuF is not a good product name though. :) | 20:01.44 |
| Robin_Watts | Actually, as always type3 fonts are a pain. | 20:28.32 |
| | I'm going to leave it as is. | 20:28.41 |
| sebras | Robin_Watts: I only have access to a small subset of my test PDFs here, but the javascript used is centered around display/hiding of objects, file attachments and HTML-form submission. | 20:35.20 |
| Robin_Watts | HTML-form submission? Or HTTP form submission? | 20:35.45 |
| sebras | HTML-forms submitted over HTTP to a domain. | 20:37.07 |
| | so lots of URL-encoding. | 20:37.19 |
| Robin_Watts | So the values from our form get encoded into HTML and that gets sent. | 20:37.34 |
| | Rather than the values just going in a GET header request. | 20:37.45 |
| sebras | yes. | 20:39.23 |
| | the first option. | 20:39.29 |
| henrys | /names | 21:29.40 |
| | mvrhel:I said in the agenda followup we'd talk about output intent tuesday but we didn't have the meeting. Should I send email to alexcher_ so we can have a meeting about it. | 22:10.06 |
| | ? | 22:10.07 |
| mvrhel | henrys: no need to. alexcher_ sent me a patch. It seems to be doing what I needed and I am working on a few issues in my stuff now | 22:10.46 |
| henrys | super | 22:10.58 |
| | Forward 1 day (to 2012/03/02)>>> | |
IRC Logs