POV-Ray : Newsgroups : povray.advanced-users : A bunch of feature requests! : Re: A bunch of feature requests! Server Time
24 Apr 2024 03:03:26 EDT (-0400)
  Re: A bunch of feature requests!  
From: SharkD
Date: 20 Jun 2010 05:14:48
Message: <4c1ddc08@news.povray.org>
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.

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


> 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.

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

What information?


>> 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.


>> Mixed-type arrays
>
> Already possible.

Really? You mean the following will work?

#local new_array = array[3]
{
	"foo", bar(), 20
}


>> 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?


>> 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.


>> Right-click menu when clicking on editor tab
>
> On Windows, I guess?

Guess why?


>> 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?


-- 
http://isometricland.com


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.