How to Break Line in MathJax using ReactJS - reactjs

I'm using MathJax I can't able to break the new line.
I am already tried using <br/> , \nand \\ but its not works for me.
const blockFormula = `x =√(t ) \\
\\mathrm{V}=\\frac{d x}{d t}=\\frac{1}{2} t^{\\frac{-1}{2}}`;
MathJax Doc version 1.0.1

The line-breaks you show are for HTML and for regular Latex. MathJax only treats the MATH MODE PART of Latex, not all of Latex so you need to accomplish line-breaks math mode style. You basically have at least 3 options:
Use the math mode gather environment:
<MathJax>
{
`$$\\begin{gather}
x =√(t ) \\\\
\\mathrm{V}=\\frac{d x}{d t}=\\frac{1}{2} t^{\\frac{-1}{2}} \\\\
\\end{gather}$$`
}
</MathJax>
Use the math mode align environment if you also want to align the rows:
<MathJax>
{
`$$\\begin{align}
x &=√(t ) \\\\
\\mathrm{V}=\\frac{d x}{d t}&=\\frac{1}{2} t^{\\frac{-1}{2}} \\\\
\\end{align}$$`
}
</MathJax>
Since you're doing this in React with HTML, you can also add the different rows to different HTML / React components to accomplish what you want:
<MathJax>{`$$x =√(t )$$`}</MathJax>
<MathJax>{`$$\\mathrm{V}=\\frac{d x}{d t}=\\frac{1}{2} t^{\\frac{-1}{2}}$$`}</MathJax>
There are probably more ways too.
I took the liberty of using my own better-react-mathjax in the sandbox that I prepared for you, showing all these options using both display math and inline math, but it should work the same in all libraries that correctly uses MathJax with React.

Related

react-spring Error: <path> attribute d: Expected number

I am using React-spring to morph my svgs - in this case, rather than a true morph, I'm really just translating particular parts of a large and complex svg on the y axis. I have a button that swaps the related vectors when clicked, so part of the image moves up on the first click, and back on the second.
When I first load the svg, I don't have any errors. I start to get errors after the first click, and the errors are related to this set of vectors:
"M0 834.5L31.6776 810.203L22.1257 798.768L36.2022 791.807H53.2951L79.9399 755.511V747.059L89.9945 740.098H107.087L121.164 713.249L136.749 700.819L158.366 690.875V679.44L179.481 668.501L195.066 637.178L208.137 619.279V586.961V570.056V559.118L195.066 546.688L179.481 516.359L219.197 519.839H244.836V475.588H266.956H297.623L306.169 391.562H323.262V342.339V338.859H324.268V342.339H327.284V339.853L329.295 338.859L331.306 339.853V342.339H334.825V339.853L336.836 338.859L338.847 339.853V342.339H342.869V339.853L344.88 338.859L346.891 339.853V342.339H349.907L357.448 278.2L349.907 260.798V248.866L372.53 236.933L392.639 248.866V260.798L386.607 278.2L392.639 309.027H396.158V306.541L398.169 305.546L400.18 306.541V309.027H404.202V306.541L406.213 305.546L408.224 306.541V309.027H412.246V306.541L414.257 305.546L416.268 306.541V309.027H420.29V306.541L422.301 305.546L424.311 306.541V309.027H428.333V306.541L430.344 305.546L432.355 306.541V309.027H436.377V306.541L438.388 305.546L440.399 306.541V309.027H444.421V306.541L446.432 305.546L448.443 306.541V309.027H452.464V306.541L454.475 305.546L456.486 306.541V309.027H460.508V306.541L462.519 305.546L464.53 306.541V309.027H468.552V306.541L470.563 305.546L472.574 306.541V309.027H476.596V306.541L478.607 305.546L480.617 306.541V309.027H484.137L489.667 278.2L480.617 260.798V248.866L497.71 236.933L518.322 248.866V260.798L512.29 278.2L528.88 342.339H530.388V339.853L532.399 338.859L534.41 339.853V342.339H538.432V339.853L540.443 338.859L542.454 339.853V342.339H547.481L558.541 278.2L547.481 260.798V248.866L569.098 236.933L589.208 248.866V260.798L578.148 278.2L589.208 343.831H591.721V341.345L593.732 340.35L595.743 341.345V343.831H599.765V341.345L601.776 340.35L603.787 341.345V343.831H607.809V340.35H608.814V343.831V384.104L634.956 439.79H636.464V437.304L638.475 436.31L640.486 437.304V439.79H644.508V437.304L646.519 436.31L648.53 437.304V439.79H652.552V437.304L654.563 436.31L656.574 437.304V439.79H660.791V437.304L662.607 436.31L664.617 437.304V439.79H668.639V437.304L670.65 436.31L672.661 437.304V439.79H676.683V437.304L678.694 436.31L680.705 437.304V439.79H684.727V436.31H685.732V439.79V494.233H723.437V559.118L1103 548.676V923H0V834.5Z",
"M0 609.069L32.6776 585.203L23.1257 573.768L37.2022 566.807H54.2951L80.9399 530.511V522.059L90.9945 515.098H108.087L122.164 488.249L137.749 475.819L159.366 465.875V454.44L180.481 443.501L196.066 412.178L209.137 394.279V361.961V345.056V334.118L196.066 321.688L180.481 291.359L220.197 294.839H245.836V250.588H267.956H298.623L307.169 166.562H324.262V117.339V113.859H325.268V117.339H328.284V114.853L330.295 113.859L332.306 114.853V117.339H335.825V114.853L337.836 113.859L339.847 114.853V117.339H343.869V114.853L345.88 113.859L347.891 114.853V117.339H350.907L358.448 53.2003L350.907 35.7983V23.8655L373.53 11.9328L393.639 23.8655V35.7983L387.607 53.2003L393.639 84.0266H397.158V81.5406L399.169 80.5462L401.18 81.5406V84.0266H405.202V81.5406L407.213 80.5462L409.224 81.5406V84.0266H413.246V81.5406L415.257 80.5462L417.268 81.5406V84.0266H421.29V81.5406L423.301 80.5462L425.311 81.5406V84.0266H429.333V81.5406L431.344 80.5462L433.355 81.5406V84.0266H437.377V81.5406L439.388 80.5462L441.399 81.5406V84.0266H445.421V81.5406L447.432 80.5462L449.443 81.5406V84.0266H453.464V81.5406L455.475 80.5462L457.486 81.5406V84.0266H461.508V81.5406L463.519 80.5462L465.53 81.5406V84.0266H469.552V81.5406L471.563 80.5462L473.574 81.5406V84.0266H477.596V81.5406L479.607 80.5462L481.617 81.5406V84.0266H485.137L490.667 53.2003L481.617 35.7983V23.8655L498.71 11.9328L519.322 23.8655V35.7983L513.29 53.2003L529.88 117.339H531.388V114.853L533.399 113.859L535.41 114.853V117.339H539.432V114.853L541.443 113.859L543.454 114.853V117.339H548.481L559.541 53.2003L548.481 35.7983V23.8655L570.098 11.9328L590.208 23.8655V35.7983L579.148 53.2003L590.208 118.831H592.721V116.345L594.732 115.35L596.743 116.345V118.831H600.765V116.345L602.776 115.35L604.787 116.345V118.831H608.809V115.35H609.814V118.831V159.104L635.956 214.79H637.464V212.304L639.475 211.31L641.486 212.304V214.79H645.508V212.304L647.519 211.31L649.53 212.304V214.79H653.552V212.304L655.563 211.31L657.574 212.304V214.79H661.791V212.304L663.607 211.31L665.617 212.304V214.79H669.639V212.304L671.65 211.31L673.661 212.304V214.79H677.683V212.304L679.694 211.31L681.705 212.304V214.79H685.727V211.31H686.732V214.79V269.233H724.437V334.118L1104 323.676V698H1L0.5Z"
error:
Error: <path> attribute d: Expected number, "…323.676V698H1L0.5Z".
After the second click, the errors explode in number, but appear to be for vectors I can't find in my svg (this is when the image returns to it's original position). I'm not sure where the numbers are coming from, which makes me think maybe they are generated by Spring. At any rate, everything looks fine in the actual browser window, so I don't think these errors are legit (in the sense that the image looks good, and the terminal point looks right, the animation happens, and even can be repeated...so what exactly is it complaining about).
The question is:
Is there actually something wrong with these vectors?
If not, I'm not sure how to fix the error. I'm not sure why d would expect a number when it should expect a set of svg instructions. Any advice would be welcome!
The spring code is here:
const animationProps = useSpring({
castle: castleCoord[curIndex],
//moon: moonsCY[curIndex]
});
I am trying to move the castle independent of several elements in the svg.
I get the exact same error by creating a bare minimum svg tag and adding 2 path elements to it with the "d" attributes set to the vector strings you provided, so I don't think its anything specific to React-spring. Browsers are extremely forgiving with how they parse svg xml so even when there are errors it often still renders fine.
If I put that same svg through the svg minifier/validator tool here: https://jakearchibald.github.io/svgomg/ , and then use that cleaned version in the html instead, there are no more errors. But since i'm not sure what its supposed to look like I can't really say if that's a solution or not, but its worth trying.
It turned out to be something about the editor I had used to create the SVGs. After making changes to the base files, I was able to fix related arity errors, and these errors also went away. Maybe not an exciting answer, but if the two SVGs are very similar but still throwing these errors, consider going back and remaking the SVGs (in this case, I literally copy-pasted the SVG back in place and it changed the markup).

Why UTF-8 Unicode in address bar vs GET form is difference in C?

I've developed a simple web page using C.
I will get the url address values and check them using strtok, strsep.
que=getenv("QUERY_STRING");
...
strcpy(val,strsep(&string,"="));
printf("%s<br>",val);
Browser Result when using <form method="GET">
E.g: When you type ۱ in an input field and press submit, it redirects to http://localhost/api?identifier=%26%231777%3B.
Output of getenv("QUERY_STRING") :
identifier=%26%231777%3B
Trying with different values:
۱ => %26%231777%3B
۲ => %26%231778%3B
۳ => %26%231779%3B
۱۲۳ => %26%231777%3B%26%231778%3B%26%231779%3B
It can easily be fixed using a function in the DecodeQueryStringC.
This is written by Max Base.
https://github.com/BaseMax/DecodeQueryStringC
decodeUrl(val,val);
printf("Fix:%s<br>",val);
Browser result when manually typed in the address bar
I am using Firefox 60.5.1esr (64-bit) and Chromium 71.0.3578.98 (Official Build) (64-bit).
E.g: When type ‍?identifier=۱ at the end of the http://localhost/api :
It redirects to http://localhost/api?identifier=%DB%B1 automatically by the browser.
Output of getenv("QUERY_STRING") :
identifier=%DB%B1
Trying with different values:
۱ => %DB%B1
۲ => %DB%B2
۳ => %DB%B3
۱۲۳ => %DB%B1%DB%B2%DB%B3
I also want to support when the user manually modifies the URL (link).
Guide me.
The percent-encoded string
%26%231779%3B
does not decode to ۱ but ۳ which is a HTML entity and not UTF-8. You shouldn't be using decodeHtmlEntities but just the decodeUrl. Likewise there is some code that is doing the redirect that is doing too much.
Don't know how about Arabic, in Hebrew there are different types of encoding. Like UTF8 and other ones,didn't fall into details but did you check that? I didn't anything with relevance to that in your post.

How to use template parameters in page content in hugo

Is it possible to use template parameters in the content of a post with Hugo? E.g. if I have the following parameters:
[params.company]
name = "My Company"
Can I then do something like this in the content of a post?
This site, {{ .Site.BaseURL }} is operated by {{ params.company.name }}
I've tried, but it's literally printing the above instead of interpolating the variables.
1. Front matter way
As far as I'm aware, it's not possible* to put variables within the markdown file's content because MD parser would strip them, but it's possible to do it using custom variables on the front matter of each .md content file. The Hugo engine can target any fields you set in front matter. Front matter fields can be unique as well.
In your case, the template which is called to show the rendered .MD file has access to front matter parameters and you can change template's behaviour (like add classes of extra <div>'s) or even pull the content right from the parameter.
For example, on my .md files I have:
---
title: "Post about the front matter"
<more key pairs>
nointro: false
---
The key nointro: true would make my first paragraph to be normal size. Otherwise, if key is absent or false, first paragraph would be shown at larger font size. Technically, it's adding a custom class on a <div>.
In the template, I tap into the custom parameter nointro this way:
parent template which shows your markdown file, which has front matter parameters:
<div class="article-body {{ if .Params.nointro }} no_intro {{ end }}">
{{ .Content }}
</div><!-- .article-body -->
Notice I can't put variables within {{ .Content }}, but I can outside of it.
For posterity, that's piece of the content from a file hugo/themes/highlighter/layouts/partials/blog-single-content.html, it's a partial for single post content. You can arrange your partials any way you like.
Obviously, that's Boolean parameter flag, but equally it could be content which you could use directly:
MD file's top:
---
title: "One of our clients"
<more key pairs>
companyname: "Code and Send Ltd"
---
Text content is put here.
Then, reference it like this (extra insurance against blank value using IF):
Anywhere in Hugo template files:
{{ if .Params.companyname }}{{ .Params.companyname }}{{ end }}
2. Using config.(toml/yaml/json)
Now, looking at your example, "This site is operated by " would almost warrant a custom field in more global location, for example, hugo/config.toml. If I wanted to add a companyname into my config, I'd do it this way:
hugo/config.toml:
BaseURL = "_%%WWWPATH%%_"
languageCode = "en-uk"
title = "Code and Send"
pygmentsUseClasses = true
author = "Roy Reveltas"
theme = "Highlighter"
[params]
companyname = ""
Then I'd use it anywhere via {{ .Site.Params.headercommentblock }}.
I guess if you want your client pages to be static pages then single location might not be the best and you might want to tap into front-matter. Otherwise, if it's a site's footer, this way is better. Alternatively, you could even put this data even on data files.
3. Using custom placeholders and replacing via Gulp/npm scripts
I said not possible*, but it's possible, although unconventional and more risky.
I had such setup when I needed two builds for my website: 1) Prod and 2) Dev. Prod URL's were coming from two places: CDN and my server. Dev had to come from a single place in a static folder because I wanted to see images and was often working offline on a train.
To solve that, I used two custom variables in all my templates (including markdown content): _%%WWWPATH%%_ and _%%CDNPATH%%_. I came up with this unique pattern myself by the way, feel free to adapt it. Then, I put it also on hugo/config.toml as:
hugo/config.toml:
BaseURL = "_%%WWWPATH%%_"
After Hugo happily generated the website with those placeholders, I finished off the HTML's using a Grunt task:
grunt file:
replace: {
dev: {
options: {
patterns: [{
match: /_%%CDNPATH%%_+/g,
replacement: function () {
return 'http://127.0.0.1:1313/'
}
}, {
match: /_%%WWWPATH%%_+/g,
replacement: function () {
return 'http://127.0.0.1:1313/'
}
}...
For posterity, I recommend Gulp and/or npm scripts, I'd avoid Grunt. This is my older code example above from the days when Grunt was the best.
If you go this route, it's riskier than Hugo params because Hugo won't error-out when your placeholder values are missing or anything else wrong happens and placeholders might spill into the production code.
Going this route you should add multiple layers of catch-nets, ranging from simple following Gulp/Grunt/npm scripts step which searches for your placeholder pattern to pre-commit hooks ran via Husky on npm scripts that prevent from committing any code that has certain patterns (for example, %%_). For example, at a very basic level, you would instruct Husky to search for anything before allowing committing this way:
package.json of your repo:
"scripts": {
"no-spilled-placeholders": "echo \"\n\\033[0;93m* Checking for spilled placeholders:\\033[0m\"; grep -q -r \"%%_\" dist/ && echo \"Placeholders found! Stopping.\n\" && exit 1 || echo \"All OK.\n\"",
"precommit": "npm run no-spilled-placeholders"
},
Basically, grep for pattern %%_ and exit with error code if found. Don't forget to escape the code because it's JSON. I use similar (more advanced) setup in production and nothing slips through. In proper setup you should creatively look for anything mis-typed, including: %_, _%, %__, __% and so on.
Normal Go template is not supported in the markdown file, but shortcodes are:
{{< param "company.name" >}}
To access arbitrary other Go template values, create a custom shortcode for it and call that from your markdown file.
For your example, you need the site's baseUrl, so save this as layouts/shortcodes/base_url.html:
{{ .Site.BaseURL }}
And write this in your markdown file:
+++
[company]
name = "My Company"
+++
This site, {{< base_url >}} is operated by {{< param "company.name" >}}
There is also the shortcode param : {{< param "companyName" >}} : https://gohugo.io/content-management/shortcodes/#param

Export specific sections in pandoc when converting from Markdown

I have a Markdown document that was generated using Knitr (literate programming). This markdown document gets converted to Microsoft Word (docx) and HTML using pandoc. Now I would like to include specific parts from the Markdown in HTML, and others in docx. The concrete use case is that I'm able to generate JS+HTML charts using rCharts which is fine for HTML, but obviously doesn't render in docx, so I would like to use a simple PNG image in that case.
Is there some specific pandoc syntax or trick that I can use for this?
So one way to solve this is to post-process the generated markdown from knitr.
I output some mustasche and then parse that using the R package whisker.
Roughly the code looks like:
md <- knit(rmd, envir=e)
docx.temp <- tempfile()
html.temp <- tempfile()
writeLines(whisker.render(readLines(md), list(html=T)), html.temp)
writeLines(whisker.render(readLines(md), list(html=F)), docx.temp)
docx <- pandoc(docx.temp, format="docx")
html <- pandoc(html.temp, format="html")
file.copy(docx, "./report.docx", overwrite=T)
file.copy(html, "./report.html", overwrite=T)
With the Rmd (knitr) containing something roughly like
{{^html}}
```{r}
WITHOUT HTML
```
{{/html}}
{{#html}}
```{r}
WITH HTML
```
{{/html}}

Using PyMEL to set the "Alpha to Use" attribute in an object of class psdFileTex

I am using Maya to do some procedural work, and I have a lot of textures that I need to load into Maya, and they all have transparencies (alpha channels). I would very much like to be able to automate this process. Using PyMEL, I can create my textures and hook them up to a shader, but the alpha doesn't set properly by default. There is an attribute in the psdFileTex node called "Alpha to Use", and it must be set to "Transparency" in order for my alpha channel to work. My question is this - how do I use PyMEL scripting to set the "Alpha to Use" attribute properly?
Here is the code I am using to set up my textures:
import pymel.core as pm
pm.shadingNode('lambert', asShader=True, name='myShader1')
pm.sets(renderable=True, noSurfaceShader=True, empty=True, name='myShader1SG')
pm.connectAttr('myShader1.outColor', 'myShader1SG.surfaceShader', f=True)
pm.shadingNode('psdFileTex', asTexture=True, name='myShader1PSD')
pm.connectAttr('myShader1PSD.outColor', 'myShader1.color')
pm.connectAttr('myShader1PSD.outTransparency', 'myShader1.transparency')
pm.setAttr('myShader1ColorPSD.fileTextureName', '<pathway>/myShader1_texture.psd', type='string')
If anyone can help me, I would really appreciate it.
Thanks
With any node, you can use listAttr() to get the available editable attributes. Run listAttr('myShaderPSD'), note in it's output, there will be two attributes called 'alpha' and 'alphaList'. Alpha, will return you the current selected alpha channel. AlphaList will return you however many alpha channels you have in your psd.
Example
pm.PyNode('myShader1PSD').alphaList.get()
# Result: [u'Alpha 1', u'Alpha 2'] #
If you know you'll only ever be using just the one alpha, or the first alpha channel, you can simply do this.
psdShader = pm.PyNode('myShader1PSD')
alphaList = psdShader.alphaList.get()
if (len(alphaList) > 0):
psdShader.alpha.set(alphaList[0])
else:
// No alpha channel
pass
Remember that lists start iterating from 0, so our first alpha channel will be located at position 0.
Additionally and unrelated, while you're still using derivative commands of the maya.core converted for Pymel, there's still some commands you can use to help make your code read nicer.
pm.setAttr('myShader1ColorPSD.fileTextureName', '<pathway>/myShader1_texture.psd', type='string')
We can convert this to pymel like so:
pm.PyNode('myShader1ColorPSD').fileTextureName.set('<pathway>/myShader1_texture.psd')
And:
pm.connectAttr('myShader1PSD.outColor', 'myShader1.color')
Can be converted to:
pm.connect('myShader1PSD.outColor', 'myShader1.color')
While they may only be small changes, it reads just the little bit nicer, and it's native PyMel.
Anyway, I hope I have helped you!

Resources