Hello,
We also really need to have an importStyles method. An alternative would be to introduce a new ImportFormatMode similar to KeepSourceFormatting but that redefines styles instead of generating new styles (cluttering the document).
Our use case is to apply the styles from one or more templates to another document, thereby forcing a document style that is consistent across all documents.
We are converting a solution based on the Word API to Aspose, which is exactly what Aspose aims to facilitate. Our current Word implementation simply calls Document.CopyStylesFromTemplate(). The workarounds that have been suggested in this thread all involve a lot of work and do not produce an acceptable result.
It is understandable that some issues have a higher priority, but it has been over five years now, and this issue has still not been addressed. To be honest, the lack of an adequate response regarding this issue brings up the question whether Aspose is actually the right choice for us.
We hope that you are willing to resolve this issue in the next release.
Kind regards,
Niels Beekman
Hi Niels,
Thanks for your inquiry.
First of all, I have created a new thread here for you to keep discussions separate for effective management of our customers. I would suggest you please follow this thread for further proceedings from now on wards.
Secondly, your request has been linked to the appropriate new feature (WORDSNET-1268) in our issue tracking system and you will be notified via this forum thread as soon as it is supported. We apologise for this inconvenience.
Moreover, yes, you’re right; there appears to have been many delays in the resolution of this issue. I have asked the ETA of this feature from our development team. As soon as any information is shared by them, I will be glad to share that with you.
Best Regards,
The issues you have found earlier (filed as WORDSNET-1268) have been fixed in this .NET update and this Java update.
This message was posted using Notification2Forum from Downloads module by aspose.notifier.
Hello team,
Thanks for the update! The release notes did not include specifics on what was added exactly, but I have found StyleCollection.addCopy. I came up with the following code:
private void copy(StyleCollection source, StyleCollection target)
{
for (Style sourceStyle: source)
{
Style targetStyle = target.addCopy(sourceStyle);
targetStyle.setName(sourceStyle.getName()); // override existing style
}
}
My intention is to override existing styles, but there is no way to express this intention currently. It seems that the setName call gets the job done (style count is decremented by one after this call). Can you confirm that this is the intended behavior, i.e. can I rely on this to continue to work?
Thanks and regards,
Niels
Hi Niels,
Thanks for being the early adopter of this new feature and yes we decided to let Name setter do the overriding of existing style if this is the intent of the API consumer.
If this is not hard for you please check how well this feature works for your testing data and share some feedback. We’ve seen some issues related to importing/overriding styles so we’re eager to get your input to improve importing/overriding algorithm.
Hi,
We have performed some more testing, and ran into several issues.
When copying styles between the attached documents, an exception occurs. I have narrowed it down to the ‘Default Paragraph Font’ style.
Document source = new Document("stylesource.docx");
Document target = new Document("styletarget.docx");
Style style = source.getStyles().get("Default Paragraph Font");
Style targetStyle = target.getStyles().addCopy(style);
targetStyle.setName(style.getName());
The stacktrace:
Exception in thread "main"
java.lang.ClassCastException: com.aspose.words.Style cannot be cast to java.lang.Integer
at com.aspose.words.ZQM.gK(Unknown Source)
at com.aspose.words.StyleCollection.X(Unknown Source)
at com.aspose.words.StyleCollection.├(Unknown Source)
at com.aspose.words.ZN9.├(Unknown Source)
at com.aspose.words.Style.setName(Unknown Source)
Another issue is related to style aliasing. Aliases seem to be somewhat unsupported at the moment. The StyleCollection contains duplicate styles (i.e. with the same name) when a style has been stored under an alias. If you like, I can provide a separate test case.
I also got a question regarding base style names. The Javadoc mentions ‘This method does doesn’t copy all dependent styles’. Could you elaborate a bit more on this? Afaik, when all styles need to be copied, this forces me to write a lot of code to copy the styles in an appropriate order.
Regards, Niels
Hi Niels,
Thanks for your inquiry. First of all, I was unable to reproduce this exception on my side. Could you please double check if you attached the correct documents? Secondly, the bottom line is that if a matching style already exists in the destination document, the source style is copied and given a unique name by appending a suffix number to it, for example “Normal_0” or “Heading 1_5”. Moreover, suppose you have two styles (Style1 & Style2) in your source document such that Style2 is based on Style1 and if you copy only Style2 to your destination document, Aspose.Words won’t copy Style1 (a dependent style) implicitly.
Best Regards,
I downloaded the attachments and got the exact same exception when running the code I posted. I am using the official 11.8.0 release that was posted a few days ago.
Regarding the style copy: thanks for the information. One question though: in case only Style2 is copied, what will be the base style name of that style in the target document?
I will open a separate topic for the style aliasing issue.
Regards, Niels
Hi Niels,
Thanks for your inquiry. The base style would be null (no style) in this case.
Secondly, I am afraid, I was still unable to reproduce this exception on my side. Could you please double check if you’re referencing the latest version of Aspose.Words in your project? You can determine version of aspose.Word by doing the following:
Unzip Aspose.Words.jar, open META-INF\ MANIFEST.MF file in notepad, you will see the following:
Manifest-Version: 1.0
Specification - Title: Aspose.Words for Java
Specification - Version: 11.8 .0 .0
Specification - Vendor: Aspose Pty Ltd
Implementation - Title: Aspose.Words for Java
Implementation-Version: 11.8.0.0
Implementation-Vendor: Aspose Pty Ltd
Release-Date: 2012.09.30
Best Regards,
Hello Awais,
That’s weird, I have the exact same version.
I have attached a ZIP-archive containing the library and code that I use. Invoke with ‘java -jar styletest.zip’.
Regards, Niels
Hi Niels,
Thanks for the additional information. I am afraid, I have had no luck in reproducing this issue on my side. Could you please also tell us about what environment are you running on for example?
- OS( Windows Version or Linux Version )
- Architecture (32 / 64 bit)
- Java runtime JDK version
- Any Third Party Libraries / SDK in addition to Aspose Products.
Once I have above information, I will prepare the required platform to simulate the environment as of yours. As soon as everything is setup, I will then test the issue again and will post the results here for your kind reference.
Thanks again for your patience and understanding.
Best Regards,
Hello Awais,
I have reproduced the issue using the following configurations:
Windows 7 64 - bit SP1: jdk1 .6 .0_23(32 - bit + 64 - bit) / jre1 .6 .0_22(32 - bit) / jdk1 .5 .0_22(with Aspose jdk15 library)
Windows XP 32 - bit SP3: jre1 .6 .0_34(32 - bit)
No third party libraries involved, just the zip I sent you.
Regards, Niels
Hi Niels,
Thanks for the additional information. I finally managed to reproduce this exception on my side. I have logged this issue in our bug tracking system. The issue ID is WORDSJAVA-638. Your request has been linked to this issue and you will be notified as soon as it is resolved. Sorry for the inconvenience.
Best Regards,
Hi,
I would have guessed that this problem would long be fixed. However, it appears that the 11.9.0 release still throws an exception for this scenario.
Please let me know when this will be fixed, as this bug effectively renders the style copy functionality useless for us.
Regards, Niels
Hi Niels,
Thanks for your inquiry. Unfortunately, this issue is not resolved yet. Our development team is currently doing analysis of WORDSJAVA-638. We will inform you as soon as this issue is resolved. We apologise for the inconvenience.
Best Regards,
Hi Niels,
Thanks for waiting. Could you please check the attached Aspose.Words JAR on your side and see if the exception still occurs?
Thanks,
Hello,
Thanks for the follow-up. Is the JAR you attached supposed to be a custom build? It looks like this is the 11.9.0.0 release, which does not fix the bug.
Manifest-Version: 1.0
Specification - Title: Aspose.Words for Java
Specification - Version: 11.9 .0 .0
Specification - Vendor: Aspose Pty Ltd
Implementation - Title: Aspose.Words for Java
Implementation-Version: 11.9.0.0
Implementation-Vendor: Aspose Pty Ltd
Release-Date: 2012.10.31
Earlier in this thread I have attached my test case. Please try for yourself, let me know your findings.
Regards,
Niels Beekman
Hi Niels,
You right, metafile is not changed. But the jar itself is changed: it is 11.9 + few fixes, another obfuscation. I hope this can fix your issue. The thing is that I can’t reproduce the issue on my site and stack trace points to very simple place… i can think only about some JIT or similar optimization or about bug in non-standard JRE.
Best regards,
I have tested with numerous JRE’s as described in this topic. Maybe you could send another build that contains debug logging that will help you pinpoint the issue. Which JRE have you tried?
–Niels
Hi Neils,
Thanks, we just fixed the issue. Awais Hafeez has the only environment that can reproduce your bug and another jar with yet another fix works well now on this environment.
You can check this jar too for full confidence. The fix will be included in the next release that will be published in the end of the month.
Regards,