On Aspose.Total for .NET|Documentation you are saying that dates and numbers are formatted according to the current thread culture.
How do you create the date when the document should contain the long date formats with weekdays and months as word (e.g.“September”) instead of the numbers (9.) in the short date format? Are you using .NET mechanisms or custom built code?
Do you support any thread culture or only specific cultures?
Ernst
Hi
Thanks for your inquiry. Aspose.Words uses .NET to format values of fields. So you can use any culture in your thread.
The following format switch will output date in long format:
{ DATE \@ "dddd, MMMM dd, yyyy" }
Best regards,
Hi Alexey,
IMO using the thread culture is not a good choice for rendering files in Aspose.Words. Microsoft Word has a different approach: It uses the language of the field and text in the document, regardless of the currenct culture or UI culture. This supports having date fields for multiple languages in a single document, which is very important for globalized applications!
We need Aspose.Words to render exactly as Word does. Using the thread culture here is a bug in Aspose.Words from this perspective.
Can you change the behavior in Aspose.Words accordingly so it behaves like Microsoft Word?
Regards, Ernst
PS: Excel has another approach and uses the culture from the current user, since there is no language stored in the excel file format.
Hi Ernst,
Thank you for additional information. I logged your request into our defect tracking system. Your request has been linked to the appropriate issue. You will be notified as soon as it is resolved.
Best regards,
Hi!
Any news on this issue?
Regards Christian
Hello
Thanks for your request. Unfortunately, the issue is still unresolved. I will let you know once there is something new regarding this issue.
Best regards,
A fix for the issue(s) you've reported (filed as WORDSNET-4241) will be included into the next release at the end of this month.You will be notified.
The issues you have found earlier (filed as WORDSNET-4241) have been fixed in this .NET update and in this Java update.
Hi Christian,
Regarding the fix for your issue, we introduced a new option under the class Document.FieldOptions. You can now use this to set the culture used during field update.
doc.FieldOptions.FieldUpdateCultureSource = FieldUpdateCultureSource.FieldCode;
Thanks,
Hi,
Thank you for the work on that so far. We are now using this property.
However this is still working only partially. When looking at the conversion of the attached file “Language and Field Codes.xml” and its corresponding output PDF the field “NumPages” does not get converted according to the language.
This seems to have something to do with the format of the field (“1st2nd, 3rd”, “1, 2, 3”).
As you can see in “Numpages_AllFormats.xml” and its corresponding output PDF some of the field are working as expected while others are not.
This is also working only partially for the field function “SectionPages” as you can see in the attached files.
This should also work for field functions in all possible stories of a Flat-OPC-document (Different headers, footers (odd, even, first), headers in different sections, Textboxes, Comments etc.)
We are using Aspose.Words 16.2 for converting the documents to PDF.
Kind regards
Hi Markus,
Thanks for your inquiry. We have logged the following issues in our bug tracking system.
WORDSNET-13715: against Language+and+Field+Codes.xml
WORDSNET-13716: against Numpages_AllFormats.xml
WORDSNET-13717: against SectionPages_AllFormats.xml
Your thread has also been linked to the appropriate issues and you will be notified as soon as they are resolved. Sorry for the inconvenience.
Best regards,
Hi,
Are there any news on the topic? Can you predict when this will be fixed?
Kind regards
Hi,
Thanks for your inquiry. All of these issues have now been resolved and their fixes will be included in next version of Aspose.Words i.e. 16.7.0. We will inform you via this thread as soon as next version will be released at the start of next month.
Best regards,
Hi,
Regarding WORDSNET-13715, it is to inform you that after when 16.7.0 version of Aspose.Words will be released, you should use the FieldUpdateCultureSource.FieldCode option to get the desired output.
Best regards,
The issues you have found earlier (filed as WORDSNET-13715;WORDSNET-13716;WORDSNET-13717) have been fixed in this .NET update and this Java update.