This week we upgraded to JasperReports Server 4.7 (Professional) and iReport 4.7. I have several reports that I created in iReport 4.5.1 and successfully used in JasperReports Server 4.5.1.
After the upgrade, all of my dollar signs are now little boxes. The pattern for my currency fields is ¤ #,##0.00. JasperReports Server is not replacing the box with a dollar sign when the report is generated. Everything looks ok in the pattern sample. My percentage symbols are all still working. I tried removing and applying the currency pattern to the fields again, but this didn't fix the problem.
Any thoughts on how I can fix this?
This is Java operating as intended... but not as you want it to operate. Your locale does not specify a currency, so you get that "¤" symbol.
You could workaround it by changing your locale from "en" to "en_US". I just did this last week. As a side note, I found one tweak that I needed to make. After changing the locale to en_US I needed to copy one file like this:
cp .../jasperserver-pro/scripts/jquery/js/jquery.ui.datepicker-en.js .../jasperserver-pro/scripts/jquery/js/jquery.ui.datepicker-en-US.js
Alternatively, I usually find it's better to work around it by setting your format mask to use a hard-coded dollar sign. If you are displaying "$50.00" to a user in the United States, it would be nonsensical to display "€50,00" to a European user or "¥50.00" to a Japanese user for the same value. There are lots of times when the hard-coded currency symbol is more appropriate.
Related
In Qt5, the MMM format, which displays the month name in a short format (e.g., "Dec" instead of "12" or "December"), when using it for the Spanish locale, shows the abbreviated month name with a dot at the end, for example, for, "25th December 2016", in MMM/dd/yyyy format, shows "Dic./25/2016".
The problem is when editing. For displaying a date, it's ok, since it's what the Spanish rules say, but it isn't suitable for editing. I'm forced to position the cursor just after the point, at the end of the month part, to delete the point, and then, the rest of the month name. If I try to put the cursor just before the point, to edit just the month name part, the field is in "read-only" mode. I can't not remove anything, unless I remove everything from the very right of the line and back, character to character (or just selecting the whole month part and remove everything).
Besides, the point is not autocompleted. So, if the user writes the new month forgetting the dot, the edition is rejected and fall backs to the original value.
Taking all of it into account, editing a QDateEdit is a bit cumbersome (in Spanish).
I don't know if it is the built-in QDateEdit behaviour, or internally it is using a QRegExpValidator, but in that case, I don't know what it's the regexp expression, to personalize it from it.
In short, how can I "solved" it? (the cumbersome edition; it's ok for me both, removing the dot, or changing the validation).
The Qt 5 behavior is correct and there's nothing Qt can do (or should do). The only correct and acceptable short name of December in a es_ES locale is "dic.", trailing dot included. That's what CLDR says:
http://www.unicode.org/cldr/charts/30/summary/es.html#1636
http://www.unicode.org/cldr/charts/30/verify/dates/es.html
In iTextPDF 5.5.8 for Java when creating a PDFDate in UTC timeZone, I get the following format:
(D:20160212073102Z)
Whereas in iTextSharp (older version) I get for UTC the format:
(D:20160212082328+00'00')
While Adobe Reader can handle both Versions, one of our Adobe Acrobat Signing plugins requires the first Version and can not handle +00'00' (it accepts +01'00' though).
Now my question: Does anyone know, how we could make iTextSharp produce the first Version? (D:20160212073102Z)
Thank you
The format you show for the older iTextSharp version
(D:20160212082328+00'00')
is wrong, the specification clearly says:
A PLUS SIGN as the value of the O field signifies that
local time is later than UT, a HYPHEN-MINUS signifies that local time is earlier than UT, and the LATIN
CAPITAL LETTER Z signifies that local time is equal to UT
Thus, the Z form has to be used for UTC.
Thus, you had better try and update to the current iTextSharp and test again. If there still is the wrong form, update your question accordingly. Such a bug would surely be fixed soon.
sadly, after iOS5 finally released, I got report from my users that they can not login.
Because there is emoji symbol in there names, and apple changed the encoding of emoji.
so there username contains a old version of emoji, how could I convert them to the new encoding?
thanks!
be specific: one emoji symbol "tiger", it is "\U0001f42f" in iOS5, but "\ue050" in earlier iOS version.
iOS 5 and OS X 10.7 (Lion) use the Unicode 6.0 standard ‘unified’ code points for emoji.
iOS 4 on SoftBank iPhones used a set of unofficial code points in the Unicode Private Use Area, and so aren't compatible with any other systems. To convert from this format to proper Unicode 6.0 characters, you'll need to run a big lookup table from Softbank code to Unified over all your current data and all new form data as it gets submitted. You might also want to do Unicode normalisation at this point, so that eg. fullwidth letters match normal ASCII letters.
See for example this table from a library that does emoji conversion tasks for PHP.
Emoji in usernames though?
I had the same problem, after digging for hours and finally found this answer that works for me
If you are using rails as your server, this is all you need to do. No need to do anything in ios/xcode, just pass the NSString without doing any UTF8/16 encoding stuff to the server.
Postegre stores the code correctly, it's just when you send the json response back to your ios client, assuming you do render json:#message, the json encoding has problem.
you could test whether you are having json encoding problem in your rails console by doing as simple test in your console
test = {"smiley"=>"u{1f604}"}
test.to_json
if it prints out "{\"smiley\":\"\uf604\"}" (notice the 1 is lost), then you have this problem. and the patch from the link will fix it.
HI,
[background]
We currently build files for many different companies. Our job as a company is basically to sit in between other companies and help with communication and data storage. We have begun to run in to encoding issues where we are receiving data encoded in one format but we need to send it out in another. All files were prevsiously built using the .net framework default of UTF-8. However we've discovered that certain companies cannot read utf-8 files. I assume because they have older systems that require something else. This becomes apparent when sending certain french charaters in particular.
I have a solution in place where we can build a specific file for a specific member using a specific encoding. (While I understand that this may not be enough, unfortunately this is as far as I can go at the moment due to other issues.)
[problem]
Anyways, I'm at the testing stage and I want to input utf-8 or other characters into management studio. Perform an update on some data and then verify that the file is built correctly from that data. I realize that this is not perfect. I've already tried programatically reading the file and verifying the encoding by reading preambles etc. So this is what I'm stuck with. According to this website http://www.biega.com/special-char.html ... I can input utf-8 characters by clicking ALT+&+#+"decimal representation of character" or ALT+"decimal representation of character" but when I use the data specified by the table I get completely different characters in management studio. I've even saved the file in a utf-8 format using management studio by clicking the arrow on the save button in the save dialog and specifying the encoding. So my question is how can I accurately specify a character that will end up being the character I'm trying to input and actually put it in the data that will then be put in a file.
Thanks,
Kevin
I eventually found the solution. The website doesn't specify that you need to type ALT+0+"decimal character representation". The zero was left out. I'd been searching for this for ages.
We are using Firebird as our database. How do we go about storing currency symbols in the database, which character set should we use or what is generally best practice?
For example storing "$" or "¥" appears straight forward, but more complex symbols do not appear correctly in the database table, i.e. "₡" will not store in the database.
What is generally accepted as "best practice" for this kind of thing.
Let me specify that the language we are using is C#. I suspected that UTF8 would be the answer, but how do we go about storing the character in the database, do we use the Unicode, Hex or Decimal equivalent, or do we simply use the character?
Issues with this approach
If you need to output currency text, I would recommend that you do not store the currency symbol associated with the currency data. Even if the symbol is stored in another column and you pull it out as needed. Rather a better approach would be to store the region / locale for the currency data then, format the currency using the regions default formatting. If whatever language/platform you are using doesn't have locale based currency functionality, I still think this is a better approach. In that case, you would do the formatting in a bit of application logic and then display it to the user.
The main reasoning being this is that in different regions and locales not only is the symbol different, but so is the placement of the symbol and the formatting of the currency itself. Also think if you need to distinguish between different types of dollars - maybe at some point you will want to indicate if the dollar amount is in USD, HKD, AUD, etc.
Currency examples
1.234,56€ - Euro (Germany)
€ 1.234,56 - Euro (Netherlands)
€ 1,234.56 - Euro (Ireland)
123,456円 - Yen (Japan)
123,456￥ - Yen (Japan) - yes there are two different currency marks!
Other resources
I found a good article on the MSDN site on currency globalization that helps to better explain the problem.
Here is site on the different formats per locale that for the Euro.
I would point to two main pitfalls:
First, make sure your database is correctly installed as utf-8. Some database force you to chose this at install time, others at schema/user creation time.
Second, make sure the programming language you use supports utf-8. php is especially known to cause problems whith string manipulation and utf-8.
The create database statement for firebird looks as the following:
Make sure you use at least version 2.0 of firebird, the first version to support utf-8.
CREATE DATABASE <database>
USER <username>
PASSWORD <password>
PAGE_SIZE <pagesize>
DEFAULT CHARACTER SET UTF8
Alternatively you can create a single field with
CREATE TABLE money (
SYMBOL VARCHAR(50) CHARACTER SET UTF8 )
Edit: To clarify on what to store: you store exactly the characters as they appear on the screen. Most likely you can just cut/paste them from any program to your database or inside a sql statement. No need to fumble around with conversions to int/hex/oct/ascii whatsoever.
Edit2: Of course you do not store the fully formatted number, but rather only the single currency symbols.
It may also be a Font issue, some Fonts do not have all rare utf-8 characters. For example Arial is missing it. "Lucida Sans Unicode" definately has it. Try setting "Lucida Sans Unicode" in your viewing program.