Unable to open RTF to DOCX-exported document in MS Word due to large tab stop accumulation.
Workaround: Re-save the original RTF file with MS Word before converting it to DOCX.
Text frames are paragraphs of text in a document which are positioned in a separate region or frame in the document and can be positioned with a specific size and position relative to non-frame paragraphs in the current document. More information about it is available in section 22.9.2.18 ST_XAlign (Horizontal Alignment Location) of Open Office XML.
at Telerik.Windows.Documents.Spreadsheet.Utilities.SpreadsheetHelper.UpdateFloatingImageSize(FloatingShapeBase shape) at Telerik.Windows.Documents.Spreadsheet.Utilities.SpreadsheetHelper.CalculateRotatableShapeBoundingRect(Point position, FloatingTransformableShape shape) at Telerik.Windows.Documents.Spreadsheet.Layout.RadWorksheetLayout.CalculateShapeBoundingRect(FloatingShapeBase shape) at Telerik.Windows.Documents.Spreadsheet.Layout.RadWorksheetLayout.UpdateShapesSizeAndPosition() at Telerik.Windows.Documents.Spreadsheet.Layout.RadWorksheetLayout.Measure(CancellationToken cancellationToken) at Telerik.Windows.Documents.Spreadsheet.Layout.RadWorksheetLayout.Measure(CellIndex frozenCellIndex, CancellationToken cancellationToken) at Telerik.Windows.Documents.Spreadsheet.Model.Workbook.UpdateWorksheetLayout(RadWorksheetLayout worksheetLayout, Worksheet worksheet, Boolean isForPrinting, CancellationToken cancellationToken) at Telerik.Windows.Documents.Spreadsheet.Model.Workbook.GetWorksheetLayout(Worksheet worksheet, Boolean isForPrinting, CancellationToken cancellationToken) at Telerik.Windows.Documents.Spreadsheet.Model.Workbook.GetWorksheetLayout(Worksheet worksheet, Boolean isForPrinting) at Telerik.Windows.Documents.Spreadsheet.FormatProviders.OpenXml.Xlsx.Contexts.XlsxWorksheetImportContext.ImportShapesSizes() at Telerik.Windows.Documents.Spreadsheet.FormatProviders.OpenXml.Xlsx.Contexts.XlsxWorksheetImportContext.EndImport(XlsxWorkbookImportContext workbookContext) at Telerik.Windows.Documents.Spreadsheet.FormatProviders.OpenXml.Xlsx.Contexts.XlsxWorkbookImportContext.EndImport() at Telerik.Windows.Documents.FormatProviders.OpenXml.OpenXmlImporter`1.Import(Stream input, IOpenXmlImportContext context) at Telerik.Windows.Documents.Spreadsheet.FormatProviders.OpenXml.Xlsx.XlsxFormatProvider.ImportOverride(Stream input, CancellationToken cancellationToken) at Telerik.Windows.Documents.Spreadsheet.FormatProviders.WorkbookFormatProviderBase.Import(Stream input, Nullable`1 timeout)
Workaround: this is the missing part after the export:
This is causing issues when exporting the document to PDF from WordsProcessing - the pdf library tries to create the font, but cannot find it due to a different casing. When importing HTML document, the font-family property is read with small letters. Later, when converting the string containing the value, it is changed to title case. This issue will be reproducible with each font containing a name with a letter with casing different than the one of the other letters (exc. first capital letter), for example: Microsoft JhengHei
In case table cell doesn't have directly applied background, it should inherit the background of its parent table.
Multiple CSS classes on an element are not correctly resolved when converted to inline styles.
Before:
.TelerikNormal {font-family: Calibri;font-size: 14.6666666666667px;margin-top: 0px;margin-bottom: 0px;line-height: 100%;color: #000000;}.TelerikHeading3 {font-family: Calibri Light;font-size: 22.6666666666667px;}<p class="TelerikNormal TelerikHeading3"><span>Test</span></p>Due to order priority, the TelerikHeading3 values override the TelerikNormal values. The font-size becomes 22.6666666666667px.
Convert:
provider.ExportSettings.StylesExportMode = StylesExportMode.Inline;
<p style="font-family: Calibri;font-size: 14.6666666666667px;margin-top: 0px;margin-bottom: 0px;line-height: 100%;color: #000000;"><span>Test</span></p>
Provide a way to export filters.
byte[] data = File.ReadAllBytes("verdana.ttf");
FontFamily verdanaRegularFontFamily = new FontFamily("Verdana");
FontsRepository.RegisterFont(verdanaRegularFontFamily, FontStyles.Normal, FontWeights.Normal, data);
FontsRepository.TryCreateFont(verdanaRegularFontFamily, out FontBase verdanaRegularFont);
foreach (RadFixedPage page in mergedDocument.Pages)
{
foreach (TextFragment textFragment in page.Content.Where(c => c is TextFragment).Cast<TextFragment>())
{
textFragment.Font = verdanaRegularFont;
}
}
When imported in the WordsProcessing model, the current HTML doesn't respect the defined column width and all columns have identical width:
<colgroup>
<col span="1" style="width: 33.3302%;">
<col span="1" style="width: 17.5658%;">
<col span="1" style="width: 49.104%;">
</colgroup>Observed result:
Expected result:
Workaround: use the width property as follows:
<colgroup>
<col span="1" width="33.3302%">
<col span="1" width="17.5658%">
<col span="1" width="49.104%">
</colgroup>
An incorrect file is produced when merging a stream more than 40 times.
Workaround: A possible workaround could be to merge up to 40 times in one file, then continue merging in a new one, and finally merge the newly generated documents.