On 20.06.10 11:14, SharkD wrote:
> On 6/20/2010 4:54 AM, Thorsten Froehlich wrote:
>> You cannot set them because there is nothing to set in a finished font.
>> You can only set font metrics in a font editor. If you want to apply
>> effects to text objects, you can transform individual characters with a
>> macro. Getting the essential font metrics is already possible with
>> clever use of the min_extent and max_extent functions.
>
> "Clever use" means tedious work that gets repeated by users over and
> over and over again. If it's so good then the devs can be "clever"
> enough to add the feature.

Well, I would be all for someone contributing a set of macros for the 
POV-Ray 3.7 include file collection to avoid any repetition.

> As for setting/overriding metrics, even an HTML coder can override
> things like x height using things like font-size-adjust and font-stretch.

Yes, it is called "scale" in POV-Ray ;-)

>> Already there, supplied by the system in Windows help docs (given you
>> report for Windows). You can also use the PDF docs, which have this, as
>> do the Mac help docs.
>
> I was talking about sub-topics within extremely long pages. No, the
> Windows help docs can't help you there as they don't track what topic
> you're reading at any given moment.

Hmm, I am not sure how a table of contents at the top of such a page (as you 
suggested) would help you keep track of where you are on that page. I know 
that PDF table of content views get updated as you move through the 
document, but I am not aware of any HTML feature (sans JavaScript) that 
could do this interactively.

>>> More library paths, wildcards
>>
>> There was information missing in your feature request. Please add it
>> there.
>
> What information?

Please refer to the bug report. What is needed is the version of POV-ray you 
are using, and the error message displayed. The background here is (as 
explained in the comment for that feature request) that the code does not 
have a limit of 20 paths internally, so the problem must be coming from some 
platform specific code that has not been updated. - It is correct that there 
was such a limit in 3.6, but you reported the problem against 3.7 beta where 
it should be exist. That is also my I changed the "feature request" to 
"possible bug".

>>> Explicit #RETURN statement inside macros
>>
>> You are misunderstanding that macros are not functions. There is no such
>> thing as a return from a macro.
>
> OK, I see now that a return statement wouldn't work in a macro. A macro
> can return an arbitrary block of code that could be completely
> unstructured.

Yes.

>>> Mixed-type arrays
>>
>> Already possible.
>
> Really? You mean the following will work?
>
> #local new_array = array[3]
> {
> "foo", bar(), 20
> }

No, this syntax will not work. I actually just noticed that i added the 
explanation to report 127 (rather than 128). Among other things, you can do 
things like this:

#declare foo = array[2];
#declare foo[0] = array[2];
#declare foo[1] = array[7];
#declare foo[0][0] = 2;
#declare foo[1][6] = sphere{1,1}

Reformatting this syntax to something close to what you are looking for is 
possible. You might want to open another thread here for such a discussion, 
or discuss it here.

>>> Ability to change the order of editor tabs by dragging them
>>
>> This is Windows only, I suppose.
>
> Why is that? Are Linux users too primitive to benefit from this feature?

Yes, they are! They have no editor supplied by POV-Ray!

>>> Native support for mesh-based surface approximations
>>
>> You can already do this with a macro. Native support would have no
>> benefit - the probable assumption that a high quality mesh would be
>> faster to generate and then render compared to a native object (i.e. an
>> isosurface) is incorrect.
>
> Pray tell me then why people have taken the time to write these complex
> macros if there is no benefit? Just this week I've been told at least a
> half a dozen times that my scenes would render faster if I replaced my
> objects with meshes.

By whom, and where?

>>> atand function
>>
>> This is the degree based version of atan. Use the radians and degrees
>> functions.
>
> There are already sind, tand, cosd, tan2d, etc. Why not also tand? Too
> conspicuous for you?

Well, I see now. You really need to write more than "There already exist 
atan, atan2 and atan2d functions, why not atand?" as a feature request. Both 
"atan" and "atan2" are built in functions. "atand" is not. Now that you 
mentioned the other ones, I had a chance to notice that these functions are 
indeed defined - in "math.inc". That would have been the minimum additional 
necessary information needed to figure out what you were up to. Now I know, 
and indeed have simply added it. So in the next beta you should find a
#declare atand = function (x) {degrees(atan(x))}
in "math.inc".

	Thorsten

Post a reply to this message