We Keep Coding

How to parse HTML text and add it to MigraDoc Document

I need to get a text that's being written by a user (in CKEditor HTML), and then add that text to a MigraDoc document, as a paragraph or whatever I need it to be.
My idea was converting the text to an MDDDL document (in memory) and add it to the document. But I don't know if there are any DLLs that permit that behaviour.
So, my question is, can someone give me pointers or advice on how I could make this happen? Should I parse the HMTL text? If so, to what should I parse it? How can I add it afterwards?

Neither PDFsharp nor MigraDoc can parse HTML, so either write your own code or try to find a third-party library (which may not exist yet).
I would probably convert the HTML directly to MigraDoc document objects in memory.

MigraDoc / PDFSharp can't do this.
But, you could use HtmlAgilityPack nuget and then use its htmlDoc.DocumentNode.Descendants() to pull out the pieces of text from html in a flat list kind of a structure, and node.ParentNode.Name to figure out the tag that the text is wrapped in. And then insert the text into your MigraDoc document with something like .AddFormattedText() and apply custom MigraDoc styles to it - i.e. if the parent tag is "strong" then apply a MigraDoc style where Font.Italic = true; etc..

Check if document has multiple pages

In MigraDoc, I know I can add a page count reference to the document using AddNumPagesField, but is it possible to determine if there are multiple pages?
The methods AddPageField and AddNumPagesField do not contain any useful information.
Basically, I want to do something like:
if(/* document has multiple pages*/) {
//do something here
}

With MigraDoc, pages do not exist until a document is rendered.
MigraDoc does not create any pages when rendering to an RTF file. Pages do not exist there.
MigraDoc creates pages when rendering to PDF.
AddPageField and AddNumPagesField are placeholders. They remain placeholders when rendering to RTF, they will be replaced by the real values when creating PDF - their values cannot be determined while the MigraDoc document is still being created.
What you can do: Assume the most likely case (e.g. multiple pages) and create the document. If it only has a single page, then discard it and create it again for the single-page case.
Or maybe use PDFsharp to modify the PDF file created by MigraDoc as needed, now adding the contents that depend on the page count.

Footer not appearing on pages with programmatically added content

I have a base document with sections created by programmatically inserting from a separate template document. The insertion is fine, but the footer isn't appearing on any extra pages created as a result of the insertion, i.e. the first page has a footer, but page two (created by inserting content) does not. If the original document has a two pages then it will render with a footer on the first two pages, but not the third.
Is there a way I can force the footer to render on all of the pages I have created?

There are three types of Headers/Footers in a Section e.g.
Header/Footer for First page,
Primary Header/Footer which can also be used for Odd numbered pages and
Header/Footer for Even numbered pages.
So, if you want to keep same Header/Footer across all pages in Word document, you can first clear all Headers/Footers (see Section.HeadersFooters.Clear() method) from all Sections in Document and then build/assign a single Primary Header/Footer to the first Section.
You might also want to turn off/on 'Different First Page' and 'Different Odd & Even Pages' options using 'Section.PageSetup.DifferentFirstPageHeaderFooter' and 'Section.PageSetup.OddAndEvenPagesHeaderFooter' properties.
Also, using Aspose.Words, you can programmatically control How Headers and Footers should appear during Joining and Appending Documents.
I work with Aspose as Developer Evangelist.

How do I insert an image in a word document as footer

I need to create and insert a QR code into existing word documents using .NET.
I've done the QR generation part. The 2 things I need to accomplish are:
Inserting the QR code in the footer of an existing word document (preferably using Open XML).
Each page of the word document has a unique QR code. This means that each footer would have to be different. (I could eliminate the footer and place the QR code as part of the body, but that word make flow of text complicated.)
Is it possible to accomplish this?

I haven't done this, but I believe that what you will need to do is
put each page in a separate Word section (and that means, in effect,
that you will need to decide what your page size and layout is)
create a footer containing one QR code to find out what XML Word
expects, and what type of image data you need to store in the .docx
(assuming that you are not attempting to store your image data
externally in spearate files).
create a footer for each section (and ensure that the footers are
not "linked to previous"), replicating the format you discovered in
point (2)
create a part for each QR code image, and a relationship to that
part
What I am even less sure about is whether Word will insist that you also store each image in another format (e.g. Windows Metafile or Extended metafile format). My guess is that Word will generate what it needs from your .jpg (or whatever). Or maybe you can use "AltChunks" in some useful way here.
The background to this is that if it were a .doc format document, you could have created a single footer containing a set of nested field codes that used the { PAGE } page number field to link to the correct image for each page - e.g.
{ INCLUDETEXT "c:\\myqrcodes\\qr{ PAGE }.jpg" }
or more likely, the slightly more complicated
{ PAGE \#"'{ INCLUDETEXT "c:\\myqrcodes\\qr{ PAGE }.jpg" }'" }
But if you try to save that as .docx format, even in compatibility mode, when you close and re-open, I think you wil just see one image on all pages. Further, even though that approach works with .doc format, it only works if the external image files are actually there and located at absolute addresses in the file system. If they are located at releative addresses (there is a way to do that) you or the end user will probably have to update the footer field codes to get the correct results.

How to build form completion/document merge application with Winforms or WPF?

I need to build an application that accepts user input data (such as name, address, amount, etc.) and then merges it with a pre-loaded document template (order form) and then prints this merged document. I can use Windows Forms or WPF for this project.
Any suggestions on how best to approach this? I'm experienced with Winforms development, but don't have any idea how to handle merging the data to the document for printing.

WPF works great for this.
You can create document templates from WPF UI elements such as a Page or a UserControl. Set up the template like you'd set up any UI in the VS designer. Determine what shape your data will be stored in (this will be your DataContext), then bind against its public properties. Then you can drop your merged template into a FixedPage and add it to an XPS document. You can print that very easily or save it to disk.
Simplified algorithm:
Create a data entry form.
Create a type that will hold data from the form (call this type Foo)
Create a Page template that binds against Foo (when a Foo instance is the DataContext)
Bind the form to an instance of Foo
Have the user fill in the form (and thereby the instance of Foo)
Create an instance of your template (assume its a Page)
Set Page.DataContext = fooInstance;
Add the Page to a FixedPage, then add this to a Fixed Document
Save the FixedDocument to an XPS document
Save the XPS document or send it to a PrintQueue
I'm doing something similar to this and it works well. Just go to my profile and read all my questions. They cover most of the hard bits of the whole procedure.

You need to use Mail Merge. A mail merge is a method of taking data from a database, spreadsheet, or other form of structured data, and inserting it into documents such as letters, mailing labels, and name tags. Start from this article.