I like DocumentViewer for display of an XPS document in a WPF application. But I also need to redact the XPS document. I have found stand alone applications (.exe) for redacting XPS. What I need is a WPF control for view and redaction of XPS. Or an extension to DocumentViewer for redaction. The redaction must actually remove the data and not just hide it (this is for a litigation application). Does anyone know of way to view and redact XPS in WPF?
With a custom DocumentPaginator you can control how each element of the document is printed.
If you can identify the text ranges you want to redact then you can replace the glyphs with a black visual and not add the text range to the final document.
...
Hmm. As I typed the above it really sounds a bit complex when there are simpler solutions.
Read the XPS document, convert it to a FlowDocument.
Allow the user to select text ranges to redact.
Replace* the selected text with the ████████████████ character (U+2588, Full Block).
Convert the document back to XPS and print.
* As you replaced the original text, it will not be available in copy/paste actions.
There are plenty of tutorials on how to each the above steps separately. Let me know if you need any additional help.
If my mind don't lie, you can't edit XPS directly, but you can create WPF representation of document, edit it and print to new XPS file.
Related
I need to make a sort of text processor. It must have these features:
All the WordPad features + paragraph styles like MS Word + text
columns + Zoom.
Insertion of tables, images, and controls like buttons, checkboxes.
Text search and replacement, spell check.
Syntax coloring, like code or quote parts on the StackOverflow site.
Ability to move text paragraph on custom places via mouse (like OneNote)
Ability to add some simple diagram (hierarchic)
I found on the web that the best way to implement the above requirements is to use FlowDocument. I also found that WPF RichTextControl would have many required functionalities, but on StackOverflow it is written that it has bad performance.
So, does it exist a FlowDocument text processor control?
If not, from which control could I start in order to implement the above requirements?
I need to delete the last line of RichTextBox in WPF, to remove the item
A RichTextBox doesn't work on a line-by-line basis, but on flow content.
To quote from MSDN:
Specifically, the content edited in a RichTextBox is flow content.
Flow content can contain many types of elements including formatted
text, images, lists, and tables. See Flow Document Overview for in
depth information on flow documents. In order to contain flow content,
a RichTextBox hosts a FlowDocument object which in turn contains the
editable content.
But, to get and manipulate content, I'd suggest taking a look at some of the examples at MSDN. Something there should fit what you're dealing with.
From the comments on Aaron Thomas' answer, the problem was solved with the following code:
myRichTextBox.Document.Blocks.Remove(myRichTextBox.Document.Blocks.LastBlock);
I am trying to display an RTF file (that was created in a legacy system) in a new WPF application and have run into some difficulty. The old RTF file contains a picture formatted as a binary jpegblip which, when read into the RichTextBox, causes this exception:
Unrecognized structure in data format 'Rich Text Format'. Parameter name: stream
I reduced the file down to the bare minimum to isolate the problem and ended up with the following opening line (the binary data has been removed for this post):
{\rtf1{\pict\picw2700\pich2700\picwgoal2700\pichgoal2700\jpegblip\bin9889
This still caused an exception so I converted the binary data to hex and created a new file with the opening line:
{\rtf1{\pict\picw2700\pich2700\picwgoal2700\pichgoal2700\jpegblip
The file with the hex data in it was displayed correctly by the control.
Has anyone been able to load a file containing binary picture data into the RichTexBox control, or failing that, is there a difinitive statement as to what the RichTextBox supports from the RTF specification?
I'm not even sure Microsoft knows what RichTextBox implements. Their idea of RTF floats around untethered in space. See MS Word, Wordpad, the numerous legacy Rich Edit controls, etc.
This has some comments that talk about using the COM objects in your .NET code, which are somewhat predictable, but again Microsoft doesn't specify what parts of the spec they follow. Broken tables in RichTextBox control (word wrap) - you can use these in WPF if you wrap them properly.
If you just have to display the document, you might ask if all your users will have Word. Then you might be able to embed the Word document viewer, and presto, problem solved. It's an easy dependency to add if your software is used in an office.
I would probably read up on that format until I knew how it worked. Then in my program, I would read the RTF file into a buffer, grab the raw object data, translate it somehow, replace those objects with updated ones, then pass it to the control.
For me, this code works fine. I can even pull it from a database table too.
<RichTextBox Height="100" HorizontalAlignment="Left" Margin="306,30,0,0" Name="rtfMain" VerticalAlignment="Top" Width="200" />
rtfMain.Selection.Load(new FileStream(#"C:\temp\document.rtf", FileMode.Open), DataFormats.Rtf);
I have a RichTextBox and need to serialize its content to my database purely for storage purposes. It would appear that I have a choice between serializing as XAML or as RTF, and am wondering if there are any advantages to serializing to XAML over RTF, which I would consider as more "standard".
In particular, am I losing any capability by serializing to RTF instead of XAML? I understand XAML supports custom classes inside the FlowDocument, but I'm not currently using any custom classes (though the potential for extensibility might be enough reason to use XAML).
Update: I ended up going with RTF because of its support for text-encoded embedded images. XAML doesn't seem to include image data in its encoding, and XamlPackage encodes to binary, so RTF just works better for me. So far I haven't noticed any lack in capability.
If all your users are doing is typing in the RichTextBox and doing character formatting, RTF is as good as XAML. However there are many FlowDocument capabilities you may expose in your UI that are not convertible to RTF.
Here are some examples of FlowDocument (and RichTextBox) features that are not expressable in RTF or are implemented differently:
A Block can have an arbitrary BorderBrush, including gradient brushes with stops, VisualBrush
A Section has the HasTrailingParagraphBreakOnPaste property
Floater / ClearFloaters is implemented differently
Hyphenation can be enabled/disabled per block, not just per paragraph
WPF Styles and ResourceDictionaries can be included in the Resources property
Arbitrary WPF UI such as bound CheckBoxes, etc, can be embedded inside the RichTextBox and can be cut-and-pasted from other windows.
For example, suppose you want to allow users to drag or cut/paste in a "current date/time" field into your RichTextBox that would always show the current date and time. This could be done by adding a second read-only RichTextBox that has the InlineUIContainer and the already-bound control. This even works when cutting and pasting from other applications and does not require custom controls.
Another consideration is that the code to convert between FlowDocument and RTF is relatively complex so it may have lower performance than going with XAML. Of course loose XAML doesn't include images and such - for that you need to use XamlPackage. I store my XamlPackage in the database as a byte[], but you can also choose to Base64 encode it for storage as a string.
The bottom line is that it really depends on whether you want the user to be able to use features not available in RTF. Even if your application doesn't include tools to generate FlowDocuments that use these features, it is possible to cut-and-paste them from other applications.
Be aware that in Wpf RichTextBox's method called TextRange.Save has a bug whereby it loses any end of line terminator. Microsoft will not fix.
https://connect.microsoft.com/WPF/feedback/ViewFeedback.aspx?FeedbackID=478640&wa=wsignin1.0#tabs
I'm looking for a reporting/printing solution that does not involve RDLC/SSRS. I'd like to use the DocumentViewer, which I know supports XPS. I have found plenty of examples that use Visual to XPS but I haven't found many examples where I can take an existing WPF page, with various controls like labels, listboxes, grids, etc and create that into an XPS document. Is there a code example out there that takes an entire XAML page and creates XPS?
It's not trivial, the basic problem here is that XPS represent fixed pages. An existing WPF page does not necessarily translate to pages on a document. How will your report be split if it cannot fit the page? This information is needed.
What you can do is to create the report as a FlowDocument (see http://msdn.microsoft.com/en-us/library/aa970909.aspx). This will give the .NET framework enough info on how to paginate your report such that when you do this:
FlowDocument flowDocument;
// load, populate your flowDocument here
XpsDocument xpsDocument = new XpsDocument("filename.xps", FileAccess.ReadWrite);
XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(xpsDocument);
writer.Write(((IDocumentPaginatorSource)flowDocument).DocumentPaginator);
it works. (Code lifted from Pro WPF in C# Book).
Usually your WPF page has a root UI element, say Grid. As Grid is a specific type of Visual(please vide "Inheritance Hierarchy" part #http://msdn.microsoft.com/en-us/library/system.windows.controls.grid.aspx for more details), you just need to write that root Grid element like other visuals into XPS. And then all embedded controls will be automatically written into XPS document.