This results in a missing paragraph. For example, having a table with three cells and Page field in the footer of a document and exporting it to PDF, will not export the last paragraph.
As a workaround add new run after the last field character in the cell's table before exporting the document to PDF.
BlockCollection footerContent = this.document.Sections.First().Footers.Default.Blocks;
Table footerTable = footerContent.First() as Table;
var cells = footerTable.Rows.Last().Cells.Where(x => x.EnumerateChildrenOfType<FieldCharacter>().Any());
foreach (var cell in cells)
{
cell.Blocks.AddParagraph().Inlines.AddRun();
}
We are using the Telerik Xamarin UI components, which were released on 18th March 2020, for one of our micro-services hosted in Azure cloud, to convert rtf text to raw text. Currently we have Linux containers in Azure. The code which we are using is as follows -
var rtfFormatProvider = new RtfFormatProvider();
var txtFormatProvider = new TxtFormatProvider();
RadFlowDocument doc = null;
doc = rtfFormatProvider.Import(<<Base64_Inputstring>>.DecodeFromBase64String());
string result = txtFormatProvider.Export(doc);
However, we observed that the output of the above code is different when run on Windows platform as compared to when run on Linux platform. For Linux, the CR characters are not included in the raw text. We would like to see the same output for Linux as what we get for Windows, that is raw text with the CR characters. Is this something which can be fixed? Can you suggest a work-around for this issue?
I am attaching a sample input along with this mail, as well as the Windows output and the Linux output, for your reference.
Thanks,
Deepa
WordsProcessing: Invalid font size when exporting to pdf.
Workaround:
var runs = document.EnumerateChildrenOfType<Run>();Dear all,
It seems that the RtfFormatProvider generates invalid alternative text in the "{\listtext }" RTF group when saving a RadFlowDocument that contains numbered paragraphs.
The text seems to always be "{N}" when level N of the list is used.
While this is no problem for readers that adhere to the latest RTF standard, RichEdit-based controls and WordPad in Windows 8-10 have issues with it and do not load the list. These versions of RichEdit are otherwise capable of reading list tables.
Please note that I am not talking about loading the document to Windows 7 RichEdit, since that does not support list tables at all (it is stuck to the Word '95 "{\*\pn ...}" format).
I submit a simple list example that can be read by WordPad in Windows 10 and the outcome after loading and saving it back with RtfFormatProvider.
The outcome loads correctly in Word and RadRichtextBox, but not in WordPad. Removing or correcting the "{\listtext ...}" for each paragraph manually makes the list load properly in WordPad.
BTW, I strongly disagree with the nonexistent support for the Word '95 RTF numbering format, since it either forces us to use some other product or create our own code to parse and massage the RTF prior to loading into your products.
The problem is great, as many controls/products are still based on the RichEdit control (including some versions of our products).
It is not only old RTF data that needs migration, but pasted content from WordPad or other applications as well, since otherwise numbering is killed, without even displaying any text present in "{\pntext ... }" groups, intended for readers that do not understand "{\*\pn ...}".
Finally, to make things worse, even in Windows 10, RichEdit uses Word '95 format for saving single-level lists (resulting in content with mixed list formats).
Anyway, thank you for your time.
This element specifies that this run contains literal text which shall be displayed in the document. The delText
element shall be used for all text runs which are part of a region of text that is contained in a deleted region
using the del element.
This is the preview (This is deleted text) of the following XML:
<w:p>
<w:r>
<w:t xml:space="preserve">This is </w:t>
</w:r>
<w:del w:author="Cooper W.">
<w:r>
<w:delText>deleted text</w:delText>
</w:r>
</w:del>
</w:p>
editor.InsertField("PAGE", "1")
foreach (ImageInline image in document.EnumerateChildrenOfType<ImageInline>().ToList())
{
UriImageSource uriImageSource = (UriImageSource)image.Image.ImageSource;
if (uriImageSource != null && !IsValid(uriImageSource.Uri.OriginalString))
{
image.Paragraph.Inlines.Remove(image);
}
}
private static bool IsValid(string uri)
{
try
{
Path.GetExtension(uri);
}
catch (ArgumentException)
{
return false;
}
return true;
}
Wrongly exported table width when the table preferred width is set to fixed:
<w:tblW w:w="11160" w:type="dxa"/>
and it is greater than the available page width:
<w:pgSz w:w="12240" w:h="15840"/>
<w:pgMar w:top="630" w:right="1440" w:bottom="540" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/>
Available page width = 12240 - (1440 + 1440) = 9360
A possible workaround is to set the page width to Auto:
IEnumerable<Table> tables = document.EnumerateChildrenOfType<Table>();
foreach (Table table in tables)
{
if (table.PreferredWidth.Type == TableWidthUnitType.Fixed)
{
table.PreferredWidth = new TableWidthUnit(TableWidthUnitType.Auto, table.PreferredWidth.Value);
}
}
At this point, only background-color is supported. Add support for bgcolor attribute as well. It could be used with the following tags: body, marquee, table, tBody, td, tFoot, th, tHead, tr.
When the value contains a semicolon the HTML style property values are omitted on import:
<th width ='12%;' ...>
Currently, setting it without semicolon imports the value successfully:
<th width ='12%' ...>