Hi - thanks for all your excellent support in the past. I have a bug - WORDSNET-20522 ---- Status : Postponed, that may not ever make it out of your backlog, not sure. Not at all complaining, I can see you have a ton of issues to deal with. Only reason I ask is because this was the last issue that was stopping us from getting licenses and switching from our old solution. My publications department ask me often if I have heard from you guys, so if it is likely is too complex to fix, or too low a priority, then I will go ahead and let them know that the project will be delayed for the foreseeable future.
best regards
Andy
We have completed the analysis of WORDSNET-20522; but, the implementation of the fix of this issue has been postponed till a later date. There are no estimates (ETA) available at the moment. We have logged your concerns in our issue tracking system and will inform you here as soon as this issue will get resolved in future or any more updates may be available. We apologize for your inconvenience.
1 Like
I have a follow question on this:
when you did the analysis and created the bug - did you actually figure out what was causing it - i.e. some crazy font or whatever?
or is it the case you haven’t gotten around to figuring out what the issue was?
I ask because one option for my company is to buy licenses and then add some plumbing code to route documents to a non-aspose converter if this condition/font set (whatever it is) exists in the word doc. If you already know what it is to look for (but just haven’t fixed it) then please let me know and we can try to use that to code around it (and spend some money with you). If you haven’t figured out what it is, then my team can to try to figure it out and then let you know, in case that helps make it a better candidate to be selected from the back log.
cheers
Andy
Regarding WORDSNET-20522, we have completed the analysis of this issue; but because of complexity, the implementation of the fix of this issue has been postponed till a later date. There are no estimates (ETA) available at the moment. The issue is even reproducible with a simplified document (see 20522 Simple DOCX and PDF files.zip (50.4 KB)). The problematic subscripts are specified in the Word document via Run property. Aspose.Words’ layout engine currently does not handle this rare case. We have logged your concerns in our issue tracking system and will inform you here as soon as this issue will get resolved in future or any more updates may be available. We apologize for your inconvenience.
1 Like
thanks so much. this is REALLY helpful. Much appreciate you sharing.
Please note that the problem occurs because Aspose.Words layout engine currently does not support this feature: “Two Lines In One…” (please see TwoLinesInOne.png (18.8 KB)) and unfortunately, we currently do not have plan to implement this feature in near future. We apologize for your inconvenience.
Yup, makes sense. In any case, your input was excellent. We are starting a code library to intercept docs that have features you don’t support and route them to an alternate converter, or just fix them with OpenXML SDK by converting them to super and sub before getting sent to Aspose.Words. Probably won’t be the last time we find an unsupported feature that is more common for us than others. using code along these lines to find it …
foreach (var paragraph in doc.MainDocumentPart.RootElement.Descendants<Paragraph>())
{
foreach (var run in paragraph.Elements<Run>())
{
if (run.RunProperties != null &&
(run.RunProperties.EastAsianLayout != null && (run.RunProperties.EastAsianLayout.Combine.HasValue)
&&
run.RunProperties.VerticalTextAlignment == null)
)
Process(run, paragraph);
}
}
then empty out the bad run and replace with normal super and sub runs, which is what Word seems to do if you fix it manually.
Thanks!
We will keep you posted here on any further updates and inform you when this issue will be resolved in future.