[Libreoffice-commits] core.git: Branch 'libreoffice-7-4' - vcl/qa

[Stephan Bergmann (via logerrit)]

 vcl/qa/cppunit/text.cxx |   15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

New commits:
commit 5258ba851a12c027dff6070f394b82423f7bd900
Author: Stephan Bergmann 
AuthorDate: Thu Jan 12 16:42:39 2023 +0100
Commit: Michael Stahl 
CommitDate: Fri Jan 13 09:49:18 2023 +

Fix VclTextTest with colorized antialiasing

The Flathub build for


"Merge pull request #206 from flathub/lo-7.4.4" on 2023-01-12 at
 consistently 
failed for
both aarch64 and x86_64 builds with

> text.cxx:260:Assertion
> Test name: VclTextTest::testSimpleText
> double equality assertion failed
> - Expected: 28
> - Actual  : -1
> - Delta   : 2

during CppunitTest_vcl_text.  The reason (as seen with a temporary build 
setting
mbExportBitmap = true and looking at the resulting
workdir/CppunitTest/vcl_text.test.core/simple-text-36-50pct.png) is that the
stem of the "L" doesn't contain any COL_BLACK pixels, so
getCharacterLeftSideHeight returns early with -1.  The stem is drawn as 
three
vertical lines of pixels, a yellow (RGB 255/195/111), a black-ish (RGB 
23/0/0),
and a blue (RGB 31/155/199) one.  In comparison, when running the same test 
on
Fedora 37, the three vertical lines use gray-scale instead of colors,
RGB 195/195/195, then true black (RGB 0/0/0), and RGB 115/115/115.

An earlier test build of
 "Update to
LibreOffice 7.4.4" for the same libreoffice-7.4.4.2 tag on 2023-01-02 at
 succeeded, so I 
assume
that it must be some change in the meantime to the underlying
org.fedoraproject.sdk//22.08 that started to cause colorized antialiasing 
here.

Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145411
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit 933519505aee0e91ca99af0ed860e4a0f148f922)
Conflicts:
vcl/qa/cppunit/text.cxx

Change-Id: I7059268eabcfe8e501d0be4f38746707def7bb35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145416
Tested-by: Jenkins
Reviewed-by: Michael Stahl 

diff --git a/vcl/qa/cppunit/text.cxx b/vcl/qa/cppunit/text.cxx
index 668e84ef2aad..823ffeabffc7 100644
--- a/vcl/qa/cppunit/text.cxx
+++ b/vcl/qa/cppunit/text.cxx
@@ -79,6 +79,13 @@ public:
 CPPUNIT_TEST_SUITE_END();
 };
 
+// Avoid issues when colorized antialiasing generates slightly tinted rather 
than truly black
+// pixels:
+static bool isBlack(Color col)
+{
+return col.GetRed() < 25 && col.GetGreen() < 25 && col.GetBlue() < 25;
+}
+
 // Return pixel width of the base of the given character located above
 // the starting position.
 // In other words, go up in y direction until a black pixel is found,
@@ -89,7 +96,7 @@ static tools::Long getCharacterBaseWidth(VirtualDevice* 
device, const Point& sta
 Bitmap bitmap = device->GetBitmap(Point(), device->GetOutputSizePixel());
 Bitmap::ScopedReadAccess access(bitmap);
 tools::Long y = start.Y();
-while (y >= 0 && access->GetColor(y, start.X()) != COL_BLACK)
+while (y >= 0 && !isBlack(access->GetColor(y, start.X(
 --y;
 if (y < 0)
 return -1;
@@ -108,7 +115,7 @@ static tools::Long getCharacterTopWidth(VirtualDevice* 
device, const Point& star
 Bitmap bitmap = device->GetBitmap(Point(), device->GetOutputSizePixel());
 Bitmap::ScopedReadAccess access(bitmap);
 tools::Long y = start.Y();
-while (y < bitmap.GetSizePixel().Height() && access->GetColor(y, 
start.X()) != COL_BLACK)
+while (y < bitmap.GetSizePixel().Height() && !isBlack(access->GetColor(y, 
start.X(
 ++y;
 if (y >= bitmap.GetSizePixel().Height())
 return -1;
@@ -129,7 +136,7 @@ static tools::Long 
getCharacterLeftSideHeight(VirtualDevice* device, const Point
 Bitmap bitmap = device->GetBitmap(Point(), device->GetOutputSizePixel());
 Bitmap::ScopedReadAccess access(bitmap);
 tools::Long x = start.X();
-while (x < bitmap.GetSizePixel().Width() && access->GetColor(start.Y(), x) 
!= COL_BLACK)
+while (x < bitmap.GetSizePixel().Width() && 
!isBlack(access->GetColor(start.Y(), x)))
 ++x;
 if (x >= bitmap.GetSizePixel().Width())
 return -1;
@@ -148,7 +155,7 @@ static tools::Long 
getCharacterRightSideHeight(VirtualDevice* device, const Poin
 Bitmap bitmap = device->GetBitmap(Point(), device->GetOutputSizePixel());
 Bitmap::ScopedReadAccess access(bitmap);
 tools::Long x = start.X();
-while (x >= 0 && access->GetColor(start.Y(), x) != COL_BLACK)
+while (x >= 0 && !isBlack(access->GetColor(start.Y(), x)))
 --x;
 if (x < 0)
 return -1;

[Libreoffice-commits] core.git: Branch 'libreoffice-7-4' - vcl/qa vcl/source

[Miklos Vajna (via logerrit)]

 vcl/qa/cppunit/pdfexport/data/bitmap-scaledown.odt |binary
 vcl/qa/cppunit/pdfexport/pdfexport.cxx |   46 ++---
 vcl/source/outdev/bitmapex.cxx |   10 
 3 files changed, 40 insertions(+), 16 deletions(-)

New commits:
commit 95fea9f0453cbe776d711297e9775b3a049b12bd
Author: Miklos Vajna 
AuthorDate: Wed Aug 3 09:44:03 2022 +0200
Commit: Caolán McNamara 
CommitDate: Sun Aug 7 11:24:31 2022 +0200

tdf#149943 vcl: fix pixelated PDF export and print for a rotated image

The bugdoc has a barcode which looks good in Writer, but it's quite
blurry in the PDF export result.

This is a problem since commit dd4a67084853a030bf4b9f1f85d728620e0604a5
(vcl: avoid downscale && upscale in DrawTransformedBitmapEx(),
2019-10-08), where the motivation was to not downscale a bitmap in case
it has a larger amount of pixels but a smaller logic size. This went
wrong here and resulted in a blurry bitmap for a not so small image.

Fix the problem by mostly reverting the above commit, because it's no
longer necessary: 68549e00d5e23aa22bc974a8151d93cd948444b3 (vcl,
BitmapEx transformed draw: special-case simple rotations, 2019-10-10)
already made sure that the rotation case doesn't use scaling from the
transform.

testTdf128630 has been adapted to pass again (after manually verifying
that the bugdoc export result is still OK), now the bad case there
simply produces a smaller bitmap.

(cherry picked from commit 7c94d7267bc8b5f43185204ab4953c4b188214bf)

Change-Id: Ib28881c129a0cf037a96eecd065e5cadede97051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137743
Tested-by: Jenkins
Reviewed-by: Caolán McNamara 

diff --git a/vcl/qa/cppunit/pdfexport/data/bitmap-scaledown.odt 
b/vcl/qa/cppunit/pdfexport/data/bitmap-scaledown.odt
new file mode 100644
index ..da9b167fd9d7
Binary files /dev/null and b/vcl/qa/cppunit/pdfexport/data/bitmap-scaledown.odt 
differ
diff --git a/vcl/qa/cppunit/pdfexport/pdfexport.cxx 
b/vcl/qa/cppunit/pdfexport/pdfexport.cxx
index 03aed3112d64..fb821ae4 100644
--- a/vcl/qa/cppunit/pdfexport/pdfexport.cxx
+++ b/vcl/qa/cppunit/pdfexport/pdfexport.cxx
@@ -1638,7 +1638,7 @@ CPPUNIT_TEST_FIXTURE(PdfExportTest, testTdf128630)
 // The document has one page.
 CPPUNIT_ASSERT_EQUAL(1, pPdfDocument->getPageCount());
 
-// Assert the aspect ratio of the only bitmap on the page.
+// Assert the size of the only bitmap on the page.
 std::unique_ptr pPdfPage = 
pPdfDocument->openPage(/*nIndex=*/0);
 CPPUNIT_ASSERT(pPdfPage);
 int nPageObjectCount = pPdfPage->getObjectCount();
@@ -1651,12 +1651,13 @@ CPPUNIT_TEST_FIXTURE(PdfExportTest, testTdf128630)
 std::unique_ptr pBitmap = 
pPageObject->getImageBitmap();
 CPPUNIT_ASSERT(pBitmap);
 int nWidth = pBitmap->getWidth();
-int nHeight = pBitmap->getHeight();
 // Without the accompanying fix in place, this test would have failed 
with:
-// assertion failed
-// - Expression: nWidth != nHeight
-// i.e. the bitmap lost its custom aspect ratio during export.
-CPPUNIT_ASSERT(nWidth != nHeight);
+// - Expected: 466
+// - Actual  : 289
+// i.e. the rotated + scaled arrow was more thin than it should be.
+CPPUNIT_ASSERT_EQUAL(466, nWidth);
+int nHeight = pBitmap->getHeight();
+CPPUNIT_ASSERT_EQUAL(466, nHeight);
 }
 }
 
@@ -3451,6 +3452,39 @@ CPPUNIT_TEST_FIXTURE(PdfExportTest, 
testPdfImageEncryption)
 // missing encryption.
 CPPUNIT_ASSERT_EQUAL(2, pPageObject->getFormObjectCount());
 }
+
+CPPUNIT_TEST_FIXTURE(PdfExportTest, testBitmapScaledown)
+{
+// Given a document with an upscaled and rotated barcode bitmap in it:
+aMediaDescriptor["FilterName"] <<= OUString("writer_pdf_Export");
+
+// When saving as PDF:
+saveAsPDF(u"bitmap-scaledown.odt");
+
+// Then verify that the bitmap is not downscaled:
+std::unique_ptr pPdfDocument = parseExport();
+CPPUNIT_ASSERT(pPdfDocument);
+CPPUNIT_ASSERT_EQUAL(1, pPdfDocument->getPageCount());
+std::unique_ptr pPdfPage = 
pPdfDocument->openPage(/*nIndex=*/0);
+CPPUNIT_ASSERT(pPdfPage);
+int nPageObjectCount = pPdfPage->getObjectCount();
+for (int i = 0; i < nPageObjectCount; ++i)
+{
+std::unique_ptr pPageObject = 
pPdfPage->getObject(i);
+if (pPageObject->getType() != vcl::pdf::PDFPageObjectType::Image)
+continue;
+
+std::unique_ptr pBitmap = 
pPageObject->getImageBitmap();
+CPPUNIT_ASSERT(pBitmap);
+// In-file sizes: good is 2631x380, bad is 1565x14.
+int nWidth = pBitmap->getWidth();
+// Without the accompanying fix in place, this test would have failed 
with:
+// - Expected: 2616
+// - Actual  : 1565
+// i.e. the bitmap in the pdf result was small enough to be blurry.
+ 

[Libreoffice-commits] core.git: Branch 'libreoffice-7-4' - vcl/qa

[Stephan Bergmann (via logerrit)]

 vcl/qa/cppunit/svm/svmtest.cxx |   14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

New commits:
commit 095a10a13569195121bedb08ef6afc0e63befc57
Author: Stephan Bergmann 
AuthorDate: Tue Jul 19 10:07:57 2022 +0200
Commit: Michael Stahl 
CommitDate: Thu Aug 4 15:01:28 2022 +0200

Fix endian-dependent test for good

SvmTest::testComment introduced in e10df88b8ae4138862d4dd25c221189878641aa4 
"Add
Comment cppunit test to vcl" calls SvmTest::checkComment twice, first for a
programmatically generated svm document, and then for the canned
vcl/qa/cppunit/svm/data/comment.svm.  
4f533655dd635dab30574c2a3b3915377124bd60
"this test is endian-dependant" had fixed the endian-dependent check in
SvmTest::checkComment for the first, programmatically generated case, but 
broke
it for the second, canned case.  As seen on s390x:

> xmltesttools.cxx:171:Assertion
> Test name: SvmTest::testComment
> equality assertion failed
> - Expected: 
00540068006500730065002000610072006500200073006f006d00650020007400650073007400200064006100740061
> - Actual  : 
540068006500730065002000610072006500200073006f006d0065002000740065007300740020006400610074006100
> - In <>, attribute 'data' of '/metafile/comment[2]' incorrect value.

So just not make the problematic MetaCommentAction payload endian-dependent 
in
the first place.  (And one wonders why the test even needs to test such a
problematic payload.)

Change-Id: I203dae6545e0d4e63e7c2d521a27c661e1cf633c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137223
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit f9902fc13aaf2c4614125d78c653435ae454de3a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137728
Reviewed-by: Michael Stahl 

diff --git a/vcl/qa/cppunit/svm/svmtest.cxx b/vcl/qa/cppunit/svm/svmtest.cxx
index 9374e9916772..9356b8f5ad6a 100644
--- a/vcl/qa/cppunit/svm/svmtest.cxx
+++ b/vcl/qa/cppunit/svm/svmtest.cxx
@@ -2244,15 +2244,9 @@ void SvmTest::checkComment(const GDIMetaFile& rMetafile)
 {"datasize", "48"}
 });
 
-#ifdef OSL_LITENDIAN
 assertXPathAttrs(pDoc, "/metafile/comment[2]", {
 {"data", 
"540068006500730065002000610072006500200073006f006d0065002000740065007300740020006400610074006100"}
 });
-#else
-assertXPathAttrs(pDoc, "/metafile/comment[2]", {
-{"data", 
"00540068006500730065002000610072006500200073006f006d00650020007400650073007400200064006100740061"}
-});
-#endif
 
 assertXPathAttrs(pDoc, "/metafile/comment[2]", {
 {"value", "4"}
@@ -2269,11 +2263,13 @@ void SvmTest::testComment()
 
 aGDIMetaFile.AddAction(new MetaCommentAction("Test comment"));
 
-OUString aString = "These are some test data";
+using namespace std::literals::string_view_literals;
+static constexpr auto aString
+= "T\0h\0e\0s\0e\0 \0a\0r\0e\0 \0s\0o\0m\0e\0 \0t\0e\0s\0t\0 
\0d\0a\0t\0a\0"sv;
 aGDIMetaFile.AddAction(new MetaCommentAction("This is a test comment", \
 4, \
-reinterpret_cast(aString.getStr()), \
-2*aString.getLength() ));
+reinterpret_cast(aString.data()), \
+aString.length() ));
 
 checkComment(writeAndReadStream(aGDIMetaFile));
 checkComment(readFile(u"comment.svm"));

[Libreoffice-commits] core.git: Branch 'libreoffice-7-4' - vcl/qa

[Stephan Bergmann (via logerrit)]

 vcl/qa/cppunit/svm/svmtest.cxx |   28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

New commits:
commit 0bec3cadcdc5994692581a4fb716b4a152af416e
Author: Stephan Bergmann 
AuthorDate: Wed Jul 20 17:44:57 2022 +0200
Commit: Michael Stahl 
CommitDate: Thu Aug 4 14:55:26 2022 +0200

Fix CppunitTest_vcl_svm_test for big endian

These crc values are the results of Bitmap::GetChecksum() calls, and for
headless Linux the formats of those bitmaps (ScanlineFormat::N24BitTcBgr |
ScanlineFormat::TopDown vs. ScanlineFormat::N24BitTcRgb |
ScanlineFormat::TopDown) depend on little vs. big endian (see the 
definition of
SVP_24BIT_FORMAT in vcl/inc/headless/CairoCommon.hxx), so these tests 
failed on
big endian Linux s390x.

So I updated the tests with whatever values I got reported on s390x, 
whether or
not those values are actually correct...

Change-Id: I05d2b656ae2e0cf00cd870b895e1bf3cb9cf82f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137270
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit eea7038c182cc1f6cd792359053ea2561a200026)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137727
Reviewed-by: Michael Stahl 

diff --git a/vcl/qa/cppunit/svm/svmtest.cxx b/vcl/qa/cppunit/svm/svmtest.cxx
index 91c9128278a7..9374e9916772 100644
--- a/vcl/qa/cppunit/svm/svmtest.cxx
+++ b/vcl/qa/cppunit/svm/svmtest.cxx
@@ -12,6 +12,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -937,14 +938,26 @@ void SvmTest::checkBitmaps(const GDIMetaFile& rMetaFile)
 if (SkiaHelper::isVCLSkiaEnabled())
 return; // TODO SKIA using CRCs is broken (the idea of it)
 
-assertXPathAttrs(pDoc, "/metafile/bmp[1]", {{"x", "1"}, {"y", "2"}, 
{"crc", "b8dee5da"}});
+assertXPathAttrs(pDoc, "/metafile/bmp[1]", {{"x", "1"}, {"y", "2"}, {"crc",
+#if defined OSL_BIGENDIAN
+"5e01ddcc"
+#else
+"b8dee5da"
+#endif
+}});
 assertXPathAttrs(pDoc, "/metafile/bmpscale[1]", {
 {"x", "1"}, {"y", "2"}, {"width", "3"}, {"height", "4"}, {"crc", 
"281fc589"}
 });
 assertXPathAttrs(pDoc, "/metafile/bmpscalepart[1]", {
 {"destx", "1"}, {"desty", "2"}, {"destwidth", "3"}, {"destheight", 
"4"},
 {"srcx", "2"},  {"srcy", "1"},  {"srcwidth", "4"},  {"srcheight", "3"},
-{"crc", "5e01ddcc"}
+{"crc",
+#if defined OSL_BIGENDIAN
+ "b8dee5da"
+#else
+ "5e01ddcc"
+#endif
+}
 });
 }
 
@@ -995,6 +1008,16 @@ void SvmTest::checkBitmapExs(const GDIMetaFile& rMetaFile)
 std::vector aExpectedCRC;
 aExpectedCRC.insert(aExpectedCRC.end(),
 {
+#if defined OSL_BIGENDIAN
+"08feb5d3",
+"281fc589",
+"b8dee5da",
+"4df0e464",
+"186ff868",
+"33b4a07c", // 4-bit color bitmap - same as 8-bit color bitmap
+"33b4a07c",
+"742c3e35",
+#else
 "d8377d4f",
 "281fc589",
 "5e01ddcc",
@@ -1003,6 +1026,7 @@ void SvmTest::checkBitmapExs(const GDIMetaFile& rMetaFile)
 "3c80d829", // 4-bit color bitmap - same as 8-bit color bitmap
 "3c80d829",
 "71efc447",
+#endif
 });
 
 assertXPathAttrs(pDoc, "/metafile/bmpex[1]", {