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
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 use Python for plotting geospatial data on maps.
For certain map-styles, such as ["basic", "streets", "outdoors", "light", "dark", "satellite", "satellite-streets"], I need a mapbox-access token and for some geospatial plotting packages like folium I even need to create my own link for retrieving the map-tiles.
So far, it worked great with the style "satellite":
mapbox_style = "satellite"
mapbox_access_token = "....blabla"
request_link = f"https://api.mapbox.com/v4/mapbox.{mapbox_style}/{{z}}/{{x}}/{{y}}#2x.jpg90?access_token={mapbox_access_token}"
However, when choosing "satellite-streets" as mapbox-tile-ID, the output doesn't show a background map anymore. It fails with inserting "satellite-streets", "satellitestreets" and "satellite_streets" into the aforementioned link-string.
Why is that and how can I come to know what's the correct tile-ID-name for "satellite-streets"?
I found an answer when reaching out to the customer support.
Apparently, one has to access the static APIs which have specific names listed on their website:
"In general, the styles that you mentioned including
"satellite_streets" that you are referencing are our classic styles
that are going to be deprecated starting June 1st. I would recommend
using our modern static API the equivalent modern styles. This
will allow you to see the most updated street data as well.
Like the example request below:
https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v11/tiles/1/1/0?access_token={your_token}
Here is more info on the deprecation of the classic styles and
the migration guide for them."
My personal adaptation after having tried everything out myself, is:
Via combining the above-mentioned with the details on how to construct a Mapbox-request link on this documention from mapbox' website,
I finally managed to make it work.
An example request looks like so (in python using f-strings):
mapbox_tile_URL = f"https://api.mapbox.com/styles/v1/mapbox/{tileset_ID_str}/tiles/{tilesize_pixels}/{{z}}/{{x}}/{{y}}#2x?access_token={mapbox_access_token}"
The tileset_ID_str could be e.g. "satellite-streets-v11" which can be seen at the following link containing valid static maps.
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.
My apologies if the question is duplicated. We are facing an issue with the analysis of a profile using Watson Personality Insights API in Spanish. We have a demo we implemented using PI API version 2 and then we tested the results (exact same text) with the demo published on developer cloud(in spanish) and we found important differences on how the big five were calculated when the facet values were not that different. Is it possible that these differences are caused because of the API version? The issue that with our demo the big five values produced a kind of negative summary profile when the developercloud summary is kinder.
We could send both result jsons. For example here is how the big five rated:
BigFive DeveloperCloud Demo V2
Openness 0.773834349 0.847273232
Conscientiousness 0.916616088 0.914907481
Extraversion 0.796331544 0.612606551
Agreeableness 0.17445636 0.096118648
Emotional range 0.036287447 0.01623536
thanks in advance!!
So the API version would not make a difference, as that just governs the format of the API; the back-end models are the same for both v2 and v3 of the API.
So the jist of your question is that when you run the same text in your app, and in the demo you get different big5 results, while the facet values are about the same.
This might be easiest solved by you opening a support ticket so we can debug the issue together; if you'd rather not do that then can you provide a sample text? Typically it boils down to a difference in the way the text is parsed.
Another question; did you try making the request using curl? That would cut out any custom logic in your app and narrow down the problem.
thanks Neil for you answer!
We tested the text using CURL and we noticed that the results didn't change by the service version used but instead by how the text was sent. If we called the service using curl passing a plain text input(formatted in UTF-8 with line breaks) it returned the same results for version2 and version 3 and also matched the ones from our demo. If we called the service using curl passing json input WITHOUT line breaks it returned the same values as well. But if we called the service passing the json input WITH line breaks then the results changed and almost matched those shown by ibm demo. My question here is which are the correct results? The ones shown when the text is sent as a plain text input(with line breaks) or when the text is sent as json input(with line breaks)? Is there any technical guideline besides the one shown in developercloud on how the text should be parsed to use this service?
Thanks again!
Currently I'm using this markdown text inside the README.md file of a project on GitHub:
See the docs of [testthat][3] on how to write unit tests.
Links
-----
- http://www.rstudio.com/products/rpackages/devtools/
- https://github.com/hadley/testthat
- http://r-pkgs.had.co.nz/tests.html
---
[1]: http://www.rstudio.com/products/rpackages/devtools/
[2]: https://github.com/hadley/testthat
[3]: http://r-pkgs.had.co.nz/tests.html
I don't like this duplication, but I don't see what choice I have. If I remove the explicit bullet point lists, then GitHub won't display the reference links. If I remove the reference links, then GitHub shows the bullet point list (of course), but the embedded links like "testthat" above don't work.
Is there a better way than duplicating? What am I missing?
Inspired by #mb21, I suppose this would be the right way to do it:
See the docs of [testthat][2] on how to write unit tests.
Links
-----
- [RStudio Devtools][1]
- [testthat][2]
- [More unit test examples][3]
[1]: https://stackoverflow.com/users/214446/mb21
[2]: https://github.com/hadley/testthat
[3]: http://r-pkgs.had.co.nz/tests.html
That is, it's not a good practice to include links verbatim and without a meaningful title. I should keep the link URLs only in the reference links section at the bottom, and in the bullet point list use meaningful titles.
When you view this on GitHub, the URLs shouldn't really matter, and if you really want to know you can move the mouse over. When you view this in plain text, now the links have meaningful titles, which is useful additional information about the URLs.
I'd write that as follows:
See the docs of [testthat][1] on how to write unit tests.
Links
-----
- [RStudio Devtools](http://www.rstudio.com/products/rpackages/devtools/)
- [Testthat](https://github.com/hadley/testthat)
- [Tests][1]
[1]: http://r-pkgs.had.co.nz/tests.html
Did that answer your question? If not, you'll have to clarify it.
An answer from 8 years in the future!
The answer to your question will depend on what your Markdown parser supports. Nowadays, most parsers support CommonMark (plus some flavouring). However, don't take this for granted and double check it. If CommonMark is not supported, try using the "vanilla" Markdown syntax as described below. Just be aware that the "vanilla" Markdown specification is flawed and may result in broken links (by design, almost).
Using CommonMark
If you can guarantee that your Markdown parser supports CommonMark, then you can do it in a simple way:
Writing unit tests is explained in the [Unit Testing] website
[Unit Testing]: https://unittesting.somedomain.com
In the Links section of the CommonMark specification (currently at version 0.30) you see that a "link" is composed of a link text, link destination and a title and each one has its own syntax and quirks. For example, if the link destination contains spaces, you need to wrap it in <angled brackets>, or if your link text is some kind of code, you're allowed to write
[`AwesomeClass`](<../docs/awesome class.md>]
Note:
In this section I am using the CommonMark syntax, so you can click the
"Edit" button to see the syntax that I used for a "real" example.
Using vanilla Markdown
The vanilla Markdown specification simply requires an extra set of angled brackets with nothing in between, as described in the links section.
Writing unit tests is explained in the [Unit Testing][] website
[Unit Testing]: https://unittesting.somedomain.com
Note
And in this section I've only used vanilla Markdown syntax. Stack Overflow's Markdown parser supports both CommonMark and vanilla Markdown. This is not by accident, since CommonMark intends to be compatible with the original specification (wherever possible!). Stack Overflow do state that they use the CommonMark spec in their Markdown help page.
Tl;dr
See the docs of [`testthat`] on how to write unit tests.
Links
-----
- [RT Studio dev tools]
- [`testthat`]
- [R Packages]
---
[RT Studio dev tools]: http://www.rstudio.com/products/rpackages/devtools/
[`testthat`]: https://github.com/hadley/testthat
[R Packages]: http://r-pkgs.had.co.nz/tests.html