IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<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() function10:22.08 
  that can be called recursively to handle events10:22.14 
  for a modal dialog, you basically just want to trap mouse/keyboard events and direct to the dialog10:22.35 
  expose events and resize events still need to be handled for the main window10: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 apps10:23.13 
sebras tor7: how does the win32 viewer do that..?10:23.18 
tor7 all the focus has currently been on the android app10: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 up10: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 least10:24.25 
  ah, speaking of the devil :)10:24.31 
  hi paulgardiner10: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 minute10: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 110: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 text10: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 list11: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 correct11: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: ok11: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 stream12: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 etc12:21.45 
  pdf_text_widget_info12: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 loop12: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. :-P12: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 call12:58.59 
  I'm usure which is best.12:59.16 
  unsure12: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 overflowed13: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 desired13: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 pain13:32.04 
  a caret and key bindings for the common editing/motion commands isn't all that difficult13: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 fine13: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 up15:43.38 
  sorrry15: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_params15: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 look15: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 parser15: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 specifications15:51.37 
ray_laptop henrys: PS has a key "MediaPosition" in the setpagedevice dict15: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 disjoint15:55.28 
  HP sucks15:56.03 
  I would think the variables should be renamed XLMediaSource and PCLMediaSource15:57.07 
ray_laptop henrys: so they don't simply map to input tray number ? :-( 15:58.38 
henrys no see pxeMediaSource_t15:59.25 
  in gdevpxen.h15:59.38 
ray_laptop henrys: where are the definitions for 1-6 for PCL ?16:02.19 
henrys in the manual16:02.34 
  # = 0 - Print the current page16: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. feeder116: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 code16: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 each16: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 error16: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 ecode16: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 PXL16:30.15 
  henrys: Oh, and the job wants the tray to be sticky, but our devices don't know about job boundaries16: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 job16:32.52 
  it makes sense to me that a 'reset' would set back to printer default16:34.03 
henrys right agreed16: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 once16: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 otherwise16: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 later16:47.50 
Jared_WebPT My question is in reference to this bug: http://bugs.ghostscript.com/show_bug.cgi?id=68729716: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 henrys16: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 created16:50.30 
  for example, http://screencast.com/t/OkO6GPKJS16: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. Thanks16:52.26 
Jared_WebPT alright, would it be advantageous for us to upgrade to 9.07, we are currently using 9.0616: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 update16:55.54 
ray_laptop Jared_WebPT: impossible to way without the bug report info16: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 file16:56.59 
  Thanks for your help16: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 match16:59.10 
  Jared_WebPT: but we'll (probably kens since it is pdfwrite) will have a look16:59.37 
Jared_WebPT Great. I will work on generating that now and submit that over ASAP17: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 - thanks17: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=summary17: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 parameters17: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 everyone18: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 need18:15.53 
  what I need is a library to view pdf's inside my application18: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: poing18:52.24 
chrisl marcosw: piong18: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: yes18:57.05 
chrisl Cool, thank18: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 pixles19: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't19: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 freetype19: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 rendering19: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 distribution19: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 Thanks19: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)>>> 
ghostscript.com
Search: