Can I use the output from ScriptShape/ScriptItemize in Uniscribe to get the char codes and pass the char codes to GetGlyphOutline to get the beziers?
Does Uniscribe have a call to get the outlines directly?
For anyone wondering the same.
The short answer: Yes. It works.
Uniscribe returns a WORD whereas the GetCharacterPlacement one gives out an LPCSTR though, so just look at that, should be trivial.
Nothing surprising though, this was just to confirm before I spend my time on it :)
Related
I've recently encountered these two variables in some Velocity code:
$!variable1
!$variable2
I was surprised by the similarity of these so I became suspicious about the correctness of the code and become interested in finding the difference between two.
Is it possible that velocity allows any order of these two symbols or do they have different purpose? Do you know the answer?
#Jr. Here is the guide I followed when doing VM R&D: http://velocity.apache.org/engine/1.7/user-guide.html
Velocity uses the !$ and $! annotations for different things. If you use !$ it will basically be the same as a normal "!" operator, but the $! is used as a basic check to see if the variable is blank and if so it prints it out as an empty string. If your variable is empty or null and you don't use the $! annotation it will print the actual variable name as a string.
I googled and stackoverflowed a lot before I finally found the answer at people.apache.org.
According to that:
It is very easy to confuse the quiet reference notation with the
boolean not-Operator. Using the not-Operator, you use !${foo}, while
the quiet reference notation is $!{foo}. And yes, you will end up
sometimes with !$!{foo}...
Easy after all, shame it didn't struck me immediately. Hope this helps someone.
Apologies if there's an answer out there already; but all I seem to be getting is a bunch of "I want to turn my 1 into a 1.0" chaff from my Google searches.
First things first. No, I'm not talking about a simple Convert::ToSingle() call. Rather, I need to convert the representation of the data to a System::Single.
So in other words, I'd like to take int myInt = 1065353216;, and the result should be something like 1.000. I know the pure c++ method would be something like float myFloat=*(float *)&myInt;;but I need the managed version.
Thanks in advance for your help.
If you're in C++/CLI, you can do it the same way as you do in C++: float myFloat=*(float*)&myInt;
In pure managed-land, there are built-in methods to do this for double & Int64 (DoubleToInt64Bits and Int64BitsToDouble, but not for single & Int32. However, if you look at the implementation of those methods (MS Reference Source), you'll see that they're doing the exact same thing as you have listed, so that's also the managed way to do it. The only difference is if you do it in C#, you have to tag the method as unsafe.
I'm trying to simplify my code by using #define statements. This is because it contains a lot of repetitive "chunks" of code that cannot be repeated using the obvious alternative, functions, because in these chunks, variables need to be declared like you'd do in a #define statement, e.g. #define dostuff(name) int name##Variable;.
Code
#define createBody(name,type,xpos,ypos,userData,width,height) b2BodyDef name##BodyDef;\
name##BodyDef.type = type==#"dynamic"?b2_dynamicBody:b2_staticBody;\
name##BodyDef.position.Set(xpos,ypos);\
name##BodyDef.userData = userData;\
name=world->CreateBody(&name##BodyDef);\
b2PolygonShape name##shape;\
name##shape.SetAsBox(width/ptm_ratio/2,height/ptm_ratio/2);
... and applying that in the following:
createBody(block, #"dynamic", winSize.width*5/6/ptm_ratio, winSize.height*1/6/ptm_ratio, ((__bridge void*)blockspr), blockspr.contentSize.width, blockspr.contentSize.height)
// error appears there: ^
Now my point is that everything's working great, no errors, except a single one that's freaking me out:
Expected unqualified-id
which points at the first bracket in ((__bridge ..., as indicated. (That argument gets passed via the userData argument to createBody.)
I know this code is nowhere near simple, but since everything else is working, I believe that an answer must exist.
This is my first question on SO, so if there's anything unclear or insufficient, please let me know!
I'm trying to simplify my code by using #define statements.
This sounds an alarm in my mind.
Break this down into functions. You said you can't. I say you can.
Notice that your macro here:
createBody(name,type,xpos,ypos,userData,width,height);
It has exactly the same syntax as a C function. So you've already created a function, you only declared it as a macro. There's no reason why you couldn't rewrite it as a function (C or Objective-C doesn't matter). You do not need to give each body its own name, instead you could store them in a dictionary (careful though because Box2D takes ownership of the bodies).
I'm doing something really dumb, and I don't see it.
I've got an object doc with a method:
-(float) currentOrient
{
return 50.5;
}
In another object, I call:
-(void) showPage
{
float rot2=0;
rot2 = [doc currentOrient] ;
NSLog(#"SP rotation is %.2f", rot2);
}
However, the output is :
SP rotation is 1112145920.000000
No, one question is "Why is the %2f not formatting correctly?" But the more confusing question is "Where is that number coming from?" Yes, I've walked through it with a debugger, the value of rot DOES change from the garbage it starts with. and that number DOES appear to be consistent.
Clearly something really dumb is going on...
It sounds like the showPage method doesn't know right return type for currentOrient, so it's interpreting the value returned as an int and casting that nonsensical int to a float. Are you getting any warnings? Are you sure you're importing the header for currentOrient correctly? Is the currentOrient method declared correctly?
I can answer the first question:
Why is the %2f not formatting correctly?
Because it ought to be %1.2f to round to two decimal places (which I believe is what you're trying to achieve?)
And guess at the second:
Do you have a property named rot in the code? Other than that... shrug... I don't know - I'm assuming you've simplified the example to post on SO, have you taken out other code that may be relevant? Based on the information you've provided everything should be ducky.
On a side note: When I hit bugs like this I go do something physical. Usually when I come back my head is clear and I find the problem immediately. You might want to give that a try too! :D
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar