On 2/10/19 3:36 PM, clipka wrote:
> Am 09.02.2019 um 19:41 schrieb William F Pokorny:
>> To start though find attached two scene files of a form I've been 
>> using to test solver/inside related changes using media. The results 
>> of Text.pov should quite closely match Text_I.pov results if 
>> everything is OK.
> 
> I'm wondering whether we're seeing an inside test problem caused by y 
> coordinates matching a horizontal line (or maybe even just an on-curve 
> control point).
> 
> The old TrueType implementation was apparently prone to such issues, and 
> added a tiny "random" rotation to try and avoid them. I had hoped the 
> prism primitive would be more robust in this respect, but maybe that is 
> not the case.

As an issue - might exist. I've occasionally had to tweak prism point 
positions to eliminate artifacts. The opposite of what you're saying - 
I've not had such trouble with text objects. Due luck perhaps.

I doubt it's what's happening here. Why does the single character text 
string work?

For the inside test as used by the object pattern, it's as if an 
internal structure/mechanism is corrupted in the freetype branch once 
there is more than one character in the text string.  Once a 
"text-union" is necessary internally(1) perhaps?

I'm light on text and prism test cases compared to some others. Wasn't 
looking much at the text shape at all previously for the solver work 
because it has/had its own. Had planned to move text to the common 
solvers in part at least, but no longer necessary.

Bill P.

(1) - I'll go now and create a <union>.pov and <union>_i.pov pair using 
spheres or something. Not something I have today for the text vs text_i 
form of inside test verification. And... looks like I never did a prism 
pair. Hmm, maybe this is a prism problem that's been sitting there all 
along. Slip, sliding away....

Post a reply to this message