The documentation of getFileAsyc says it will always be in (.pptx or .docx) in Office Open XML (OOXML)
Since Office 2016 this holds no longer true, if one saves the file in OpenDocument format (*.odt).
How will I get the information about the filetype? The name ends with *.odt, but in Word 2013 the name also ended with *.odt, but was transferred as *.docx
Example:
In following case, the binary filecontent cannot be determined:
Create an empty file in Word
Insert your TaskpaneApp
Safe the file as *.odt to you PC in Word
call getFileAsync(Compressed), and
get no docx but odt-content in Word 2016 with the name .odt
get docx-content in Word 2013 with the name .odt
For Word 2013 I fixed the problem by adding .docx to the provided name. Exactly this fix causes the Problems with Word 2016, where the file is realy a *.odt
The input parameter of the getFileAsync method is precisely the file type you need. And this is independently on which format you saved the file.
Office.js supports 3 file types: compressed (which is docx,pptx, etc), text (plain text) and PDF. ODT is not a file format supported in the getFileAsync Method. Check the article you referred to see what formats are supported in which Office Applications.
hope this clarification helps.
Related
Whenever an MS word (or LibreOffice or other word processor) document is opened in its respective program, the words appear normally on the page, but when the document is opened in a text editor, most of it is Unicode gibberish.
I can understand why the document might have some parts that aren't legible, like bullet points or metadata, but why isn't at least some of the content stored as plaintext? Does every letter get encoded?
The last format docx of Microsoft Word is an xml with plain text compressed with zip. You can unzip the file by renaming docx to zip and then open the file with a notepad. So it is stored partially as plain text just compressed.
I find that it is probably a branding thing. If you want you can import it to a Text File.
If you go to File > Export > Change File Type > Plain Text (*.txt), you can export the document there.
Our project has requirement to generate end report both in PDF and MS-Word Document. We are using iTextSharp to dynamically generate tables and rows in report. Finally we will upload the file to server as PDF and MS-word. Both will be converted to Byte Array/Stream file and saved as PDF and MS-Word Document. In Which,uploaded PDF working as expected, but MS-word getting error and not opening(Attaching the screen shot).
iTextSharp doesn't produce MS Word documents, so this isn't an actual iText question. When I look at your screen shot, I see that you are trying to import a PDF file into Word. Since Word can't interpret PDF syntax, it shows you the syntax of the PDF file:
%PDF-1.4
%âãÏÓ
1 0 obj
<</Type/Font...
I think your question is wrong. You are not using iTextSharp to create a PDF file and an MS Word file. You are using iTextSharp to create a PDF file, and not an MS Word file.
There is no such thing as "Save a PDF as MS Word file" in iTextSharp, and it will be extremely difficult to find another tool that can convert a PDF document to a Word document in an acceptable way. (There are such tools, but the quality is suboptimal for PDFs that weren't made to be converted to another format.)
I use RTF as the default format. Is there a way to keep Word 2013 from showing “[Compatibility Mode]” after the title of every document? It is taking up lots of space in the taskbar and title bar and makes the titles of documents hard to read.
There's no way to suppress using a setting - RTF file format hasn't been the "plain text" version of a Word document since Word 2007, when the Word Open XML format took over that role. Any RTF file equates to Compatibillity Mode since it cannot support the newer Word functionality.
The only possibility you'd have would be to set the Caption property of the Application object, using VBA or another language automating the Word application. But you need to be aware that this is not permanent in any way.
I'm trying to take some data stored in a database and populate a Word template's Content Controls with it using the Open XML SDK. The data contains paragraphs and so there are carriage return and line feed characters in it. The data is stored in the database as nvarchar.
When I open the generated document, the CR+LF combination shows up as a question mark with a box around it (not sure the name of this character). This is actually two sequences back to back, so CR+LF CR+LF equals two strange characters:
If I unzip the .docx, take the Custom XML part and do a hex dump, I can clearly see 0d0a 0d0a so the CR+LF is there. Word is just printing it weird.
I've tried enforcing UTF-8 encoding in my XmlWriter's settings, but that didn't seem to help:
Dim docStream As New MemoryStream
Dim settings As XmlWriterSettings = New XmlWriterSettings()
settings.Encoding = New UTF8Encoding(False)
Dim docWriter As XmlWriter = XmlTextWriter.Create(docStream, settings)
Does anyone know how I can get Word to render these characters correctly when written to a .docx through the Open XML SDK?
To bind to a Word 2013 rich text control, your XML element has to contain a complete docx. See [MS-DOCX]:
the data stored in the XML element will be an escaped string comprised of a flattened WordprocessingML document representing the formatted data in the structured document tag range.
Earlier versions couldn't bind a rich text control.
Things should work though (with CR/LF, not w:br), if you bind to a plain text control, with multiline set to true.
we have word Document(office 2003) Containing Bookmarks(Template) - We Generate the Document Via Application under Test(Final Document)(Office 2003)- Based on the data we enter in the Application under Test -Book mark gets filled and Document Gets Printed
So now I need to Compare the template with the Final Document
What is the Best Approach to compare the 2 documents
Note: I need to Compare the Margin , font and all other formatting stuffs as well
Initial Analaysis - I Converted the 2003 template and the final document to 2010 word format and changed the File type to .zip - when we extract it i got numerous XML - I compared both the XML - but that is not adding value for this kind of test why because eventhough there is a discrepancy it is becoming really difficult to Map the contents in XML to the actual contents in the word document
Winmerge has a plugin that handles Word 2003/2007 files.