I'm creating xml-like mark-up language using System.Xml.XmTextWriter that will be read by a third party app.
In this mark-up language, symbols > and < when inside an element, need to show up as, but the XmlTextWriter converts them to > ; and < ; (no spaces, I just added those because of formatting on here).
Any ideas on how to prevent this while still working with XmlTextWriter?
You can output raw XML (no escaping) with the XmlTextWriter.WriteRaw method.
http://msdn.microsoft.com/en-us/library/z7sb8fsy.aspx
Related
Youtrack and many other web apps use KaTeX to render mathematical notation and markdown for all other things.
However markdown parser treats certain characters in a special way and interferes with KaTeX.
For example the following equation
\begin{equation}
X_i = \begin{cases}
0, t_i < t_{i-1} \\
1, (t_i - t_{i-1}) > t_0 \\
X_{i-1}, otherwise
\end{cases}
\end{equation}
Would render incorrectly as
Note the missing line.
The reason is that < and > and the text between are treated as an HTML tag and thus ignored.
The intended rendering would instead look like
Reordering the cases resolves the issue as well as replacing < with \leq and > with \geq. But both solutions seem incomplete and in the latter case change the meaning of the equation.
In LaTeX there are no predefined commands for < and > and KaTeX currently does not support \newcommand yet.
I have posted a similar question on tex stackexchange. And while it was closed there as off-topic, users provided a solution in comments. Using \lt for < and \gt for > is supported in KaTeX. So the equation should be typed as
\begin{equation}
X_i = \begin{cases}
0, t_i \lt t_{i-1} \\
1, (t_i - t_{i-1}) \gt t_0 \\
X_{i-1}, otherwise
\end{cases}
\end{equation}
I have two java source files. Both represent the same class (semantically), but they were formatted differently.
For example, one of them contains the following line:
return Boolean.valueOf(Boolean.getBoolean("abc"));
While in the second file it looks like 2 lines:
return Boolean.valueOf(
Boolean.getBoolean("abc"));
In both cases, when I apply formatting (Ctrl+Alt+L), these lines do not change.
Is it possible to format them in some canonical way: that is, to get the same code if the only difference is formatting?
Equivalently: is there any way to remove all ignorable whitespace? Such a 'dried-out' program would then be easily restored using 'Reformat code'.
You should be able to do this if you turn off "Wrapping and Braces | Keep when reformatting | Line Breaks" in the Java code style settings.
Go to File > Settings > Ediotor > Code Style > java
in tab Wrapping and Braces uncheck line breaks
Apply and make (Ctrl+Alt+L) again.
For example when my code says:
System.out.println("Printing demo features");
I use CTRL+SHIFT+L and Intellij make this:
System.out.println("Printing demo features" );
Thanks for your help.
It looks like you have custom code styling in place for Java, thus the auto format function tries to match it:
Check Settings > Editor > Code Style > Java > Spaces and look for "Within" grouping. See if you have some options marked like "Method call parentheses". If you don't have any custom style in place, simple reset the Java style to default and it should be "fixed".
Obs.: I am on Intellij14, options might be different.
Check off Settings > Editor > Code Style > Java > Spaces > Within > Method call parentheses
If above didn't help: "File" -> "Invalidate Caches / Restart..." (sounds unrelated, but in my case actually solved it)
I've written several IDL programs to analyse some data. To keep it simple the programs read in some time varying data and calculate the fourier spectrum. This spectrum is written to file using this code:
openw,3,filename
printf,3,[transpose(freq),transpose(power)],format='(e,e)'
close,3
The file is then read by another program using this code:
rdfloat,filename,freq,power,/double
The rdfloat procedure can be found here: http://idlastro.gsfc.nasa.gov/
The error i get when trying to read the a file is: "Input conversion error. Unit: 101"
When i delve in to the file being read, i notice several types of unrecognised characters. I dont know if these are a result of the writing to the file or some thing else related to the number of files being created (over 300 files)
These symbols/characters are in the place of a single number:
< dle> < dc1> < dc2> < dc3> < dc4> < can> < nak> < em> < soh> < syn>
Example of what appears in the file being read, Note they are not consecutive lines.
7.7346< dle>18165493007e+01 8.4796811549010105e+00
7.7354408697119453e+01 1.04459538071< dc2>1749e+01
7.7360701595839< can>28e+01 3.0447318983094189e+00
Whenever I run the procedures that write the files, there is always at least one file that has some or all of these characters. The file/s that contains these characters is always different.
Can anyone explain what these symbols are and what I might be doing to create them as well as how to ensure they are not written to file?
I see two things that may be causing a problem. But first, I want to suggest a few tips.
When you open a file, it is useful to use the /GET_LUN keyword because it allows IDL to find and use a logical unit number (LUN) that is available (e.g., in case you left LUN 3 open somewhere else). When you print formatted data, you should specify the total width and number of decimal places. It will make things easier because then you need not worry about changing spacings between numbers in a file.
So I would change your first set of code to the following (or some variant of the following):
OPENW,gunit,filename[0],/GET_LUN,ERROR=err
FOR j=0L, N_ELEMENTS(freq) - 1L DO BEGIN
PRINTF,gunit,freq[j],power[j],FORMAT='(2e20.12)'
ENDFOR
FREE_LUN,gunit ;; this is better than using the CLOSE routine
So the first potential issue I see is that if your variable power was calculated using something like FFT.pro, then it will be a complex float or complex double, depending on the input and keywords used.
The second potential issue may be due to an incorrect format statement. You did not tell PRINTF how many columns or rows to expect. It might not know how to handle the input properly, so it guesses and may result in those characters you show. Those characters may be spacing characters due to the vague format statement or the software you are using to look at the files (e.g., I would not recommend using Word to open text files, use a text editor).
Side Note: You can open and read the file you just wrote in a similar fashion to what I showed above, but changed to the following:
n = FILE_LINES(filename[0])
freq = DBLARR(n)
power = DBLARR(n)
OPENR,gunit,filename[0],/GET_LUN,ERROR=err
FOR j=0L, N_ELEMENTS(freq) - 1L DO BEGIN
READF,gunit,freq[j],power[j],FORMAT='(2e20.12)'
ENDFOR
FREE_LUN,gunit ;; this is better than using the CLOSE routine
i am trying to parse the xml file but getting exceptions since the file contains the special character. To make file to parse successfully i have to enclose the value in since there are many special characters in my xml files at different places is there any way like declaration or something so that these fields will get replaced with CDATA whicch will reduce the mannual work exerytime?
Well, either your parser is broken, or your XML.
XML has 5 predefined entities, which your parser should support, and whatever generates your XML should use them when appropiate:
< <
> >
& &
' '
" "