Hi Rolf - the block will not deform, that is correct. Can’t be done, the way blocks are made currently. The geometry in the block has to be the same, other than some simple transforms, as the underlying block definition. I do not have an explanation as to why the non-block gets larger, apparently, than the target surface - that did not happen here. My ‘scale’ setting was Uniform and 1…
-Pascal
Hi again,
That’s OK, if only the Help file states the fact. I actually planned my work with the emblems, based on reading the help file, which caused me to waste time by making blocks that kept failing, in part due to being just that, blocks.
That’s also OK. But what is not OK is that it happened here. 
The developers should take a look and, if it can easily be fixed they will fix it, but if not, then at least the Help file should state that there’s a bit of uncertainty there. That can potentially save a lot of wasted time and frustration.
In most cases (I believe) it’s probably quite easy to workaround even the current limitations, but only if they are well documented. Like adding a paragraph in the Help file about “known limitations” or “know Issues”. That’d be pragmatic, and most important, it would avoid frustrations. 
I regret the limitations with Blocks in general. In this particular case I had planned to enhance the letters with more detail (like screw pillars and a layer of rubber on the back side), but I can live with it since these letters occur only once in the model anyway.
// Rolf
DEBUG TIME
Hi again @pascal,
I’ve got some bad news. In an attempt to justify myself, or trying to do away with me suspecting myself being “lesser talented”, I made a new attempt. I tried replacing my cage edited L with a new exploded instance of L, on top of an expanded target surface, and the result only gets worse…
Fig. 1 : As I extend the surface, so the deformation (Scaling) is also extended!
Why I tried again was because I noticed that your success was based on your own target surface, not mine. But will you succeed using the surface which I’m struggling with? (attached).
This surface is point-edited, can that be a cause for why my attempts fail every time?
Although I cannot with absolute certainty exclude the possibility that I’m either clumsy or stupid, or both, I think that by now there are indications that there’s something basically flawed with the command. It has now proved to be unpredictable in almost every way thinkable. Alternatively there’s something wrong with my file / objects.
In any case, please try debug the attached file, it’s the original objects that I’ve used and failed with (I leave my result in place, just delete it and retry).
HOW I MANAGED TO FAIL (…)
In order to reproduce my exact sequence of actions,
Between (upper left and lower right), flip is not needed any longer (after I flipped the surface normal),Between (upper left and lower right) and the dialog settings as in the image above.Scaling, but the object still scales as in the image above. I also tried #2 checking Prompt, and explicitly entered the value “1” on the command line, but still the same result as in the picture.Remark: I’m using Rh5 (last release) on Win10.
// Rolf
The model captured in Fig. 1 :
PV Front 011 - tst.3dm (2.5 MB)
Hi Rolf
I’d like to say a couple of things … as far as I understand, of course.
OOS1.3dm (333.7 KB)
On your file the surface gets distorted because the target surface’s parameterisation is not proportional to real space.
There are spans longer than others. You can see that looking at the surface: the distance between the isocurves varies considerably.
The usual fix to this kind of things is Rebuild
I tried rebuilding the surface and it seems to work (at least here … )
I think Rhino, in order to orient the surface, relies on the surface space, so to speak, and that depends on its parameterisation.
About blocks not being distorted: as Pascal said, blocks are only links to real geometry, that can be transformed by a transform matrix, i.e. moved, scaled, rotated.
A surface built by OrientOnSrf (no Rigid) as you can see, is a completely new object. It cannot be defined simply transforming the original block geometry.
Blocks are useful because they are small: they’re only links.
When an object changes its shape, it cannot be a block instance of a different shape.
I hope my words are clear enough and somehow useful, despite my poor English … and obviously despite my very limited understanding of geometry and Rhino’s insides
Regards
[quote=“emilio, post:24, topic:36193”]
On your file the surface gets distorted … There are spans longer than others.[/quote]
AS DESIGNED
@emilio, thank you for your reply.
Yes, the spans between the isocurves was intentionally manipulated to simplify the manipulation of the surface “topology”, which was manually point edited to follow the “notch” in the middle of the original surface.
If that explains the distortions of the resulting oriented object, it helps a lot. Thank you for that. I can correct that problem.
BUGFIX
I guess McNeel have reasons to take a different approach when calculating the orientation result, perhaps making a temporary copy of the surface and make the spans evenly spaced on the copy before producing the end result, etc.
BLOCKS - DEAL WITH THEM!
Regarding the limitations of Blocks I have no problem with that. But Rhino actually can do at least two och three meaningful things when someone tries to align a Block object, for example:
And, Rhino should at least identify the span-problem which you described and display a warning about the potential distortions. I mean, what if the span distances are only slightly disproportional? The user may not visibly notice the distortion of the object which will be the result of that, and so the problem may pop up only much later, perhaps when it’s too late.
KNOWING
Not knowing about a limitation is the most serious problem. Knowing about the limitation OTOH gives the user a chance to avoid it or to workaround it.
Again, thank you very much. The span problem was very important information and it helps a lot and it also helps me avoid similar problems in other places.
// Rolf