Should have known you'd answer the same answer :-) Regards,
Scott Rossi Creative Director Tactile Media, UX/UI Design On 2/20/16, 3:43 PM, "use-livecode on behalf of J. Landman Gay" <[email protected] on behalf of [email protected]> wrote: >Should have known you'd answer first. :-) > >-- >Jacqueline Landman Gay | [email protected] >HyperActive Software | http://www.hyperactivesw.com > > > >On February 20, 2016 5:38:30 PM Scott Rossi <[email protected]> >wrote: > >> A good suggestion. You can achieve the same effect in LC without >> duplicate objects by adding a dropshadow effect to the text that has a >> size of 0, an angle of 45, and a distance of 2 or 3 (maybe higher, >> depending on the size of the text). >> >> Regards, >> >> Scott Rossi >> Creative Director >> Tactile Media, UX/UI Design >> >> >> >> >> On 2/20/16, 3:25 PM, "use-livecode on behalf of Tim Selander" >> <[email protected] on behalf of >> [email protected]> wrote: >> >>>Would it be better to do what we do in the video world? Put a >>>black edge on the "Realm of Knowledge" text. Any video editor can >>>do that, but you can fake a reasonable fascimile put using the >>>text twice, in layers. Top layer is the text in white. Bottom >>>layer in black. Shift the black text down and to the right a >>>couple of pixels. Puts a black edge on the bottom-right of the >>>white text. Improves readability. You can even blur the black >>>text a bit to make the effect a bit more subtle. >>> >>>Tim Selander >>>Tokyo, Japan >>> >>>On 2/20/16, 11:32, Sannyasin Brahmanathaswami wrote: >>>> >>>> HH You are right of course. one pixel was an expediency and certainly >>>>does not cover all cases. In fact it is a rather weak algorithm as you >>>>can see here: >>>> >>>> https://www.evernote.com/l/ABHZ6MzemNNJY6SXFJ3HTMb7afCnCElhYfE >>>> >>>> the text field crosses a blown out highlight (white hair) over to a >>>>dark background. >>>> >>>> in a case like this a midtone is usually all one can decide on. in >>>>this >>>>case >>>> >>>> 220,220,220 >>>> >>>> at >>>> >>>> 200,200,200 >>>> >>>> we start to hit the same level as the background. in this particular >>>>photo: >>>> >>>> https://www.evernote.com/l/ABFY-T8OCqNDYK4QOed3qr0G6GfqZUXWjEo >>>> >>>> For this particular context I'm actually happy with the "homeKey" >>>>field >>>>being subdued. >>>> >>>> but in other cases one wants a stronger presence >>>> >>>> https://www.evernote.com/l/ABE267idXlBHrY4Xs4ND27ziH1UjmGtU-eY >>>> >>>> Musings: >>>> >>>> A random algorithm also does not help us out either. >>>> >>>> In this "FlipBoard" model/copy-cat (which is what I'm aiming for in >>>>V1) >>>>image will be dynamically replaced on every return to the same card, >>>>not >>>>only per session, but even if the user just leaves the card and >>>>returns. >>>> >>>> "Only God will know for sure" what the luminance of the background >>>>will >>>>be under the field, because I'll be dynamically adding more and more >>>>images in the category over time... if we want to get really "manic" >>>>(your term ha!) we could write an analyzer to scan every pixel across >>>>the whole area underneath the field. but I worry this will take up so >>>>much CPU time, especially on Android that it will delay rendering the >>>>card. >>>> >>>> In print we often decide to put a background frame behind the type and >>>>change the opacity of the area to give some weight to the background, >>>>but on these small mobile spaces, that just adds more noise to the >>>>design >>>> >>>> I may settle finally on 200,200,200 for all and forget the attempt to >>>>analyze the background... though it was a very useful exercise and I >>>>have other context where I can and will use this new "skill" >>>> >>>> FlipBoard uses white and I guess they must have a staff of 50 people >>>>who curate every image and crop to make sure there is dark matter >>>>underneat their type... >>>> >>>> "not gonna happen here" >>>> >>>> BR >>>> >>>> On February 19, 2016 at 11:05:52 AM, [-hh] >>>>([email protected](mailto:[email protected])) wrote: >>>> >>>>> BR, >>>>> >>>>> you do estimate the luminance of a 120x175 = 21000 px region >>>>> on base of the evaluation of ONE single deterministic pixel? >>>>> >>>>> Accepted, of course, but then it may be better, from a >>>>> probabilistic point of view, not to take "the" pixel (40,40) >>>>> but *any* randomly chosen pixel of that region. >>>>> >>>>> You could do for that: >>>>> >>>>> set randomseed to (char -8 to -1 of the millisecs) >>>>> put 19+random(120) into pX ; put 19+random(175) into pY >>>> _______________________________________________ >>>> use-livecode mailing list >>>> [email protected] >>>> Please visit this url to subscribe, unsubscribe and manage your >>>>subscription preferences: >>>> http://lists.runrev.com/mailman/listinfo/use-livecode >>>> >>> >>>_______________________________________________ >>>use-livecode mailing list >>>[email protected] >>>Please visit this url to subscribe, unsubscribe and manage your >>>subscription preferences: >>>http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> >> _______________________________________________ >> use-livecode mailing list >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > >_______________________________________________ >use-livecode mailing list >[email protected] >Please visit this url to subscribe, unsubscribe and manage your >subscription preferences: >http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
