According to the documentation here, it looks like there are 16 COLOR_ATTACHMENTS that we can use in webgl2. However, when I print:
console.log(gl.getParameter(gl.MAX_COLOR_ATTACHMENTS));
It returns 8 in the console.
I've search on the internet to learn whether or not there is an extension allowing us to use 16 COLOR_ATTACHMENTS, but I could not find any. Does anyone know what is the problem here?
Thank you in advance.
The documentation you linked to does not say there are 16 color attachments. It just lists constants for 16. How many you actually get is GPU/driver/browser dependent.
According to the spec section 6.2 page 272, 4 is the minimum required by WebGL2, some devices support more than 4. Checking WebGLStats it looks like the most supported is 8.
Note: According to the creator of WebGLStats the reason that there's a tiny percentage reporting only 1 is because some webpages sharing their stats either by their browser or other reasons are falsely claiming WebGL2 support when they don't actually support it.
Related
Running into an issue when using EncodeForHTML for certain characters (Emojis in this case)
The text in this case is:
⌛️a😊b👍c😟 💥🍉🍔 💩 🤦🏼♀️🤦🏼♀️🤦🏼♀️ 😘
Now if I just a straight output
<cfoutput>#txt#</cfoutput>
It displays correctly, no issues, but if I use EncodeForHTML first
<cfoutput>#EncodeForHTML(txt)#</cfoutput>
I get this
⌛️a��b��c�� ������ �� ����♀️����♀️����♀️ ��
I tested it with EncodeForXML & esapiEncode as well to be sure; all are giving me the same result.
I've verified the encoding settings in Lucee are UTF-8, and the meta charset tag is also set to UTF-8. I can't find any documenation re: EncodeForHTML saying if it make any changes to the character encoding, if it requires the character encoding to be something specific, or if it has any known issues with emojis or certain code points.
I appreciate any help or clarification anyone can provide.
Edit: Thank you everyone. Wish I could accept multiple answers.
I was required to sanitize emojis in order ensure that third-party content was cross-compatible with external services. Some of the content contained emojis and was causing export/import problems. I wrote a ColdFusion wrapper for the emoji-java library to identify, sanitize and convert emojis.
https://github.com/JamoCA/cf-emoji-java
For example, the parseToAliases() function "replaces all the emoji's unicodes found in a string by their aliases".
emojijava = new emojijava();
emojijava.parseToAliases('I like 🍕'); // I like :pizza:
To "encode" you could use either the parseToHtmlDecimal() or parseToHtmlHexadecimal() functions prior to using EncodeForHTML().
emojijava = new emojijava();
test = emojijava.parseToHtmlDecimal('I like 🍕'); // I ❤️ 🍕
EncodeForHTML(test);
At the time of this writing, ColdFusion's latest version is 2018 update 9
In turn, it uses ESAPI 2.1.1
Recent release notes don't mention Emoji,
https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation
But they do mention in Pull request 413
"Fixing ESAPI's inability to handle non-BMP codepoints."
This dates from 2017
https://github.com/ESAPI/esapi-java-legacy/pull/413
So based on all this information, I would recommend doing both of the following
Try using ESAPI directly. This is how it was done before ESAPI was added to CF. This issue may or may not still exist in ESAPI
Put in a ticket with Adobe to update this library.
Yes, ESAPI 2.2.0.0 addressed the issue of not correctly encoding non-BMP characters (see https://github.com/ESAPI/esapi-java-legacy/issues/300) as part of PR #413 that James mentioned above.
But I just uploaded release ESAPI 2.2.1.0-RC1 (release candidate 1) to Maven Central early this morning and hope to have an official 2.2.1.0 release out by next weekend, so if you are going to put in a ticket with Adobe for fix this with an updated version of ESAPI, I'd wait another week and then tell them to update to 2.2.1.0.
I am trying to use the Amatic Font from Google in my PDF File but it gives me an Error like below. Could that be because the Font Type? I have tested with Open Sans and it is working.
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught exception
'Zend_Pdf_Exception' with message 'Unable to read version 4 table' in
/var/www/vhosts/httpdocs/main/zend/library/Zend/Pdf/FileParser/Font/OpenType.php:555\nStack
trace:\n#0
/var/www/vhosts/httpdocs/main/zend/library/Zend/Pdf/FileParser/Font/OpenType.php(121):
Zend_Pdf_FileParser_Font_OpenType->_parseOs2Table()\n#1
/var/www/vhosts/httpdocs/main/zend/library/Zend/Pdf/FileParser/Font/OpenType/TrueType.php(83):
Zend_Pdf_FileParser_Font_OpenType->parse()\n#2
/var/www/vhosts/httpdocs/main/zend/library/Zend/Pdf/Font.php(701):
Zend_Pdf_FileParser_Font_OpenType_TrueType->parse()\n#3
/var/www/vhosts/httpdocs/main/zend/library/Zend/Pdf/Font.php(615):
Zend_Pdf_Font::_extractTrueTypeFont(Object(Zend_Pdf_FileParserDataSource_File),
0)\n#4 /var/www/vhosts/httpdocs/main/zend/invoice.php(27):
Zend_Pdf_Font::fontWithPath('/var/www/vhosts...')\n#5 {main}\n\nNext
exception 'Zend_Pdf_Exception' wi...\n'
I am using this Script for my tests https://github.com/phpmasterdotcom/GeneratingInvoicesWithZendPdf/blob/master/public/invoice.php
What's happening is this: The Zend Framework code in OpenType.php explicitly checks the OS/2 table version of the font. Is it higher than 3, an exception is thrown. Your font has an OS/2 table version of 4 (which is the fifth version, there are at least 6 versions as far as I know).
Unfortunately, recent versions of the ZendPdf module (like here on GitHub) still don't seem to support version 4 or higher. So apart from looking for another pdf generator - that does support version 4 - I fear there's no clean solution.
You could try editing the framework code, but of course that's a bit shady. As an alternative, apparently it should be able to change that version and regenerate the font. See this post on the Tex forum (the post AFTER the accepted answer). If you choose that path, probably you'll find better guidance on that forum.
Sorry I can't offer a better solution, but maybe it helps you understanding what's going on.
I am using ActiveReports 2.0 (Visual Basic 6.0). Is it possible to implement this functionality:
Mix code sets in the 128 bar code.
I need to encode a USPS tracking number. Following is an example of the same:
CJ123456789US as Code 128B: "CJ1″
then shift to Code 128C: "23456789″
then shift to Code 128B: "US"
Unfortunately, it is not supported as of now. However, it has already been been forwarded to the concerned team as an enhancement request.
You may refer to the following forum post for further follow up:
http://our.componentone.com/groups/topic/how-to-define-character-sets-to-mix-in-code-128-barcodes-5/
Regards,
Mohita
I have 2 servers which I though were synchronized (dev and live) but the "News System" (extension key "news") makes something different.
In the dev server this line
<f:format.date format="%A">{newsItem.datetime}</f:format.date>
outputs "Freitag", as expected (Thats friday in German)
But in the Live Server, it outputs %AM. Which is even weirder is that l (alone, without %) outputs "Friday" in English.
I've checked all the configurations I've seen and I cant seem to find where the difference between the systems is.
Any idea?
TYPO3 is using DateTime::format (http://de2.php.net/manual/en/datetime.format.php) to format the date. This method is using the same syntax of date() which is not using locales, so all output is english.
The only thing I can not explain is why your dev enviroment accepts %A to render the date. Are there different PHP-Versions? Which TYPO3 Version are you using? Get a look at /typo3/sysext/fluid/Classes/ViewHelpers/Format/DateViewHelper.php, you will get the answer there.
I just solved it! Turns out I had 4.7.7 in my live server, and that doesnt support stftime.
Funny, I never thought that such an important feature would be added in an 4.7.X update...
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.