| | <<<Back 1 day (to 2015/09/01) | 20150902 |
| mvrhel_laptop | Robin_Watts: for the logs, I pushed a commit on my repos that had changes that removed the NULL check and also got rid of the magic 23 number | 04:19.13 |
| tor8 | Robin_Watts: 3 commits on tor/master for review if you got a few spare minutes | 08:40.06 |
| Robin_Watts | tor8: All look fine to me. | 08:58.21 |
| | 1 minor thing... | 08:58.24 |
| | No, ignore me. | 08:59.02 |
| tor8 | Robin_Watts: thanks. | 09:56.34 |
| Robin_Watts | kens, chrisl: a PDF sanity check please. | 15:16.33 |
| kens | Umm ok.... | 15:16.53 |
| rayjj | wow!! That "Technical Discussion" email that mentioned the "g" word sure elicited a lot of traffic | 15:16.54 |
| Robin_Watts | Suppose I have a content stream in pdf that sets an ExtGState with an SMask entry. | 15:17.09 |
| kens | Hmm oddly I've been looking at this sort of thng recently | 15:17.24 |
| Robin_Watts | Then it does 'q'. Then it has some content A. | 15:17.38 |
| rayjj | kens: not surprising seeing recent pdfwrite changes :-) | 15:17.45 |
| Robin_Watts | Then I have an ExtGState which sets SMask to /None. and some Content B. | 15:18.03 |
| kens | rayjj its just amusing that Robin is hitting hte same area | 15:18.10 |
| Robin_Watts | Then Q. and then Content C. | 15:18.23 |
| | Does B get the softmask applied? Does C? | 15:18.44 |
| kens | be72694a3cac0aa72c0843334e7f1afdabbddc7abe72694a3cac0aa72c0843334e7f1afdabbddc7abe72694a3cac0aa72c0843334e7f1afdabbddc7C does, B doesn't | 15:18.51 |
| | Grr | 15:18.55 |
| | B does not, C does | 15:19.04 |
| | That is the behaviour I've observed with both Acrobat and GS recently | 15:19.26 |
| Robin_Watts | Ok, that at least seems sane. | 15:19.37 |
| kens | Its what I would expect, given that the SMask is part of the (Ext)Gstate | 15:20.03 |
| Robin_Watts | If instead of setting the SMask to None, I'd set it to some other smask, then B would be masked JUST by the new SMask, not the old SMask ? | 15:20.37 |
| kens | I don't remember if the spec makes it totally clear whether the Ext GState obeys gsave and restore | 15:20.39 |
| rayjj | Robin_Watts: is the initial 'gs' that sets the SMask in the content stream, or as part of a Form dict ? | 15:20.47 |
| kens | Robin_Watts : yes, that is wha I've seen | 15:20.53 |
| Robin_Watts | rayjj: For the purposes of this discussion in the content stream. | 15:21.09 |
| rayjj | Robin_Watts: it is supposed to obey q Q | 15:21.14 |
| kens | They do not 'merge' | 15:21.16 |
| Robin_Watts | but why do you think it would matter? | 15:21.24 |
| rayjj | and SMask as part of a Form gets applied to the entire Form, and the Form contents is rendered with SMask /None (initially) | 15:22.21 |
| | then as the content is processed, other SMasks may be used | 15:22.48 |
| Robin_Watts | rayjj: So for form contents SMasks *do* compose on top of one another? | 15:23.23 |
| kens | Not exactly on top of one another | 15:23.36 |
| | THe Form SMask is applied after the Form contents | 15:23.51 |
| Robin_Watts | But the net effect is that you see the 'intersection' of the two softmasks in that case. | 15:24.12 |
| kens | Essentially yes, but the order of processing might be important | 15:24.27 |
| | I haven't thought about it in enough depth to be certain | 15:24.41 |
| rayjj | Robin_Watts: the rendered Form (from processing the Contents) will be RGBA, (or whatever colorspace+alpha) | 15:24.55 |
| Robin_Watts | I suspect the order of processing doesn't matter in cases where we're ignoring knockout/isolated/blendmodes. | 15:25.11 |
| | like I am. | 15:25.14 |
| rayjj | Robin_Watts: but yes, if a Form has an SMask, then inside the form's stream contents another SMask is used, that will affect objects drawn (e.g., reducing their alpha according to the mask), so when the blending is done as the group is popped, the Form SMask may further reduce the alpha according to that mask | 15:27.57 |
| Robin_Watts | rayjj: Right. | 15:28.27 |
| rayjj | Robin_Watts: and BM (that complicates things) | 15:28.28 |
| | but for simple case it's commutative (AFAIK) | 15:29.23 |
| | kens: do subclassing devices ever get removed ? How ? (feel free to point me to the correct FM) | 15:30.57 |
| kens | They can do, it depends on the device | 15:31.14 |
| | THe one for the color_procs does if I remember correctly | 15:32.08 |
| rayjj | so gx_device_unsubclass is the method ? | 15:32.37 |
| kens | Err, probably, its been a while.... | 15:32.48 |
| rayjj | which is the colorprocs subclass device ? | 15:33.46 |
| rayjj | only saw the pagehandler and objecthandler | 15:34.05 |
| kens | Again I don't recall offhand, its the one set up by PCL to do monochrome mode | 15:34.06 |
| rayjj | ah, pcl/pcl/pcpalet.c | 15:34.44 |
| | thanks, I'll have a look at it. | 15:34.54 |
| kens | Its in thre somewhere | 15:34.59 |
| mvrhel_laptop | Morning Robin_Watts. Did you get a chance to have a second look at the commit on my repos? | 15:35.07 |
| Robin_Watts | sorry, no. let me look now. | 15:35.20 |
| mvrhel_laptop | thanks | 15:35.23 |
| rayjj | uses find . -type f -exec grep unsubclass "{}" ; | 15:35.41 |
| kens | rayjj pcl_update_mono() pushes and pops the PCL_Mono_Palette device | 15:35.54 |
| Robin_Watts | mvrhel_laptop: using sizeof(constant string) rather than strlen(string) saves a runtime operation and gives the same results. | 15:36.43 |
| mvrhel_laptop | ah ok | 15:36.51 |
| | will change that | 15:36.57 |
| Robin_Watts | but that's really minor. It looks fine as is. | 15:37.15 |
| mvrhel_laptop | ok. will fix that and then commit. thanks Robin_Watts | 15:38.41 |
| Robin_Watts | np. | 15:38.47 |
| mvrhel_laptop | hmm misspellings in comments too.. | 15:41.14 |
| kens | rayjj why do you want to look at the device subclassing stuff ? Is there a problem ? | 15:46.51 |
| rayjj | kens: no, I think it will be more efficient to use a "normal" spotcmyk subclass device instead of the pdf14 compositor. For one thing, if all we are doing is overprint simulation, we don't need an alpha channel | 15:50.51 |
| kens | Umm, possibly, if I understood what you are doing :-) | 15:51.25 |
| | It wil be interesting to have another use case implemented though | 15:51.41 |
| rayjj | kens: the concept is to have the spotcmyk subclass device render the page, and at 'print_page' time (similar to pop_device time with pdf14) to send to the converted bits to the child device | 15:52.17 |
| kens | OK I thnk that should be possible, its broadly similar to the transparency flattening for pdfwrite. I did consider trying to make that into a subclassing device but there was a problem, I can't remember now what it was | 15:53.20 |
| mvrhel_laptop | Robin_Watts: so where is the best place to look in the mupdf code to see how to get started with forms support? I suppose mupdf.c in platform/android/jni? There is not really and documentation about this is there? | 15:54.07 |
| rayjj | kens: but the next page may not need/want the overprint sim, so I wanted to revert to the child device, which is what unsubclass does, IIUC | 15:54.14 |
| mvrhel_laptop | or tor8 ^^ | 15:54.42 |
| Robin_Watts | mvrhel_laptop: paulgardiner is the guy who understands forms more than me. | 15:54.43 |
| kens | Yes, it simply removes the device from the chain, restoring things as they were before. Or at least, that's what is *supposed* to happen | 15:54.44 |
| Robin_Watts | but yes, mupdf.c is the place to look, I think. | 15:55.01 |
| mvrhel_laptop | ah ok. paulgardiner ^^ | 15:55.02 |
| | ok | 15:55.08 |
| rayjj | the pdf14 device never gets unhooked -- it just goes into a forwarding device mode | 15:55.14 |
| kens | Yes I remember that | 15:55.27 |
| | Its much simpler to operate that way of course | 15:55.40 |
| Robin_Watts | mvrhel_laptop: We need to update the JNI in mupdf.c to cope with the extra params you just added too. | 15:55.47 |
| mvrhel_laptop | oh yes | 15:55.58 |
| paulgardiner | mupdf.c does sound like a good start | 15:56.14 |
| mvrhel_laptop | thanks paulgardiner. I will poke around in there a bit | 15:56.32 |
| kens | mvrhel_laptop : your latest commit failed to compile on the cluster | 15:56.58 |
| mvrhel_laptop | really | 15:57.10 |
| paulgardiner | IIRC, you send events at point on a page and that causes a field to be focussed. You then work on the focussed field. | 15:57.21 |
| kens | MuPDF came back compilefail on every node | 15:57.21 |
| rayjj | kens: I have to do a bit more thinking about handling any put_params afer the device is the 'spotcmyk_sim' device | 15:57.41 |
| mvrhel_laptop | :( | 15:57.54 |
| Robin_Watts | mvrhel_laptop: Yeah, looks like you need to update mudraw too to pass extra empty strings. | 15:57.54 |
| mvrhel_laptop | oh | 15:58.07 |
| kens | rayjj putparams can be handled or passed on or both. I thnk some of the extant devices do those things | 15:58.12 |
| mvrhel_laptop | sorry about that let me fix | 15:58.17 |
| rayjj | kens: yeah, I was thinking it might need to do both. The nice thing is I am only worried about PDF (ignoring PS) and we have control over the parameter setting order, and it all is in pdf_main | 15:59.58 |
| kens | Should be OK | 16:00.11 |
| rayjj | kens: the usage of putdeviceparamsonly in pdf_cslayer is only for the benefit of pdfwrite, correct ? | 16:02.09 |
| | kens: the graphics lib doesn't do anything with the layers | 16:02.27 |
| kens | Hmm, I'm not sure, where is that ? | 16:02.29 |
| rayjj | Resource/Init/pdf_cslayer.ps -- search for putdeviceparamsonly | 16:02.54 |
| mvrhel_laptop | ok. easy enough to fix. Shame on me for just building libmupdf in gsview and assuming all was well. Robin_Watts, should I amend my last commit here and then push, or make a new commit and push, or something else | 16:03.15 |
| Robin_Watts | new commit and push. | 16:03.26 |
| mvrhel_laptop | ok | 16:03.29 |
| kens | rayjj I can't thnk anything except pdfwrite can use that | 16:03.36 |
| rayjj | kens: it's for BMC/BDC/EMC | 16:03.43 |
| kens | But I've never seen it used either | 16:03.44 |
| | rayjj if I were writing it, I'd do the pdfmarks directly | 16:03.56 |
| | In any event, nothing except pdfwrite can handle those | 16:04.46 |
| | the putdeviceparms that is | 16:04.57 |
| | I thnk the name of the file is misleading, as is the comment at the top, ths isn't really illustrator layers.... | 16:05.28 |
| rayjj | kens: I don't know if it's really used | 16:05.47 |
| kens | I'm not convined, I'm just haivn a quick grep | 16:06.14 |
| | BMC and EMC are hanbdled (more sensibly) in pdf_main.ps | 16:06.33 |
| rayjj | kens: it appears to be an option "cslayer.dev" -- probably deprecated | 16:07.23 |
| kens | Only one of the pdf_cslayer.ps and pdf_main.ps can be active, since they are both deinfed in pdfopdict. | 16:07.24 |
| | My guess is that we could drop pdf_cslyer.ps altogether | 16:07.40 |
| mvrhel_laptop | ok that is fixed. thanks for alerting me kens | 16:07.56 |
| kens | PCL_Mono_PaletteI very much doubt the one in pdf_cslayer.ps actually still works | 16:08.03 |
| | mvrhel_laptop : NP | 16:08.10 |
| chrisl | kens: Let's consider dropping it *after* the release... | 16:08.24 |
| kens | chrisl I wasn't suggesting we hsould do it. Certainly not at the moment | 16:08.45 |
| | I'd want to look at it *much* more carefully before deciding that. | 16:08.56 |
| | However, it does look as though pdf_cslayer is never actually executed. | 16:09.35 |
| rayjj | kens: I agree that it should be removed. AFAICT, it was developed in 2007, and other than changing the copyright hasn't been touched since | 16:09.37 |
| chrisl | I actually think it's supposed to enable devices to handle marked content, but I doubt there's a device that handles it | 16:09.55 |
| kens | rayjj I'm with Chrisl, lets do it after the release, just in case | 16:09.57 |
| rayjj | kens: no, it won't go into the init list unless cslayer.dev is on the FEATURE_DEVS list | 16:10.11 |
| kens | chrisl pdfwrite will, but the code already exists in pdf_main.ps, so it doesnn't need an extra file for it | 16:10.27 |
| chrisl | kens: yes, but pdfmark will only exist for vector devices - I think pdf_cslayer.ps is supposed to do it for "normal" devices | 16:11.18 |
| rayjj | I'm for removing it now (so we don't forget it for another 8 years) | 16:11.26 |
| mvrhel_laptop | ok. the simple windows mupdf app has some basic forms stuff too that shows what to do | 16:11.31 |
| kens | I'll open a bug for me to remove it after the release. Chrisl, does the pdfwrite stuff depend on pdfmark ? | 16:11.45 |
| mvrhel_laptop | I should be able to get something up and going pretty quickly in gsview I think | 16:11.54 |
| kens | sorry teh BMC/PCL_Mono_PaletteEMC stuff | 16:11.54 |
| chrisl | I thought the pdf_main.ps handling of BMC/BDC/EMC was done with pdfmarks - didn't look though | 16:13.02 |
| kens | TBHPCL_Mono_Palette right at the moment I can't see how it handles it at all | 16:13.18 |
| | It does process BMC and EMC regardless, I'm just not sure what it does with them | 16:13.39 |
| chrisl | It's really not important - rayjj is correct, pdf_cslayer.ps won't be executed in any default build..... | 16:14.26 |
| kens | PCL_Mono_PalettePCL_Mono_PaletteYeah that's what I thought | 16:14.35 |
| kens | curses this stupid paste thing | 16:14.44 |
| rayjj | kens: chrisl: the parameters it sets: /MarkType, /BMC_Tag and all of the rest (BDC_*) are not used in base/* psi/* devices/* or devices/vector/* | 16:15.29 |
| kens | I'd suggest that if it was ever wanted to implement in a device other than pdfwrite that device should identify itself as such. | 16:16.14 |
| rayjj | chrisl: I ripped out the compressed color remnants already (as part of a minor clean up effort to get rid of junk) | 16:16.21 |
| kens | THen it could work the same way and we could get rid of the file. | 16:16.30 |
| chrisl | rayjj: I did check that before (I cannot remember why), I had a feeling it was added specifically for some customer | 16:16.42 |
| kens | I won't touch it for now anyway | 16:16.44 |
| rayjj | well, it must have been a customer back in 2007 | 16:17.00 |
| chrisl | Hah! I like the original commit message: "DIFFERENCES: None, doesn't run."!! | 16:18.08 |
| kens | OK I'm heading off, goodnight all | 16:18.48 |
| rayjj | I don't think it has ever been used. It was created in commit dfbbece and never touched since, and no references to it in the git log since (except for the "change everything" commits). I suspect it was a work in progress that got committed and never used | 16:21.02 |
| | chrisl: with all the tree-shaking that has occurred, the likelihood that this would cause a problem is nil, and it would be trivial to re-instate it if so | 16:23.33 |
| chrisl | rayjj: quite true - I'll pull it out tomorrow | 16:23.52 |
| rayjj | chrisl: thanks. Some things as worth not opening a bug for (particularly since low priority bugs don't get much attention) | 16:24.50 |
| chrisl | Right, my turn to mosey off...... | 16:29.37 |
| mvrhel_laptop | rayjj: off to pick up the sax today. The guy fixed the goose neck, a few dents and replaced several pads. Should be good to go! | 16:48.36 |
| rayjj | mvrhel_laptop: I hope so! | 16:48.52 |
| mvrhel_laptop | Also picking up a alto sax there for my daughter who is starting band | 16:49.08 |
| | timing worked out perfect as they need their instruments tomorrow | 16:49.20 |
| | The shop was pretty cool. Its in the basement and this kid (like 20 something) and his dad work only on saxophones. Usually complete tear downs. | 16:50.12 |
| rayjj | mvrhel_laptop: oh, my! your son will have to learn how to transpose so they can do duets (it's really good to learn). My younger sister played alto and I played b-flat clarinet, so I had to learn | 16:50.29 |
| mvrhel_laptop | oh he is good at transposing now from his piano work. that sounds like a good idea | 16:51.02 |
| rayjj | then the next younger sister started flute, so I had to learn to transpose from C | 16:51.03 |
| | the thing is if you learn on b-flat clarinet, it's fairly easy transposing to e-flat since that corresponds to the register shift | 16:51.59 |
| mvrhel_laptop | ok | 16:52.07 |
| rayjj | G on the alto (three fingers of left hand down) is C on the clarinet in the base register, but with the 'octave key' (shifts to upper register) it is a G | 16:53.33 |
| | most people still call it an octave key on the clarinet even though it doesn't shift by an octave :-/ | 16:54.23 |
| | transposing orchestral music from C is a booger. It often has several sharps (violinists don't like being on open strings since they can't do vibrato) and on a b-flat instrument, you end up adding more sharps | 16:56.44 |
| | mvrhel_laptop: sounds like you've found a good shop. My great uncle had a instrument repair shop in his basement. He worked on EVERYHTING and even made violins and viola's from scratch. Not sure if he ever did a cello. He's who I got my clarinet from | 16:59.34 |
| mvrhel_laptop | nice | 16:59.52 |
| | this is the shop. their web site could use some work, but its def. a mom and pop shop (or son and pop in this case) | 17:01.19 |
| | http://www.worldwidesax.com/ | 17:01.21 |
| Robin_Watts | mvrhel_laptop, rayjj: Dunno if either of you guys would be interested in: http://www.fortenotation.com/en/lp/giveaway/ | 17:21.07 |
| mvrhel_laptop | cool. thanks Robin_Watts | 17:21.40 |
| Robin_Watts | Helen uses Sibelius 6, but that runs on her Acorn. One day it's going to die, and we're going to need to look at alternatives. | 17:21.47 |
| | PC versions of sibelius are stupid money :( | 17:23.26 |
| | actually, sibelius first is just 80 quid now, that's come down a lot. | 17:25.37 |
| mvrhel_laptop | kids used to play around with https://noteworthycomposer.com/ a lot before | 17:26.30 |
| rayjj | acorn. Sounds like that might be worth money some day :-) | 17:41.00 |
| | Robin_Watts: is hers like this one ? http://www.ebay.co.uk/itm/BBC-MODEL-B-32k-MICRO-COMPUTER-Disk-Drive-Microvitec-Monitor-Manuals-etc-/262031542618 | 17:43.34 |
| Robin_Watts | rayjj: No, though I am intimately familiar with such machines. | 17:44.04 |
| | More like: http://www.ebay.co.uk/itm/Acorn-Risc-PC-StrongARM-200Mhz-130Mb-Ram-40Gb-HDD-PC-Card-Keyboard-and-Mouse-/161806234867?hash=item25ac6734f3 | 17:44.45 |
| rayjj | I wonder if my ex-coworker from Mizzou still has his Altair that I helped him build (I did most of the soldering until he got the hang of it) | 17:45.25 |
| | Robin_Watts: wow! 200MHz _and_ a hard drive !!! | 17:46.16 |
| Robin_Watts | rayjj: Don't knock it. Boots almost instantly, doesn't get viruses and still feels faster than PCs today. | 17:46.56 |
| | The designer of the BBC Micro went on to design the ARM. | 17:47.19 |
| | The first job that Paul and I had together was working for her doing video codec work. | 17:47.49 |
| | mvrhel_laptop: mysteamgauge.com, might be useful to you. (Only gives total times, so you'd need to keep totals each week and do the maths) | 17:56.32 |
| mvrhel_laptop | Robin_Watts: oh thanks | 17:57.17 |
| rayjj | Robin_Watts: cool. And I wasn't knocking it. I also had early experience, mostly with unix or 'home brew' OS's that would boot really fast and never crashed (except for h/w failure). | 17:58.12 |
| mvrhel_laptop | cool I have the widgets all found and highlighted now in gsview | 19:00.35 |
| | now to do something useful when they are selected | 19:01.03 |
| | but that will have to wait until later today. off for lunch and then to the sax shop | 19:01.26 |
| | have to be careful how I say that | 19:01.35 |
| | I do see a performance improvement I can make in gsview | 19:02.03 |
| | I may do that before finishing up the forms | 19:02.18 |
| Robin_Watts | in what way? | 19:02.21 |
| mvrhel_laptop | Robin_Watts: oh yes let me ask you this | 19:02.32 |
| | so I have a cache for the display lists | 19:02.38 |
| | but I see now that I am loading a page when I first render the page, as well as do a search for the links, and now the widgets | 19:03.24 |
| | I probably should have a page cache | 19:03.29 |
| | so that I am not re loading the page each time | 19:03.37 |
| Robin_Watts | yeah, that would work. | 19:03.45 |
| mvrhel_laptop | right now it gets recreated | 19:03.51 |
| | ok. I will do that | 19:04.09 |
| Robin_Watts | but can't you use the display lists to search? | 19:04.22 |
| mvrhel_laptop | I dont' know, the calls to get widgets and links require a page | 19:05.07 |
| | eg. pdf_first_widget | 19:05.11 |
| | requires a context, a document and a page | 19:05.27 |
| Robin_Watts | right, yes. | 19:05.28 |
| | but if you run the widgets to a display list once... you don't need to enumerate them each time. | 19:06.11 |
| mvrhel_laptop | right. I only enum them one time at start up | 19:06.33 |
| | the details of the widgets are stored in the c# structures | 19:06.43 |
| | this is the same for text locations as well as links etc | 19:07.13 |
| | ok hungry. bbiaw | 19:08.42 |
| rayjj | strange, in gxdevice.h line 380: /* There is no forward_create_compositor (see Drivers.htm). */ but then line 397: dev_proc_create_compositor(gx_forward_create_compositor); | 20:03.23 |
| marcosw | I"m going to take the cluster down for a couple of hours, until 6:00 pm PDT, for testing. | 22:30.41 |
| | Forward 1 day (to 2015/09/03)>>> | |
IRC Logs