| <<<Back 1 day (to 2013/07/31) | 2013/08/01 |
sebras | tor*: rebased sebras/master. | 09:06.10 |
| tor7: agh! now I know why I haven't bothered with x11 form input before. | 10:19.34 |
tor7 | sebras: pain in the ass? | 10:20.01 |
sebras | tor7: the wintextinput() callback is designed to be modal, which means reproducing the x11 main() loop in that function as well. | 10:20.01 |
| tor7: for win32 paul(?) just pops up a dialogbox which blocks until the text is fully entered. | 10:20.30 |
| in the x11 case you really want to set the state and pop back to the main loop and have that fiddle with expose-events and so on. | 10:20.55 |
| oh and I wonder what the retry argument is for... | 10:21.08 |
tor7 | sebras: system("zenity") ;) | 10:21.09 |
sebras | tor7: no, not for x11. | 10:21.18 |
| but, yes something like that _would_ have worked. | 10:21.31 |
tor7 | sebras: could split the main loop into a main_loop_iter() function | 10:22.08 |
| that can be called recursively to handle events | 10:22.14 |
| for a modal dialog, you basically just want to trap mouse/keyboard events and direct to the dialog | 10:22.35 |
| expose events and resize events still need to be handled for the main window | 10:22.48 |
sebras | haven't though about the details, but I'd probably need to make more variables global in that case. | 10:22.56 |
tor7 | but I think a better solution would be to implement inline form editing for both win32 and x11 apps | 10:23.13 |
sebras | tor7: how does the win32 viewer do that..? | 10:23.18 |
tor7 | all the focus has currently been on the android app | 10:23.24 |
sebras | what do you mean by "inline"? | 10:23.31 |
| to do it in the field form itself? | 10:23.44 |
tor7 | sebras: I think windows prevents you from moving a window when a modal dialog is up | 10:23.53 |
| sebras: yes. | 10:24.01 |
sebras | right. | 10:24.05 |
| yes, that would probably be the Right<tm> way. | 10:24.13 |
tor7 | sebras: or do it in a non-modal text input field at least | 10:24.25 |
| ah, speaking of the devil :) | 10:24.31 |
| hi paulgardiner | 10:24.33 |
sebras | hi paulg! | 10:24.38 |
paulgardiner | Oh dear. What have I broken? :-) | 10:24.49 |
sebras | :) | 10:24.54 |
| paulgardiner: do you remember the wintextinput() interface? | 10:25.10 |
| what is the retry argument meant to do there..? | 10:25.16 |
paulgardiner | It's something to do with mupdf rejecting the text and asking the user to have another go. Let me look a minute | 10:26.18 |
sebras | oh, yes that makes sense. I was stuck in lookig at td_retry in platform/x11/win_main.c. | 10:26.49 |
| but looking at the loop in pdfapp_onmouse() makes it a whole deal easier to understand. | 10:27.17 |
paulgardiner | Ah good... I'm sure I'll understand it again in a bit :-) | 10:27.44 |
| Oh I see. It's so that things like mujstest can avoid getting stuck in a loop that a user would know to avoid. | 10:28.50 |
sebras | wait... isn't mujstest only used for running cluster tests? | 10:29.41 |
paulgardiner | So if you you are creating a ui, ignore retry, but if you are writing part of the test suite then return NULL if retry is 1 | 10:30.04 |
sebras | I have never used it and I'm not convinced I know its purpose..? | 10:30.08 |
paulgardiner | sebras: Yes, but it does poke widgets and insert text | 10:30.45 |
sebras | alright. | 10:31.06 |
paulgardiner | I assume that was the point of it. I'm guessing mujstest calls pdfapp_onmouse, otherwise I can't think why I added the retry arg. | 10:31.53 |
sebras | agh! where is pdf_widget_s defined? | 11:07.33 |
| and what is the relationship between pdf_annot_s and pdf_widget_s? | 11:09.47 |
| paulgardiner: why are single- and multi-line text widgets handled the same? would it make sense to have different PDF_WIDGET_TYPE_* constants for them? | 11:32.55 |
| also pdf_text_widget_set_text() (well, run_keystroke() really) does not validate the length of the supplied text with respect to MaxLen. should it? | 11:39.08 |
paulgardiner | For historical reasons pdf_widget is just another name for pdf_annot, and there is no definition of pdf_widget_s. Probably we don't want to distinguish the types and should use pdf_annot everywhere. | 11:41.32 |
| But there are some calls that are widget specific. | 11:41.56 |
sebras | I'm trying to detect multi-line text fields because they should handle return differently I believe. | 11:42.15 |
| however I only access to pdf_get_field_flags() which takes a pdf_obj*, but from pdf_focused_widget() I can only get a pdf_widget* which is not the same of course. | 11:43.20 |
| I guess I'm probably asking how this API is intended to be used. ;) | 11:43.40 |
paulgardiner | sebras: Yes. I was intending to eventually handle them differently in the Android app, but don't at the moment. | 11:43.49 |
| The intention is to enhance the API as needed. There is no way currently to detect multi-line (nor password IIRC) | 11:45.04 |
sebras | ok. I might want to do that then. :) | 11:45.25 |
paulgardiner | Yeah sure. It was always intended but never rose hgh enough in the priority list | 11:46.29 |
sebras | I'm trying to get decent form filling input for the x11 viewer. so I may bother you a bit more... | 11:47.37 |
paulgardiner | No probs. It's all things that we want done. | 11:48.13 |
sebras | paulgardiner: where do I get the Correct<tm> version of v8 for building? I only have some v8 prebuilt-binaries 3.9 something. is that what we are using? | 11:55.28 |
paulgardiner | Yeah 3.9 is correct | 11:56.06 |
sebras | paulgardiner: there is a 3.19.11 available from upstream. do you guys intend to update at some stage? I'm unsure whether it matters of course. :) | 11:57.13 |
| paulgardiner: or is this more of a proof of concept thing? | 11:57.26 |
paulgardiner | I don't have a policy in mind. Maybe someone else has, but I'd imagine there is no need to update unless our current version lets us down in some way. | 11:58.39 |
| We shied away from treating it like other thirdparty libs because it is so huge and awkward to build. | 11:59.55 |
sebras | paulgardiner: ok | 11:59.55 |
tor7 | it's big and messy and difficult. we don't want to upgrade unless we really have to. | 12:17.27 |
sebras | tor7: ok. | 12:17.34 |
| paulgardiner: I'm confused. in get_text_widget_info() you do check for multiline widgets but that information is never exposed. | 12:18.06 |
paulgardiner | That's because I need it to generate the appearance stream | 12:19.26 |
sebras | so if I add PDF_WIDGET_TYPE_MULTILINE_TEXT then I should use the type to separate multiline from singleline and not parse the Multiline flag in get_text_widget_info()..? | 12:20.32 |
paulgardiner | Might be better to stick with one text type and have a separate call to find information like Multiline, password etc | 12:21.45 |
| pdf_text_widget_info | 12:22.43 |
sebras | ok. | 12:23.06 |
| paulgardiner: sebras/forms does that look about right to you? | 12:24.36 |
| ideally I would go for the bullet glyph, but I don't know how to look it up and this is better at least. :) | 12:24.54 |
tor7 | sebras: robin will hate you for calling strlen in a for loop | 12:26.30 |
| memset(text, '*', strlen(text)) | 12:26.44 |
sebras | tor7: d'oh!. | 12:27.07 |
| tor7: I blame all of that on stupid glib and gstreamer programmer. :-P | 12:27.23 |
| programming... | 12:27.26 |
tor7 | :) | 12:27.37 |
sebras | tor7: paulgardiner: that commit you saw before was not the commit you were looking for.... | 12:28.12 |
paulgardiner | No. I'm not looking for a commit. Go on your way Luke. | 12:29.01 |
sebras | actually was dressed as Luke in pre-school! | 12:34.45 |
paulgardiner | Well the force is strong in you because I've now forgotten what I was doing. :-) | 12:37.19 |
sebras | paulgardiner: did you intend for pdf_text_widget_set_text() to validate length compared to MaxLen? | 12:57.15 |
paulgardiner | Not sure. Might be better to leave it to the caller as to whether to call pdf_text_widget_info to get MaxLen and then check before makeing ther set_text call | 12:58.59 |
| I'm usure which is best. | 12:59.16 |
| unsure | 12:59.20 |
sebras | paulgardiner: as an app developer wouldn't I like to have the library do those checks for me? it does the js-checking automagically... | 13:00.51 |
paulgardiner | Possibly, but then you might want to tell the user why the text was rejected and having the set_text call return a boolean doesn't quite work. | 13:02.14 |
sebras | paulgardiner: ok, so you want to differentiate not-accepted-due-to-js from not-accepted-due-to-length..? | 13:02.52 |
paulgardiner | With javascrip checks the javascript can make alert calls. We could perhaps fake an alert call when MaxLen is overflowed | 13:02.58 |
sebras | or any other form of acceptance predicate. | 13:03.04 |
paulgardiner | javascript alert calls have a message so the javascript can report the failure any way it want... or not if desired | 13:04.05 |
| maybe pdf_text_widget_set_text should return an error code. | 13:04.50 |
| There's several ways to do it and I'm unsure which I think is best. | 13:06.06 |
sebras | paulgardiner: wow, there are quite a few things not implemented in this form-filling area. | 13:11.14 |
| more than I expected. :) | 13:11.24 |
paulgardiner | A lot, but at least it's all details. All the real nasties are taken care of. | 13:14.04 |
sebras | tor7: getting naïve textediting in place for x11 is not that difficult. but getting it to support highlighting and replacement and having a caret and jump words and so on is more difficult and also I believe that the way things are supposed to be handled (i.e. what key combos should do what) differ between the win32 and x11. | 13:30.26 |
tor7 | selecting text is always a pain | 13:32.04 |
| a caret and key bindings for the common editing/motion commands isn't all that difficult | 13:32.20 |
sebras | tor7: I was contemplating having the font do the rendering of the caret by simply representing it by a vertical bar... ;) | 13:33.21 |
tor7 | XDrawLine at caret x position +/- the font ascent and descent is fine | 13:34.00 |
sebras | tor7: right, thanks for the mio-tip. I'll look at it. | 13:35.38 |
dogisfat | What is the difference between fixed2int_pixround and fixed2int_pixround_perfect? | 14:37.37 |
ray_laptop | henrys: I am responding to Masuda-san about their tray selection problem (turns out they have PXL from their driver). But, looking at pxl/pxsessio.c it looks like their is an error. | 15:41.21 |
henrys | ray_laptop:I sent you email about it did you read it? | 15:42.02 |
ray_laptop | henrys: the MediaSource and MediaDestination commands appear to set ".MediaSource" instead of "%MediaSource" | 15:42.22 |
henrys | ray_laptop:yes I sent you email saying exactly that. | 15:42.58 |
ray_laptop | henrys: I just did. For some reason, when I sorted by "subject" it didn't pop up | 15:43.38 |
| sorrry | 15:43.40 |
| henrys: for consistency, I think we need to use %MediaSource, right ? There is no default handler (in base/gsdparam.c) for ".MediaSource", so it will probably error out | 15:44.50 |
henrys | np they should be different right? I can't imagine the definitions are the same. | 15:44.52 |
ray_laptop | you mean HP has different values between PCL and PXL ? | 15:45.30 |
henrys | sorry I didn't realize that was PCL, what does PS use? | 15:46.57 |
| PCL and XL are slightly different yes. | 15:48.15 |
ray_laptop | henrys: the PS interpreter ignores %MediaSource in put_params | 15:49.01 |
| henrys: or rather, base/gsdparam.c does. | 15:49.24 |
henrys | no I meant which parameter does setpdagedevice use for trays? | 15:49.56 |
| nvm I can look | 15:50.04 |
ray_laptop | henrys: so you are saying that we need several different, incompatible parameters presented to the device. Why shouldn't "normailizing" this be done in the various parser | 15:50.09 |
henrys | I'm not saying anything except the definition of PCL and XL tray selection are different. XL has more choices. | 15:51.07 |
| as per the specifications | 15:51.37 |
ray_laptop | henrys: PS has a key "MediaPosition" in the setpagedevice dict | 15:51.41 |
| henrys: are the PCL keys the same as the corresponding XL keys ? (a proper subset?) | 15:53.07 |
henrys | that's what I'm checking now. | 15:53.25 |
ray_laptop | henrys: thanks. | 15:55.24 |
henrys | sigh of course they are different disjoint | 15:55.28 |
| HP sucks | 15:56.03 |
| I would think the variables should be renamed XLMediaSource and PCLMediaSource | 15:57.07 |
ray_laptop | henrys: so they don't simply map to input tray number ? :-( | 15:58.38 |
henrys | no see pxeMediaSource_t | 15:59.25 |
| in gdevpxen.h | 15:59.38 |
ray_laptop | henrys: where are the definitions for 1-6 for PCL ? | 16:02.19 |
henrys | in the manual | 16:02.34 |
| # = 0 - Print the current page | 16:02.54 |
| (paper source remains unchanged). | 16:02.54 |
| 1 - Feed paper from the a printer-specific tray. | 16:02.56 |
| 2 - Feed paper from manual input. | 16:02.57 |
| 3 - Feed envelope from manual input. | 16:02.59 |
| 4 - Feed paper from lower tray. | 16:03.00 |
| 5 - Feed from optional paper source. | 16:03.01 |
| 6 - Feed envelope from optional envelope. feeder1 | 16:03.02 |
| similar but not quite the same. | 16:03.17 |
ray_laptop | henrys: thanks. I just found it in the manual as well (in 5-4) | 16:04.36 |
henrys | ray_laptop:so we can leave it as is or I can change the parameter names to PCLMediaSource and XLMediaSource, that would be more digestible. Let me know. | 16:05.47 |
ray_laptop | henrys: Or we could create an enum for the superset, mapping corresponding functions together, and make it easier for device code | 16:06.52 |
| henrys: but if we don't try and do it, then we can't do it wrong ;-) | 16:08.52 |
henrys | I agree the device code has to now recognize 2 parameters. But adding another table that we have to remember to update anything one of the other tables changes is usually bad news. | 16:09.35 |
ray_laptop | henrys: since it is already %MediaSource for PCL and .MediaSource for PXL, then I guess they are unique. IMHO, we should add IGNORE_INT_PARAM for .MediaSource, and change %MediaDestination to .MediaDestination, then add comments in gsdparam that these are from PCL and PXL to each | 16:12.04 |
| henrys: why do we even have those in base/gdevpcen.h? I don't see anybody using them | 16:13.56 |
henrys | the language PXL uses the type definition and presumably the XL output devices should eventually also. | 16:15.04 |
| why do the values have to go in gsdparam.c? Why can't it be specific to their device? | 16:17.04 |
ray_laptop | henrys: OK. So it's primarily for when we want to preserve the setting from PXL or PCL. But that means that the PCL and PXL devices will need to handle both params and map the 'other' one accordingly (i.e., PCL devices need to map .MediaSource to a suitable PaperSource value), right ? | 16:17.45 |
| henrys: well, thanks for the help. I'll add this to the response to the customer (explaining why there are two different params and what the values mean) | 16:19.04 |
| henrys: if you want to change the names going forward, that's fine with me. The log should show the old and new names and explain why. That's up to you. | 16:21.35 |
| henrys: do you want me to fix the base/gsdparam.c in the meantime (as I mentioned above) ? | 16:22.00 |
henrys | right there is a gotcha - pcl doesn't set it the tray each job unless the command is explicitly given. | 16:22.00 |
ray_laptop | henrys: why is that a "gotcha" ? | 16:22.24 |
henrys | maybe it isn't but I'm if I select envelope in XL driver do a reset in pcl and send pcl I won't get envelope on an HP printer. | 16:23.33 |
ray_laptop | huh? | 16:24.31 |
henrys | I asked you above why we should add the parameters to gsdparam.c, what does that get us, vs. them just processing the params in their device? | 16:24.56 |
ray_laptop | henrys: sorry. missed that. We want to handle params so we don't return an error | 16:25.33 |
henrys | ray_laptop:confused why aren't we returning an error now? | 16:26.08 |
ray_laptop | if there are params that are left 'unprocessed' on a param list it throws an error | 16:26.10 |
| it probably does, but look are the code in pxsesssio.c it sets ecode, doesn't check it, then goes on to write other params such as Duplex which also set ecode | 16:28.02 |
henrys | about "huh?" sorry that was unclear: the problem is if a user selects say the envelope tray in PXL, now I send a PCL job with a reset their driver will still select envelope unless an explicit PCL command to select a tray is sent. I am betting the HP printer doesn't behave that way. Does that make sense. XL is okay because it selects a tray every job. | 16:30.12 |
ray_laptop | but I haven't tried it to see what's going on with their PXL | 16:30.15 |
| henrys: Oh, and the job wants the tray to be sticky, but our devices don't know about job boundaries | 16:31.54 |
henrys | so I'm going to make a code change for that. It will set a default each time, but I don't think that should interfere with your discussion we don't even know if there driver produces PCL. | 16:32.49 |
ray_laptop | so why not have PCL always set the PaperSource to 1 for every job | 16:32.52 |
| it makes sense to me that a 'reset' would set back to printer default | 16:34.03 |
henrys | right agreed | 16:34.17 |
| I'll fix it. | 16:34.21 |
ray_laptop | henrys: OK. And I will add in / fix the handlers in gsdparam.c (unless you want to do it). Then if/when you change to names to more meaningful you can just change it there too. OK? | 16:35.58 |
| unless you want to just do it all at once | 16:36.20 |
henrys | I wouldn't make any change to parameter parsing in the library, we use unrecognized parameters all the time in PCL and XL without proble. | 16:36.56 |
| PCL and XL would never look at the return value anyway. | 16:37.56 |
| so what is the point? | 16:38.06 |
Jared_WebPT | hello, got a question for an admin if someone is available? | 16:43.06 |
ray_laptop | henrys: it bothers me to have errors thrown for gs_error_undefined, and then ignore them. Also the 'case 1:' of the switch(ecode) in pxsessio.c will get skipped (always) | 16:43.27 |
| henrys: I haven't stepped through it. I'll let you know if I find out otherwise | 16:44.26 |
henrys | maybe make an enhancement bug report? But all the customer has to do now is doing something appropriate with the current variables right? | 16:47.15 |
ray_laptop | henrys: correct. I will first finish the reply to them so they'll have it when they get in later | 16:47.50 |
Jared_WebPT | My question is in reference to this bug: http://bugs.ghostscript.com/show_bug.cgi?id=687297 | 16:49.02 |
henrys | PCL on an HP printer will not error out with an out of bounds tray selection, I don't know if that makes it bother you less. I do see your point ray_laptop | 16:49.17 |
| Jared_WebPT: what's the question? | 16:49.53 |
Jared_WebPT | hi henrys | 16:50.04 |
| if you look at that post I just have, we have a weird issue here using Ghostscript where we are getting extra spaces added to PDFs created | 16:50.30 |
| for example, http://screencast.com/t/OkO6GPKJS | 16:51.04 |
henrys | Jared_WebPT: if it doesn't match adobe create a bug with the test file and a command line. | 16:51.55 |
| Jared_WebPT: if it is a regression say so in the report. Thanks | 16:52.26 |
Jared_WebPT | alright, would it be advantageous for us to upgrade to 9.07, we are currently using 9.06 | 16:53.13 |
henrys | we always encourage folks to keep up to date. We release 2x a year - Feb and Aug. | 16:54.08 |
ray_laptop | Jared_WebPT: so 9.08 release candidate is already set. | 16:55.16 |
Jared_WebPT | Ok, I noticed in that bug report I sent that they mentioned that there was a big font update (as of recent) so wasn't sure if some of these font issues would be fixed with 9.07 or not? | 16:55.28 |
| Alright, might benefit us to wait for 9.08 to get officially released before we update | 16:55.54 |
ray_laptop | Jared_WebPT: impossible to way without the bug report info | 16:56.02 |
| s/way/say/ | 16:56.15 |
Jared_WebPT | Ok, I understand. I will do as henrys suggested and create a bug report for the test file | 16:56.59 |
| Thanks for your help | 16:58.34 |
ray_laptop | Jared_WebPT: some problems are caused by input that doesn't embed the font file, so gs has to substitute, and the metrics on the substitute don't match | 16:59.10 |
| Jared_WebPT: but we'll (probably kens since it is pdfwrite) will have a look | 16:59.37 |
Jared_WebPT | Great. I will work on generating that now and submit that over ASAP | 17:00.08 |
| ray_laptop: do you have any basic instructions on creating the test file you need for the bug submit? | 17:04.36 |
ray_laptop | Jared_WebPT: we just need the input file you are sending to gs and the command line | 17:06.19 |
Jared_WebPT | Alright, I can do that - thanks | 17:07.09 |
ray_laptop | Jared_WebPT: If you want to check the 9.08 release candidate (or close to it), it will save kens some time. The snapshot is at (tar.gz) is at http://git.ghostscript.com/?p=ghostpdl.git;a=summary | 17:10.20 |
| henrys: I see why the undefined parameters get ignored silently. the gs_c_param_list uses c_param_read_commit which doesn't really check for left over parameters | 17:15.08 |
| and even if the param_commit returned gs_error_undefined, the px_put1 is called with the third param == 0, so undefined errors get set to 0. It tries REALLY hard to avoid detecting errors :-) | 17:18.41 |
citizen5 | hi everyone | 18:15.16 |
| is it possible to generate a .jar from from the mupdf source code? | 18:15.34 |
| I was able to generate an .apk file but this is not what I need | 18:15.53 |
| what I need is a library to view pdf's inside my application | 18:16.06 |
| any sugestion? | 18:16.17 |
ray_laptop | henrys: I sent the response off to the customer (on tray selection). Let me know if I got anything wrong, please. | 18:46.30 |
marcosw | chrisl: poing | 18:52.24 |
chrisl | marcosw: piong | 18:53.06 |
marcosw | chrisl: in the email re. ufst you said "They will need the UFST update from us". Is that just the normal svn version or something else? | 18:53.55 |
chrisl | marcosw: just what's in svn. Actually, they should only need the fapiufst.mak file, not the whole archive. | 18:54.46 |
marcosw | marcosw: thx. | 18:54.56 |
chrisl | marcosw: do you want me to reply to Nortbert (I was going to check with henrys first)? | 18:55.24 |
marcosw | chrisl: that would be great, that way any follow-up questions will be your problem :-) | 18:55.51 |
chrisl | marcosw: they'll end up my problem anyway, so...... | 18:56.12 |
henrys | marcosw:so do you want to contact phil about my comment on the p1 bug or shall I? | 18:56.18 |
marcosw | henrys: I'll do it. | 18:56.44 |
chrisl | henrys: are you okay with me dealing with Norbert on that? | 18:56.49 |
henrys | chrisl: yes | 18:57.05 |
chrisl | Cool, thank | 18:57.12 |
| or even "thanks" | 18:57.22 |
dogisfat | Why would text be provided as paths to a driver at 524 dpi whereas at 523 dpi the text is rendered to pixles | 19:07.14 |
chrisl | dogisfat: at a certain point a glyph gets too big to reasonably generate an interim bitmap, so we switch to rendering it as a path. | 19:11.51 |
dogisfat | Is there a way to force this behavior? | 19:12.09 |
| So all text comes out as a path? | 19:12.22 |
chrisl | dogisfat: No, there isn't | 19:12.37 |
dogisfat | Bummer, thanks! | 19:12.50 |
chrisl | dogisfat: the problem is, once we render it as a path, we lose all the hinting and clever, glyph specific drop out detection and things like that. Those don't matter at very large sizes, or very high resolution, but can be very important at low res, small point size. | 19:14.15 |
dogisfat | I figured. Well I guess I must figure out some way of intercepting the call to the rasterizing function. | 19:15.34 |
| Thanks again! | 19:15.40 |
chrisl | dogisfat: that's probably not going to be straightforward, as the glyph path generation and rendering is done by freetype | 19:18.38 |
dogisfat | It looks like I can build my own *_copy_mono function and grab the pixels there. | 19:19.25 |
chrisl | dogisfat: Oh, I see, I thought you meant the actual glyph rendering | 19:19.52 |
dogisfat | Really I wanted the curves, but I think that might be too much work for right now so I guess that copy_mono will have to do. | 19:20.34 |
chrisl | dogisfat: otoh, if you don't mind tweaking source a bit, there may be a simple way for you to always get paths - it's just it's not something we'd want in our normal distribution | 19:21.16 |
dogisfat | Ideally I want GS to do as little rendering as possible for my application but I am pretty unacquainted with the appropriate way to do most things in GS so 90% of my implementations have been hacks :/ | 19:21.55 |
chrisl | dogisfat: sounds like a lot of stuff in GS - you'll fit right in ;-) | 19:22.26 |
dogisfat | Thanks | 19:22.43 |
chrisl | gotta head off now - 'nite folks....... | 19:26.36 |
ray_laptop | mvrhel is NOT going to like coming back to a P1 bug :-) | 21:00.09 |
| I'm continuing to dive into it, but with 17 .raw images involved in the rendering of a single "f" it isn't going to be a slam dunk :-( | 21:02.02 |
| Forward 1 day (to 2013/08/02)>>> | |