I've started playing with TiKZJax, a system for converting TikZ images to svg, and embedding them in html pages.
I do like this tool a lot, but I'm having some troubles with mathematical formulas (LaTeX) in TikZJax nodes. The problem is that some basic mathematical symbols do not render correctly.
Here you can see a webpage with two MWEs.
The first one is derived from an image I was preparing, where I first noticed the issue.
The negative y axis labels have a "times" sign instead of the expected minus.
The two texts roughly at (3,3) and (6,6) are two "experiments". One should be $-2$ and the other has a bunch of random symbols $\hbar \pi \times \otimes \sum$. The third and the fourth won't render correctly.
The second MWE is the same you can find in the TikZJax demo here, but with $-\y$ in place of $\y$. Again, the minus sign won't render correctly.
The compilation log I see from the console does not complain about anything.
I tried inspecting the "times" symbol that appears in place of the minus sign. I am no expert at all, but from what I understand, this should correspond to the £ symbol in the font family cmsy10:
<text alignment-baseline="baseline" y="61.57359313964842" x="-51.62625122070311" style="font-family: cmsy10; font-size: 12;">£</text>.
I looked for a table of cmsy10 fonts and I found one in this TeX StackExchange thread.
It seems to me that the minus sign is two cells to the right from the times sign. I am not sure how to read the "coordinates" in the table. Anyway from this site £ corresponds to 163, and 161 corresponds to an inverted exclamation mark "¡".
I created an html file with the svg code for (a version of) the first MWE, and changed the pound symbols into inverted exclamation marks. This produces the expected minus signs.
Could it be that the author of TikZJaX got the mapping of some math symbols wrong?
Or am I getting it all wrong?
In the latter case, can something be done to get the correct minus signs (and other symbols)?
Thanks a lot for your help
Francesco
PS By the way, I noticed that the TikZJaX demo here does not actually map the fonts to the correct font family. I think this is because something goes wrong with the link to the css file in the header of the webpage. I'm guessing this because I get a similar rendering if I comment out the link to the css file, which contains a list of font families.
Related
My problem occurs when I try to use some data/strings in a p-element.
I start of with data like this:
data: function() {
return {
reportText: {
text1: "This is some subject text",
text2: "This is the conclusion",
}
}
}
I use this data as follows in my (vue-)html:
<p> {{ reportText.text1 }} </p>
<p> {{ reportText.text2 }} </p>
In my browser, when I inspect my elements I get to see the following results:
<p>This is some subject text</p>
<p>This is the conclusion</p>
As you can see, there is suddenly a difference, one p element uses and the other , even though I started of with both strings only using . I know and technically represent the same thingm, but the problem with the string is that it gets treated as a string with 1 large word instead of multiple separate words. This screws up my layout and I can't solve this by using certain css properties (word-wrap etc.)
Other things I have tried:
Tried sanitizing the strings by using .replace( , ), but that doesn't do anything. I assume this is because it basically is the same, so there is nothing to really replace. Same reason why I have to use blockcode on stackoverflow to make the destinction between and .
Logged the data from vue to see if there is any noticeable difference, but I can't see any. If I log the data/reportText I again only see string with 's
So I have the following questions:
Why does this happen? I can't seem to find any logical explanation why it sometimes uses 's and sometimes uses 's, it seems random, but I am sure I am missing something.
Any other things I could try to follow the path my string takes, so I can see where the transformation from to happens?
Per the comments, the solution devised ended up being a simple unicode character replacement targeting the \u00A0 unicode code point (i.e. replacing unicode non-breaking spaces with ordinary spaces):
str.replace(/[\\u00A0]/g, ' ')
Explanation:
JavaScript typically allows the use of unicode characters in two ways: you can input the rendered character directly, or you can use a unicode code point (i.e. in the case of JavaScript, a hexadecimal code prefixed with \u like \u00A0). It has no concept of an HTML entity (i.e. a character sequence between a & and ; like ).
The inspector tool for some browsers, however, utilizes the HTML concept of the HTML entity and will often display unicode characters using their corresponding HTML entities where applicable. If you check the same source code in Chrome's inspector vs. Firefox's inspector (as of writing this answer, anyway), you will see that Chrome uses HTML entities while Firefox uses the rendered character result. While it's a handy feature to be able to see non-printable unicode characters in the inspector, Chrome's use of HTML entities is only a convenience feature, not a reflection of the actual contents of your source code.
With that in mind, we can infer that your source code contains unicode characters in their fully rendered form. Regardless of the form of your unicode character, the fix is identical: you need to target these unicode space characters explicitly and replace them with ordinary spaces.
While editing some old ColdFusion code I found a <td> which has a bgcolor property. The value of it was ##89969E. I copied the code to a HTML file and found out the color was different in ColdFusion.
Now, i noticed the double #, so i removed one and the color was the same. Why does the color change when adding/removing a #?
jsFiddle
As a basic premise, additional hashes are interpreted as a missing/erroneous value and so replaced with a zero, so ##89969E becomes #0089969E. Note that HEX codes can be as long as 8 digits following a hash (if aRGB), where the last two refer to transparency
Missing digits are treated as 0[...]. An incorrect digit is simply
interpreted as 0. For example the values #F0F0F0, F0F0F0, F0F0F, #FxFxFx and FxFxFx are all the same.
When color strings longer than 8 characters or shorter than 4
characters are used, things start to get strange.
However there are a lot of nuances - you can find out more about this here, and for some fairly entertaining results this creates, have a little read here
I've tried the answers on 4 other S.O. questions but my image is still not showing up.
I'm learning to code by going through Dash at General Assembly. However I'm building this project using Sublime 3.
body{
background-image: url("Southern California Sunset.jpg");
My html file and images are saved in the same folder.
Where I obtained the background image:
Southern California Sunset.jpg
Your CSS syntax for background image is correct:
background-image: url("Southern California Sunset.jpg");
You can replace each space with %20 which is the HTML URL encoding equivalent. But in a modern web browser this may not be necessary. You can also use camel case (that is, capitalization of the first letter of every word) without spaces or another naming convention to eliminate the spaces.
As long as the syntax is correct and the file is in the right place, the code should work properly.
You do, however, have a small (unrelated) syntax error in your code; this:
<input type="email"; placeholder"Your email"/>
should be:
<input type="email" placeholder"Your email" />
HTML is generally pretty forgiving of syntax errors. Still, it is best to avoid them.
Try replacing the spaces in the filename with %20:
background-image: url("Southern%20California%20Sunset.jpg");
In general, avoid spaces in file names. Much easier.
Like he said you should avoid using spaces when saving an image. I use the 'camel humps' method for all my coding. So instead of using spaces you capitalize the all the words.
So instead of 'my example image text.jpg', it would be MyExampleImageText.jpg.
You must have a picture size under 1 MB or 500 KB. This worked.
body {
background-image: url(yourfile.jpeg);
}
Today I discovered this by accident:
<hr width=100% color=red />
creates a red horizontal rule, but
<hr width=100% color=red/>
creates a green horizontal rule.
This isn't just with the color red, if there is a / directly behind the color name, another color will be drawn. This doesn't work for color codes like #000000 (to #000000/).
Just of curiosity, here is my question: How does the color get chosen? Is this a bug or intended?
Additional info:
Browser: Google Chrome 29.0.1547.66 m
Installed plugins / add ons: Ad Block Plus
I tested this with IE 10 and it has the same problem as Chrome.
This is, somewhat surprisingly, intentional error handling, described in clause 2.4.6 Colors of HTML5 CR. It is presumably meant to maintain compatibility with legacy content that has weirdly broken color designators that have been traditionally processed in a certain manner by browsers.
When the mixed-syntax (partly HTML, partly XHTML) markup <hr width=100% color=red/> is used, in a document served as text/html (when served with an XHTML content type, it would simply cause nothing but an error message to be shown), the color attribute will be parsed as red/ (with the slash as part of the value). Since this does not match any color name, rules for parsing a legacy color value will be applied.
This means that any character that is not a hexadecimal digit is replaced by the digit 0, and if the resulting value is not six characters long, trailing zeroes will be added. Finally, the value is prefixed with #, so it will be interpreted as a hexadecimal color designator. Thus, red/ yields #0ed000, which is the light green color that you see.
Similarly, <hr width=100% color=blue/> would cause the color #b00e00 to be used.
The problem can of course be avoided by using either HTML syntax (which has no / before >) or XHTML syntax (which has quotation marks around each attribute value).
The semantic analizer of your browser detect the <hr> tag and later try to determinate the atributes for that label.
Using white spaces as token separator, your first line have 3 attributes (noted that the correct slash for finish a tag in html is / ). In this case, the second token color=red as interpreted as a attribute (color) and value (red). In your second line there are only 2 attributes. The second attribute (color) has the value red\ that is not a valid identifier in the asociative array for colors.
Why your browser return blue?
Each browser manage the exceptions that diferents ways, its problably that your browser return the first value in the asociative array colors.
I should recommend to you that use quotes as delimiter for attributes values.
I just tried it,and it works.
First I copy your code and execute, it was unexpected. Still I try same code, and I just put " " (double quotes) around the color name, and tried color codes too.
and I found, it is working properly with Crome,IE and Mozilla.
using the color attribute might be the problem. Try border-color.
<hr width="100%" style="border-color:#f00">
Before coming here, I tried myself by googling. After I read these two links
http://www.w3schools.com/tags/tag_bdo.asp
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_bdo
I still don't understand clearly what is the practical purpose?
Thanks in advance for those who shed some light on this.
Pretty striaghtforward. If you're writing a web page using a default language, such as English, that is rendered left-to-right, and you want to include a island of text in another language, such as a quote in Hebrew, that is rendered right-to-left you can use this tag to override the base direction in which the text is written onto the page in case the bi-directional algorithm is getting it wrong. You need to make sure that the font you're using supports the appropriate character set too, of course.
http://www.w3.org/TR/html40/struct/dirlang.html
I tried the code bellow, and noticed that it is apparently obsolete for Hebrew, at least:
<!DOCTYPE html>
<html>
<body>
<p>If your browser supports bi-directional override (bdo), the next line will be written from right to left (rtl):</p>
<p>חדשות, ידיעות מהארץ והעולם - עיתון הארץ</p>
<bdo dir="rtl">חדשות, ידיעות מהארץ והעולם - עיתון הארץ</bdo>
</body>
</html>
Both seemed to output the same line, which confused me, but prompted a search that lead me to the following article:
The bidirectional ordering of text in AbiWord is done automatically,
closely following the Unicode Bidirectional Algorithm (UBA; see the
Unicode Consortium website). The Unicode character set assigns each
character certain directional properties which are then used by the
UBA to order text. Thus, Hebrew or Arabic characters will
automatically be treated as right-to-left, and English characters as
left-to-right. There are some characters that are directionally
ambiguous, and how they are treated by the UBA depends on what
characters are found in their vicinity (this includes all white space
and punctuation characters).
http://fantasai.tripod.com/qref/HTML4/structure/bdo.html
Hope it helps