Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I have automated word document creation from templates using the "Microsoft Word 12.0 Object Library" in my project, but it is unacceptably slow. I'm looking for alternatives: I need to create a document from a template, run some macros and insert text and tables into various bookmark ranges (some text formatting options would be nice too). I only need the final document to be compatible with Word2007, but would prefer a solution easily available from .NET (other recommendations are appreciated too)...
Please advise.
Have a look at Microsoft's Office OpenXML SDK. It allows you to create Word 2007 (.docx) documents programmatically without the Office applications.
To use it you will need to be familiar with the OpenXML file format. A good starting point also providing examples are the blogs of Brian Jones and Erika Ehrli.
This sample on CodeProject might also be a good start: Creation of a Word 2007 document using the Open XML Format SDK.
I also recommend you to have a look at the DocumentReflector, a tool included within the SDK, that creates the code to produce a certain Word document based on an existing document.
Options, I used up to now:
Yours - COM automation: performance wasn't the biggest issue here for me,
just all the ugly details of COM automation like dead processes, locked files, ...;
for some tasks where an API exists and as long as only person uses the app,
its still an option.
Requires Word installation.
Import as HTML and save as Word - works quick and better as expected,
as long as your word format is simple and matches HTML markup structure quite well
(e.g. headers, item lists). To simplify handling, templates have to be HTML then,
so often a quick hack for a limited use case.
Requires Word installation.
Concatenate and process templates saved as WordML: saves you the pain of COM
automation, but since WordML is just a binary format masked as XML, it's often a pain;
hence some tasks are more complicated than using a Word-API.
Nevertheless I prefer it over 1.
Does not require a Word installation.
As in previous answer, OpenXML SDK: just starting to use this, seems to be a good
compromise of 1 and 3: work on XML level or on API level - whatever fits best for a
certain feature.
Does not require a Word installation.
other recommendations are appreciated too
The Java equivalents to the OpenXML SDK are docx4j (my project), and POI.
Using docx4j, you can inject macros into an existing docx, or work from a dotm (as divo suggests).
Officewriter is another option.
The OfficeWriter API is a .NET library that allows you to generate,
manipulate, and read Excel and Word documents from your own
applications.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
The task
We'd like to maintain some developer's documentation for our .NET projects with the following criteria:
"Documents", ideally written in Markdown for providing information that's not closely related to a piece of code (like overview, FAQ).
Standard inline comments for code and API documentation. We do thus in form of standard inline (XML) comments on the classes/interfaces (primarily for IntelliSense support, secondarily for being able to generate an API reference) and would like to continue to do like that.
The documentation is contained in what it documents; e.g. if it's an overview of a solution then in the solution, if it's for a project then among the project's files, version controlled in the same way as the code (this is so the docs are close to what they document, so they are less prone for going out of date, and also this was docs are always "at hand").
Ability to auto-generate (from the CI server) a readable, compiled documentation for a whole project, including "documents" and inline comments for APIs.
An example
We've a project that's a component usable within a 3rd party system. For this project we have the following type of documentation:
Overview (what the project does, what are the aims)
Installation instructions
API documentation
Version history
We'd like to enable our developers and other developers to
- read this documentation from the project's source package and
- from a website.
Solutions we've looked at
Using a wiki (we tried Confluence): this is good for "document"-type of documentation (like overview or installation notes), but it lives independently from the project itself. It's another system to maintain and because it's not before one's eyes when doing development it can quickly go out of date. Also it's one more task to somehow integrate auto-generated API documentation into it.
Using Markdown files and storing them along the code: this is simple and documentation is always at hand and close to what it documents; however we somehow need to generate a publishable web package from these files and the source files' inline documentation.
So far doxygen looks like the solution capable of providing all these. Do you agree?
See "How to include custom files in doxygen".
Broadly speaking this is exactly what I am currently doing, and I'm using Doxygen.
However, I'm afraid I know nothing about .NET. The project I'm working on is a Java package, but includes API documentation extracted from the source, user guides, release records and things like deprecations.
The only thing out of our scope and in yours is Installation Guide, but that's really only because the developer only gets to read it after installation.
We have Jenkins CI building the document on every change.
The 'descriptive' text is all written in Markdown which Doxygen handles reasonably well.
Downsides: If you are familiar with the way Doxygen handles grouping of text for source code you may be confused that these commands don't work to group the blocks of text in Markdown. There are a few other specific oddities but you'll probably find most of them if you scan my own questions on the subject (here, here and here)
Upsides: (Things we've found useful that you've not mentioned)
We can also parse the 'doxygen' markup in the Java API to create a javadoc that IDE's such as Eclipse can use. This does mean we have to limit ourselves to javadoc-style command in the API docs but that's not a big limit.
We've included, under doxygen 'build switch', a manual for your developers on how to write the documentation for the manual (OK, this is slightly recursive!). This provides the recommended command subset to use, and whether (according to taste) you want people to use doxygen #subsection or Markdown ## for headings etc.
Hope that helps.
I'd suggest you try it; trialling a sample of each type of document section you need, to see if it will do the whole set of functions you need. Nothing more annoying documenting 90% then finding it won't do the last 10%.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am looking into using a wiki (prefer mediawiki, but not a req.) as the repository for developer generated documentation (User Guides, Release Notes, Application Notes, Errata, etc.) from a collaborative/easy-to-update point of view a wiki seems like a good match, however since this documentation will ultimately ship to customers we want to be able to export the documents in their final state (e.g. during the release cycle) to static versions that no longer include histories.
Ideally the export would leave the document in a form (i.e. word doc, or legible HTML) where updates could be easily made by a non-programmer.
It would be good if niceties like section ordering and table of contents were available, or easy to add after the fact.
Are any tools with features like these available?
It sounds like you need a step in your dev cycle that will take your HTML wiki contents and "documentify" them - doc/pdf/html for simpler delivery. If that's right, you could try something like Docmosis or JODConverter which can act as engines to do the conversion. The last step would be working out how to integrate it and have it automatically extract your wiki content to transform into a document.
I'm a little confused.
If you want to ship the documentation in a formal like HTML, how would users continue editing? (use DumpHTML to generate HTML).
If you want to ship the documentation in Wiki form and allow users to continue editing, why not just replicate the database and get rid of the change history until a certain point? AFAIK MediaWiki has some support for this.
One option would be Mylyn WikiText, which is used by some Eclipse projects to generate Eclipse documentation from the Eclipse wiki (which is based on mediawiki). WikiText also supports other wiki markup (trac, textile, etc.) and other output formats (docbook, HTML, etc.).
In MoinMoin Wiki you can export to DocBook. DocBook can be converted to professional looking PDFs.
DokuWiki uses plain text files as storage backend which can be simply copied to your project as documentation.
First, don't discount that MediaWiki has a permanent link function. So, if you allow the readers to access your wiki, you can just send them a URL to a specific version of the page.
Alternatives - you can print a PDF. Wikipedia uses the Collection extension but there are others.
Finally, if you use Firefox and want a client side solution, use PrintPDF
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I am looking for some references on how to implement the following feature:
ability to embed objects (e.g. diagrams) into word processors and being able to edit them in their respective "mother" application
For example, MS Word and Visio work like this together, allowing the user to easily edit/tweak the diagrams after adding them to the word processor.
I am interested in how this is done on the following platforms:
Microsoft Word
OpenOffice
So far I know that:
Microsoft Word uses OLE/COM
Open Office uses UNO
Can you point me to any references, examples, books on how to approach this?
Since OLE is an almost pre-historic technology (still of use) you have to dig a bit deeper in MSDN. The article linked below describes a sample application that can be embedded into container applications such as IE, Word, or OpenOffice. The sample is based on VC6, so I don't know how much luck you will have to get it running with current versions of Visual Studio.
Creating an OLE Server
Probably the most simple option to create an OLE control (.ocx) is to use the old Visual Basic 6. This is described here:
How To Create and Use a Minimal ActiveX Component in VB
It is also possible to write a control in managed code like C#, but I assume this is not recommended1 as it might lead to conflicts if the current process is already running another version of the CLR (Up to now, only one version of the CLR can exist in a process, .NET 4.0 will introduce side-by-side execution of the CLR). I found the following tutorial:
Create ActiveX in .NET Step by Step
1See the warning at the bottom of this article by Andrew Whitechapel.
This can still be quite easily done in Word using COM (or OLE but it's the same thing with a new name). Depending on what language you are intending to do it in you will go about it differently. Essentially you need to create a particular kind of ActiveX control.
In Delphi (the easiest language to do this in) you would create an ActiveXForm in a COM dll and then you would be able to embed this in your word document. You could make your application do whatever you wanted inside Word (talking to Word is a bit more involved but possible).
I have no idea what to do in OpenOffice I'm afraid.
I think you need to come back with more specific questions.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Currently the documentation where I work is in a bit of a state. There isn't anywhere near enough of it, and the documentation that does exist is spread out over many word documents making it hard to find anything.
I'm trying to take some initiative and get it improved, and I figure the first thing is to find a better format to write the documentation in:
My thoughts are that the documentation should be structured in a series of short articles (MSDN / Html Help style) and structured in a suitable tree:
It would be good to be able to produce a standalone Html-Help style package to be shipped with the application
As well as being able to produce a MSDN-style website as a reference for those who are too lazy to look at the CD.
Search is of course a must-have
It needs to be at least reasonably easy to update - if there is a 17 step process to update the published documentation then it makes it seem like too much work to do simple changes, and nobody can ever be bothered to update it.
The documentation is technical in nature, and so ideally it would be nice to be able to include generated documentation from things like the Xml documentation embedded in C# code. This is however definitely a side-requirement - currently very little useful Xml documentation exists, its just that in the future I plan to fix that.
For the same reason it is often good to be able to handle things like attachments (code samples etc...) I'm not expecting anything fancy, but this is something I need to bear in mind to make sure that its at least not handled badly.
Are there any projects or languages that are suited to this sort of documentation?
I've had good results with doxygen on my C and C++ projects although it supports many other languages as well. You put the documentation in comments in the code that can be simple or complex HTML markup. It is very easy to update as it is part of the code. You can make building the documents part of your build process. Additional topic that are not strictly API related can be added as separate HTML documents. The version I'm using doesn't support search so you would have to add another product to search these pages. Because it is HTML you can add in code samples, diagrams, etc.
If you use LaTeX you can get all your documentation in great looking PDFs and printed copies, as well as being able to generate html (via latex2html). TeX has the advantage of being all plaintext, too, so you can track/merge it reliably with your favourite revision control system.
We use confluence as our documentation repository. It is fairly easy to have public and private sections, and has a nice WYSIWYG editor. It can handle attachments and can be saved off as PDF documents if you like.
I've used robohelp with good results. it is plain html, but has a generation process that keeps everthing looking consistent. It can be packaged as a .hlp file with the app, or published to the website. Check it out, it is simple so you can get back to doing your job :)
A clean way is to use DocBook. It is easy write and undetstand. It is also easy to parse as XML parsers are standard and other forms of documentation (e.g. from the embedded documentation in comments) can be easily be transformed to this format.
It is straightforward to generate PDF, HTML og other formats from the DocBook source (tools exist for this purpose).
I've started using DokuWiki. Its not exactly what I was originally looking for (I think I was really looking for a CMS), but it does the job and some respects its better than what I originally had in mind (in particular its a wiki - I've not yet gotten as far as publishing this to our customers however so I'm not sure how well thats going to work out)
I'm using the IndexMenu plugin and the Arctic template to get a navigation tree on the left, and if I publish the wiki itself I'll use the discussion plugin to allow users to post feedback.
Currently my method of handling generated content is to use xslt templates to produce dokuwiki syntax, and write that output directrly to files / folders in the "data/pages" folder.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm investigating the possiblity of creating PDF files from an embedded system, specifially an ARM9 using the IAR tools. Open-souce or licensing is fine - I'm finding it difficult to search for online, and I'm hoping someone here has used a package. C or C++ is preferred, we will be creating fairly simple reports with only a little text and graphics.
UPDATE: By searching SO, I did find PDFTron - anyone have any experience with it? Seems like it might do what we want.
!!!
(is this a webserver? Otherwise it seems like it would make more sense to spit out text files as reports and convert on a PC.)
No experience, but maybe libHaru ? Wikipedia has a list of PDF software.
Look at iText - I've used that before and it works well.
(It is Java-based, but you said "C or C++ is preferred", not required)
How large is the system you're targeting? If you can afford to run a Python interpreter and a copy of Inkscape (no X needed), there's a great toolchain available.
Last time I faced the kind of problem space you're in, I used Inkscape to render SVG to PDF in non-GUI mode, as follows:
inkscape --without-gui --export-pdf=foo.pdf foo.svg
...where the SVG is built using template substitution. (In doing this in the past, I used the Genshi template language for building the templates, which happens to interoperate wonderfully with Inkscape's GUI functionality -- Inkscape-the-GUI-SVG-editor doesn't remove tags in namespaces it doesn't recognize, so you can edit a SVG template in Inkscape even after marking it up to work as a Genshi template!)
My use case was automatic generation of cover pages for outgoing fax jobs; a complete set of scripts implementing this method for HylaFAX+ is available in the mailing list archive here.