I've updated my TYPO3 website from 4.1 to 6.2.9. Now the Umlauted Characters [German Letters] are not shown properly. Is there any Idea to fix that.
I experienced similar troubles when upgrading from 4.1 to 4.2. The following paragraphs are notes from my blog. Hope it helps.
Updating from TYPO3 4.1 (and earlier versions) to 4.2 (and later)
Some DB fields in 4.1 are of type BLOB (for example the TS templates). Most of these fields get converted to TEXT in 4.2. Now think about the following scenario, which seems to be common. The template was saved using TYPO3 4.1 and a DB using latin1 (ISO-8859-X) as charset. Then the DB converted to UTF-8 and TYPO3 was configured accordingly. You think you're finished because everything works will. But in most cases, there's still some latin1 formatted data in the BLOB fields. You just don't see. Once you upgrade TYPO3 to 4.2, these BLOBs get converted to TEXT, assuming the data is UTF-8. But it's latin1, because BLOB was not converted before. The result is a broken template. Lots of people in the mailing lists complain about whole parts missing. The reason is invalid non ascii characters (like umlauts äöüé¢ etc), which break the template view.
How to avoid that?
If you change the charset of TYPO3 and/or your DB, convert those BLOB fields which would have been changed by the TYPO3 update to TEXT before converting the charset or make sure to convert the BLOB data otherwise.
More about UTF-8 and older versions of TYPO3: https://stmllr.net/blog/thinking-about-utf-8-character-set-conversion-in-typo3/ Creative Commons License CC BY-SA 3.0
Related
Using body.getOoxml() in an add-in for Word 2016 does not include the numbering package part. This leads to errors when executing insertooxml() since the API creates new numbering definitions which are wrong or default to the standard (as 1,2,3 etc.). Hence numberings that have other logic, like lower letters or roman letters, will be set back to the standard on executing insertooxml().
This applies to Word 2016 MSO which still uses IE 11 in add-ins. (nothing we can do about that).
In Word for M365 it works correctly.
The Word version in use is 16.0.5369.1000 MSO 16.0.5366.1000 32-Bit (Running on Windows 10)
We currently use Office-js version 1.1.82 (the newest 1.1.83-custom.0 has a bug that throws an exception on insertooxml in Word 2016)
We need this for our solution which removes sensitive data from word documents. Since Word Js Api 1.1 does not include hyperlinks, we need to operate on ooxml to fix hyperlinks as well.
Steps to recreate:
Create a new word document
Add one or two titles
Change title numbering to "a,b,c"
Execute the following code in an add-in:
var body = context.document.body;
var body_ooxml = body.getOoxml();
await context.sync();
var body_ooxml_value = body_ooxml.value;
body.insertOoxml(body_ooxml_value, Word.InsertLocation.replace);
await context.sync();
What I expected:
The content of the document should remain the same. Without any changes to the numbering
current findings
I made several tests and found out that in Word 2016 MSO, getOOXML does not return the numbering - even though the file numbering.xml exists and is correct. After executing insertOoxml it seems as if the api is trying to re-create the numbering from scratch which leads to an overwrite in numbering.xml that includes standard numbering (1,2,3).
I don't see a workaround (but would be happy for any advice).This seems to be a product bug and needs to fixed.
Just FYI, in case you didn't know: Microsoft no longer requires support for IE in add-ins that are distributed through AppSource. That said, it does seem to be a bug, so you could create a bug issue on the office-js repo. But I don't think a bug in an Office version that old will have a high priority.
I'm trying to add the alternate text into my images just as the Apache FOP documentation instructs: By using fox-alt:-text.
<fo:external-graphic src="logo.gif" content-width="75%" content-height="75%" fox:alt-text="My company logo"/>
I'm using Apache FOP version 2.5 and accessibility is ON (setted true in fop.xconf). For some reason I'm getting an error message saying
org.xml.sax.SAXParseException:cvc-complex-type.3.2.2: Attribute 'fox:alt-text' is not allowed to appear in element 'fo:external-graphic'.
Any ideas on what might be wrong?
I now realized that the problem is not in Apache FOP but it's in my code. Our system is doing some additional schema validation (javax.xml.validation.Validator) against the plain fo schema and doesn't see the fox extension.
fox:alt-text is not a part of the original fo schema's fo:external-graphic definition and is causing validation failures.
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.
In MATLAB I used to go:
info = imfinfo('image.jpg');
iso = info.DigitalCamera.ISOSpeedRatings;
And that's it. Octave has an imfinfo function that reads many parameters from the image header, but apparently not the ISO speed. That looks strange to me (why would it read dozens of params and let out ISO speed?).
Is there something I am missing?
Example image is here, shot with a DSLR (as you can see with imfinfo). With MATLAB, I can clearly see that imfinfo('image.jpg').DigitalCamera.ISOSpeedRatings is 200.
tl;dr
The value you want is under the field PhotographicSensitivity. Use:
iso = imfinfo ("image.jpg").DigitalCamera.PhotographicSensitivity;
See Octave bug #47706.
Octave only considers tags that follow Exif version 2.3.
Workaround
Old versions of the Octave image package had a function readexif (the function was deprecated in image package version 2.2.0 and removed in version 2.4.0) which may be able to read them. The last version to include that function was 2.2.2
Discussion
The details you are accessing are the EXIF values on your image file. Basically, there's a table on your file that maps tags, such as ExposureTime or FNumber, to their actual values. However, the tag names are not encoded in the file. Instead, each tag has an integer value e.g., ExposureTime or FNumber will appear as 33437 and 33434 respectively. It's the job of a program/library to map those integer values to the tag name.
The tag you are looking for, ISOSpeedRatings is not a valid EXIF tag per the EXIF specs version 2.3 (the latest specs, released in 2010). It was renamed to PhotographicSensitivity. If you read the specs under that tag, you will find this note:
Note that this tag was referred to as “ISOSpeedRatings” in versions of this standard up to Version 2.21.
If you read even more of the specs, you will find the following explanation on Annex G:
[...] the PhotographicSensitivity tag whose ID was 34855 was previously referred to as ISOSpeedRating, which, in reality, led to confused interpretations of sensitivity that resulted in many recordings that differed from ISO speed as defined under the ISO 12232 standard.
And if you read even more of the specs, you will notice that the meaning of the value with the tag 34855 was slightly changed when its name changed. This means that it's not only a tag name issue, its meaning is different if your camera follows a different version of the EXIF specs (assuming that your camera recorded it correctly, remember that the reason for the change was that cameras were recording the wrong thing).
I'm not sure what is the right technical answer. I'm guessing a program should check the recorded ExifVersion (which is the EXIF tag 36864) and change the tag names according to that.
Edit
Octave uses GraphicsMagick to read images, including its metadata. GraphicsMagick does not accept the EXIF tag numbers, programs need to query using the tag names. Octave then has a hardcoded list of tag names but only includes the tags for Exif specs 2.3. It seems that GraphicsMagick recognizes your file is an older version of Exif and names the tag old way which Octave does not ask for.
I did the following and can now use readexif from 2.2.2 in image 2.6.1:
Download Image 2.2.2 as suggested earlier in this thread
Add the readexif.m from Image 2.2.2 among image 2.6.1
Reload package pkg load image
Now you can call readexif. To get ISOSpeedRating:
readexif(JPGPath).Exif_IFD_Pointer.ISOSpeedRatings
If I load an xlsx file that already has a filter, and then save the file using GemBox, it seems to throw my filtering cell away. Does GemBox support filtering at all? I know I can load the file in preserved mode but my intention is to create the filter in my C# app.
EDIT 2015-06-15:
The newer version of GemBox.Spreadsheet (version 3.9) does have an API support for filters, see the version history page. Also, you can find here an Excel AutoFilter example.
ORIGINAL ANSWER:
Unfortunately, in the current version (3.5) GemBox.Spreadsheet supports filtering only through preservation.