EDIT: For those that say: do not do this, I most respectfully point out that 1. this is something that is allowed by javascript and, more importantly, 2. this is something that I need to do for pedagogical reasons.
I would like to "validate" my javascript code with jslint (or jshint ... or something equivalent) but, unfortunately, it fails due to the presence of non-ascii characters in identifiers. Does someone know of a validator like jslint which accepts non-ascii characters in identifiers?
I know of a partial workaround, which is to use something like
this["andré"]
instead of
this.andré
but do not know of an equivalent workaround for something like
var andré = ...
Version 1.0.0 of JSHint will add support for unicode characters in identifiers. Currently this is available as a release candidate which you can download on GitHub. From the JSHint blog:
This version adds support for Unicode identifiers!
var π = 3.1415;
Related
I need help importing a library to Xamarin. I included the library and inserted it into a new folder named BarcodeScanner, and the name of the library is libBarcodeScanner.a.
gcc_flags "-L${ProjectDir} -lBarcodeScanner -force_load ${ProjectDir}/libBarcodeScanner.a”
But it shows an error:
Error: Could not parse additional mtouch arguments: No matching quote found.
What should i do ?
Do i need to create a binding project to use a library like BarcodeScanner ?
Error: Could not parse additional mtouch arguments: No matching quote found.
That does not look like a Xamarin.iOS (mtouch) error message. Those start with a MT prefix followed by 4 numbers, e.g. MT2001. Could it be Xamarin Studio giving you this error ?
What should i do ?
Review the flags: are they identical to what's pasted above ?
No matching quote found. makes is sound there's an extra quote in there. Maybe one of the " is wrong (e.g. a autocorrection giving you a smart quote) ?
Or maybe your project directory (replaced from ${ProjectDir} contains a quote character ?
Also can you edit your question to add which version of Xamarin Studio you're using ?
Do i need to create a binding project to use a library like BarcodeScanner ?
No, but it's the preferred ways to link static libraries. Using a binding project removed the need to add Additional mtouch arguments inside every projects and every build configuration (e.g. Debug, Release...) of your applications.
I will answer my own question, maybe it will help someone. I declared in my MainController that i needed:
using MonoTouch.CoreVideo;
using MonoTouch.CoreMedia;
using MonoTouch.CoreGraphics;
using MonoTouch.CoreFoundation;
And after that i referenced only the static library with:
-gcc_flags "-L${ProjectDir} -lBarcodeScanner -force_load ${ProjectDir}/libBarcodeScanner.a"
#poupou's "maybe" was spot on, but I'll be pedantic and explain exactly.
Look closely at this line I just quoted from your original question. I've marked it down using code (four spaces prefix per line), and broke it into two lines. Nothing else has been changed. Hopefully the error should be obvious now:
- gcc_flags "-L${ProjectDir} -lBarcodeScanner
-force_load ${ProjectDir}/libBarcodeScanner.a”
Essentially, you used different types of double quotes. The first double-quote character above is Unicode 0x0022, which is the regular Quotation Mark. The second double-quote character above is Unicode 0x8221, or Right Double Quotation Mark. It might be that you had copied & pasted all or part of the line above from a web page, rather than typing it in.
For command-line processing, mixing your styles of double quotes simply won't work. You'll need to use balanced regular quotation marks, as you wrote in your own answer just now (but might not have specifically noticed?) FWIW, the right- and left- variants of the quotation mark are usually used for word processing, web pages, etc. where the style aesthetic matters.
Since you didn't use code-markup when quoting that line originally (while I noticed you did, in your recently posted answer) it looks like Stack Overflow "helpfully" tried to render the quotes as similar in style, fooling us into looking elsewhere for the problem, when it was right in front of us.
Anyway, next time you get an error about mismatched quotes, I suggest you carefully check their type. If they look the least bit different, they may not be the right kind of quotes.
I have a code block in an org document
#+NAME: result_whatever
#+BEGIN_SRC python :session data :results value :exports none
return(8.1 - 5)
#+END_SRC
which I evaluate inline:
Now, does this work? Let's see: call_result_whatever(). I'd be surprised ...
When exporting to LaTeX, this generates the following:
Now, does this work? Let's see: \texttt{3.1}. I'd be surprised \ldots{}
However, I don't want the results to be displayed in monospace. I want it to be formatted in "normal" upright font, without any special markup.
How can I achieve this?
You should be able to get it work using the optional header arguments which can be added to call_function().
I don't have LaTeX installed on this system so can't fully test the outputs to ensure they come out exactly as desired, I'm using the plain text output to compare instead. However you can use the following syntax as part of your call to modify the results.
Now, does this work? Let's see call_results_whatever()[:results raw].
I'd be surprised ...
Without the [:results raw] the output to Plain Text (Ascii buffer) is Let's see `3.0999999999999996'.. With the added results it becomes Let's see 3.0999999999999996.
For full details of the available results keywords as well as other optional header arguments for the inline blocks please see Evaluation Code Blocks and Results arguments.
this is 5 years later. apparently in org-mode 8.2 or so, a new variable was introduced (documenting in "Evaluating Code Blocks" in the org-mode manual, but this from etc/ORG-NEWS in the source tree):
*** New option: org-babel-inline-result-wrap
If you set this to the following
: (setq org-babel-inline-result-wrap "$%s$")
then inline code snippets will be wrapped into the formatting string.
so, to eliminate \texttt{}
(setq org-babel-inline-result-wrap "%s")
The problem of this type can be solved in two ways:
1: Easy does it:
A plain query-replace on the exported buffer.
Once you're in the LaTeX buffer,
beginning-of-buffer or M-<
query-replace or M-%
enter \texttt as the string that you want to replace
enter nothing as the replacement
continue to replace each match interactively
with y/n or just replace everything with !
2: But I wanna!
The second way is to nag the org-mode mailing list into
implementing a switch or an option for your specific case.
While it's necessary sometimes, it also produces a system
with thousands of switches, which can become unwieldy.
You can try, but I don't recommend.
Currently I am trying to set application name using
net.rim.blackberry.api.homescreen.HomeScreen.setName("これはある");
but it throws exception: IllegalArgumentException.
Can anyone provide the solution?
I am using Blackberry JDE 5.0.
This is probably a string encoding problem. Try
new String(new String("これはある").getBytes("UTF-16BE"), "UTF-16BE");
It's not pretty but I think that will work.
Here's a link to the Blackberry string spec: http://www.blackberry.com/developers/docs/5.0.0api/java/lang/String.html
By default it's ISO-8859-1 which does not include Japanese characters.
The problem you are facing is how to get a string represented in your source code into your application with the same characters. For latin characters, this is pretty straightforward, as we can just put the characters in quotes, and get a string, like "Hello world"
When you go to non-latin, like Japanese, it gets harder. You can still directly write Japanese in your source code, but you need to make sure your editor and your compiler agree on an encoding so that the characters can be interpreted correctly. The Java-SE compiler takes an argument "-encoding" which allows you to specify the encoding of your java source files.
Unfortunately, rapc, the BlackBerry compiler, does not offer an option to specify encoding, even though it is invoking javac itself. So rapc uses the platform default, which is utf-8 on Linux and OSX and iso-8859-1 on Windows.
The way around this problem is to use a feature of the Java language for parsing strings - unicode escaping. By entering the six character sequence "\u3053" in a string, the java compiler will parse that number as hexidecimal and use the corresponding unicode code point, solving problems with source file encoding.
So "Hello world" and "\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064" will result in the same strings appearing in your class files.
Because of this, Svetlin's answer from the comments is the right approach here:
net.rim.blackberry.api.homescreen.HomeScreen.setName("\u3053\u308C\u306F\u3042\u308B");
In my english thesis latex file, how to mention the following non English words: François, École Fédérale?
Thanks and regards!
The traditional way is to use the accent-adding macros:
Fran\c{c}ois
\'Ecole F\'ed\'erale
(You can also write Fran\c{}cois or Fran\c cois; the \c macro uses no parameter; the braces or space are just a trick to allow LaTeX to see the proper macro name.)
Otherwise, try this:
\usepackage[utf8]{inputenc}
and type the accents directly, with UTF-8 encoding.
There are a host of more-or-less subtle issues with fonts and hyphenation.
If you don't go the UTF8 inputenc route, and yet find yourself writing a lot of these names, I'd suggest defining macros for them. At the simplest, you can say \newcommand\Francois{Fran\c cois} but then you need to be sure to use it as such: \Francois{} so that any spaces afterwards don't get gobbled.
On the other hand, the following technique works pretty well too (though I can't take credit for inventing it - I saw it originally in a short talk at BachoTeX 2009 by Philip Taylor):
\makeatletter
\let\latex#less<
\catcode`<13
\def<{\ifmmode\latex#less\else\expandafter\find#name\fi}
\def\find#name#1>{\#nameuse{name.#1}}
\def\DefineName#1#2{\#namedef{name.#1}{#2}}
\makeatother
Now you can define special names using, e.g.
\DefineName{Francois}{Fran\c cois}
\DefineName{Ecole Federale}{\'Ecole F\'ed\'erale}
and later on you can use them in text with
I ran into <Francois> at the <Ecole Federale> the other day.
You can make your tags (the plain ASCII versions) be whatever you want - they don't have to actually be related to the properly accented names.
EDIT: in response to the issue that misspelled names don't produce errors, you can change the definition of \find#name to
\def\find#name#1>{\ifcsname name.#1\endcsname
\#nameuse{name.#1}%
\else
\#latex#warning{Undefined name #1}%
\fi}
Note that \#latex#warning{...} can be changed to \#latex#error{...}\#eha and it will complain more forcefully. Or if you want to pretend to be (or actually be) a package you can use \Package(Warning|Error){<package name>} in place of \#latex#(warning|error) and it won't pretend to be a built-in LaTeX error anymore.
We have been reading and writing Sticky Notes/Annotations/Comments to pdfs via an activex control in our application for a number of years. We have recently upgraded to Delphi2009 with Unicode Support. The following is causing problems.
When we call
CAcroPDAnnot.GetContents
The results seem to be rather strange and we lose our Unicode Chars. It is not like saving as an ansi string which would usually result in returning ????? instead we get a string such as
‚És‚“ú‚É•—Ž×‚ð‚Ђ¢‚½‚ç
For a string of Japanese characters.
However if I save the comments in the pdf to a datafile via the menu in the pdf itself it is written to file as something like
0kˆL0Oeå0k˜¨ª0’0r0D0_0‰
The latter can be export and reimported into an acrobat pdf and will recreate the correct unicode characters. However once I call CAcroPDAnnot.GetContents in my code it is coming back as something else.
Is CAcroPDAnnot.GetContents broken?
Is there an encoding scheme I should be aware of?
Is there an alternative I might be able to do?
Thanks
‚És‚“ú‚É•—Ž×‚ð‚Ђ¢‚½‚ç
That's the string:
に行く日に風邪をひいたら
in CP-932 aka Shift-JIS encoding, an awful but lamentably still-popular encoding in Japan.
You're currently interpreting it in as CP-1252 (Windows Western European). If your PDF-reading component won't convert it for you automatically, you'll need to find a way to detect what encoding the document is in and convert it manually.
I don't know what Delphi provides for reading encodings, but have you got the encodings for Shift-JIS installed in Windows, from the Control Panel -> Regional Options -> "Install files for East Asian languages" option? If not, that might explain why it'd be failing to convert automatically, perhaps.
You're not exactly giving us a lot of information to work with.
I take it you're talking about the "Acrobat.CAcroPDAnnot" class' method GetContents here. Which version of Acrobat are you using? Have you perhaps switched versions (or run an update) around the time you started programming with Delphi 2009?
Then: how did you instantiate the object? If using a *_TLB.pas file generated from the DLL, are you certain it still matches it? (Try re-generating it, if uncertain).
Third: how are you calling the method? What type of variable are you assigning the result to?
What might also help, is if you could provide a sample of an annotation (preferably including non-ASCII chars); and for that annotation:
what it should look like (and what it does look like inside Reader)
what it returns when using a pre-2009 version of Delphi*
what it returns when using Delphi 2009*
(* preferably the HEX byte codes of the (ansi/wide)strings; but output from the Ctrl-F7 inspector should do)
Then maybe someone could provide a more meaningful answer.
Ok, one of the main differences between Delphi 2009 and the earlier versions is that the default string type is an unicode string. That means that if you use the same ActiveX component as in previous versions, you are passing unicode strings to ascii strings and that is usually not a good idea.
There are a couple of solutions for this problem:
Try if you can upgrade your activeX component so that it supports full unicode strings.
Use AnsiString and not string to communicate with the activeX component. In this case, you can still use the old interface, but you are still bound to the same limitations.
Use an other control that creates pdf. There is a lot to find, but be prepared to change a big chunk of your software. (Some controls are XML based and use encoding. )