https://bugs.documentfoundation.org/show_bug.cgi?id=116592
--- Comment #4 from Bartosz <gan...@poczta.onet.pl> ---
The mapping of the Word to Writer is available at file:
writerfilter/source/dmapper/ConversionHelper.cxx:240
It seems that MS Word it treating colors differently, and it is depends on
position.
void MakeBorderLine( sal_Int32 nLineThickness, sal_Int32 nLineToken,
sal_Int32 nLineColor,
table::BorderLine2& rToFill, bool
bIsOOXML )
{
static const sal_Int32 aBorderDefColor[] =
{
// The first item means automatic color (COL_AUTO), but we
// do not use it anyway (see the next statement) .-)
0, COL_BLACK, COL_LIGHTBLUE, COL_LIGHTCYAN, COL_LIGHTGREEN,
COL_LIGHTMAGENTA, COL_LIGHTRED, COL_YELLOW, COL_WHITE, COL_BLUE,
COL_CYAN, COL_GREEN, COL_MAGENTA, COL_RED, COL_BROWN, COL_GRAY,
COL_LIGHTGRAY
};
//no auto color for borders
if(!nLineColor)
++nLineColor;
if(!bIsOOXML && sal::static_int_cast<sal_uInt32>(nLineColor) <
SAL_N_ELEMENTS(aBorderDefColor))
nLineColor = aBorderDefColor[nLineColor];
sal_Int32 nLineType = lcl_convertBorderStyleFromToken(nLineToken);
// Map to our border types, we should use of one equal line
// thickness, or one of smaller thickness. If too small we
// can make the deficit up in additional white space or
// object size
SvxBorderLineStyle const nLineStyle(
::editeng::ConvertBorderStyleFromWord(nLineType));
rToFill.LineStyle = static_cast<sal_Int16>(nLineStyle);
double const fConverted( (SvxBorderLineStyle::NONE == nLineStyle) ? 0.0 :
::editeng::ConvertBorderWidthFromWord(nLineStyle, nLineThickness,
nLineType));
rToFill.LineWidth = convertTwipToMM100(fConverted);
rToFill.Color =
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
