I have a use-case involving Arabic text in a game, with custom font. I am currently using the createWithTTF API call, and selecting the Font file that I would need.
However, since Arabic is a Right to Left(RTL) language instead of a Left to Right(LTR) language, the texts are getting printed incorrectly. Apparently, the best solution for this is to use the createWithSystemFont API call. However with this call, I would not be able to use a custom font and I would have to resort to a system font.
Is there any way that you guys know in Cocos2DX to use a custom font, with Arabic text? I did look into this Github issue. I tried the Arabic Writer out, but this gives glitchy output in certain cases. I know that editing the source JSON/Plist file is an option, and I have tried using reversed Arabic strings in the source. However, since Arabic is a language that has combined characters, the result that I get on my UI is not 1:1 with the expected result, and some characters are disjointed(which are supposed to form a special character after getting merged).
Looking for suggestions on how to tackle this. I have looked into almost all open threads related to this, and could not find anything conclusive. Thanks!
I wrote a fix for the Persian language. It works for Arabic as well but you may need some Arabic only characters to it. (Might need some editing)
https://github.com/MohammadFakhreddin/cocos2dx-persian-arabic-support
I have a product on Microsoft store (PowerBI Tiles), that use the api powerbi.js from Microsoft to get visuals from logged-in user.
When I try to open the application using PowerPoint online on Firefox, we got some problems.
"The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature."
My team try to solve the problem on our side, but we detect that the problems doesn't come from our code, but from powerbi.js (Microsoft code). Even the demos from Microsoft doesn't work on Firefox.
We create two animated gifs reproducing the problem (on our application and also on the demos from Microsoft)
Microsoft Demos - Running on Firefox
PowerBI Tiles - Running on Firefox
Anyone with this kind of problem? Any solution to this problem.
Many thanks.
João
When using the CiviMail WYSIWYG to compose a mailing, clicking the image insert option and then choosing "browse server", then uploading an image and inserting it - results in a broken image in the sent email because it uses a relative URL for the image.
Given that this is CiviMail and its sole purpose is to send out mailings, it seems like this behavior should be gleaned and replaced prior to sending? Is there an extension or way to configure it to fix this? I recall this being an issue previously, but had thought this was resolved for 4.5. Anyone know if there is a way to configure without jumping into the wysiwyg's direct code and overriding?
the editor is used in multiple locations besides civimail
Might want to check see if the wysiwyg editor has a setting that decides between relative vs absolute urls. might want to tweak that setting and see if it fixes things
I was wanting to do something like this for a PDF
http://www.ixian.co.nz/mainzeal/mainsite/Dec2010.html
But that service appears to be a paid for solution. I was wondering if there is anything out there open source that can do the same thing? I.e I give it a PDF and it can turn it into a browsable book, like the above, complete with page flip effect
Take a look at FlexPaper Zine
http://flexpaper.devaldi.com/flexpaper_flip_zine.jsp
Well, didn't find much aside from scribd.com which is obviously not the same thing.
I'm increasingly becoming aware that there must be major differences in the ways that regular expressions will be interpreted by browsers.
As an example, a co-worker had written this regular expression, to validate that a file being uploaded would have a PDF extension:
^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$
This works in Internet Explorer, and in Google Chrome, but does NOT work in Firefox. The test always fails, even for an actual PDF. So I decided that the extra stuff was irrelevant and simplified it to:
^.+\.pdf$
and now it works fine in Firefox, as well as continuing to work in IE and Chrome.
Is this a quirk specific to asp:FileUpload and RegularExpressionValidator controls in ASP.NET, or is it simply due to different browsers supporting regex in different ways? Either way, what are some of the latter that you've encountered?
Regarding the actual question: The original regex requires the value to start with a drive letter or UNC device name. It's quite possible that Firefox simply doesn't include that with the filename. Note also that, if you have any intention of being cross-platform, that regex would fail on any non-Windows system, regardless of browser, as they don't use drive letters or UNC paths. Your simplified regex ("accept anything, so long as it ends with .pdf") is about as good of a filename check as you're going to get.
However, Jonathan's comment to the original question cannot be overemphasized. Never, ever, ever trust the filename as an adequate means of determining its contents. Or the MIME type, for that matter. The client software talking to your web server (which might not even be a browser) can lie to you about anything and you'll never know unless you verify it. In this case, that means feeding the received file into some code that understands the PDF format and having that code tell you whether it's a valid PDF or not. Checking the filename may help to prevent people from trying to submit obviously incorrect files, but it is not a sufficient test of the files that are received.
(I realize that you may know about the need for additional validation, but the next person who has a similar situation and finds your question may not.)
As far as I know firefox doesn't let you have the full path of an upload. Interpretation of regular expressions seems irrelevant in this case. I have yet to see any difference between modern browsers in regular expression execution.
If you're using javascript, not enclosing the regex with slashes causes error in Firefox.
Try doing var regex = /^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$/;
As Dave mentioned, Firefox does not give the path, only the file name. Also as he mentioned, it doesn't account for differences between operating systems. I think the best check you could do would be to check if the file name ends with PDF. Also, this doesn't ensure it's a valid PDF, just that the file name ends with PDF. Depending on your needs, you may want to verify that it's actually a PDF by checking the content.
I have not noticed a difference between browsers in regards to the pattern syntax. However, I have noticed a difference between C# and Javascript as C#'s implementation allows back references and Javascript's implementation does not.
I believe JavaScript REs are defined by the ECMA standard, and I doubt there are many differences between JS interpreters. I haven't found any, in my programs, or seen mentioned in an article.
Your message is actually a bit confusing, since you throw ASP stuff in there. I don't see how you conclude it is the browser's fault when you talk about server-side technology or generated code. Actually, we don't even know if you are talking about JS on the browser, validation of upload field (you can no longer do it, at least in a simple way, with FF3) or on the server side (neither FF nor Opera nor Safari upload the full path of the uploaded file. I am surprised to learn that Chrome does like IE...).