mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c22cb6f2a566232c57194eadb02f46aebda4c3ca
libreoffice/vcl/qa/cppunit/logicalfontinstance.cxx

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

112 lines
4.2 KiB
C++
Raw Normal View History

vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
#include <sal/config.h>
#include <test/bootstrapfixture.hxx>
#include <cppunit/TestAssert.h>
#include <vcl/virdev.hxx>
#include <vcl/font.hxx>
#include <font/LogicalFontInstance.hxx>
#include <memory>
class VclLogicalFontInstanceTest : public test::BootstrapFixture
{
public:
VclLogicalFontInstanceTest()
: BootstrapFixture(true, false)
{
}
void testglyphboundrect();
CPPUNIT_TEST_SUITE(VclLogicalFontInstanceTest);
CPPUNIT_TEST(testglyphboundrect);
CPPUNIT_TEST_SUITE_END();
};
void VclLogicalFontInstanceTest::testglyphboundrect()
{
improve readability of VirtualDevice constructor (a) It is not obvious what DeviceFormat::DEFAULT means (b) There are two parameters (each with two states), but only really 2 possible overall states So (1) use more useful names (2) combine the two parameters into one enum Change-Id: Ic0595b39e032cc9e019b88326389d055b977da00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-06 18:14:16 +02:00
ScopedVclPtr<VirtualDevice> device = VclPtr<VirtualDevice>::Create(DeviceFormat::WITHOUT_ALPHA);
vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
device->SetOutputSizePixel(Size(1000, 1000));
loplugin:ostr in vcl Change-Id: I5b6ee5bda0c5ff69d297f7f8e87d4c3f3d21791c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167470 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-10 13:19:35 +02:00
vcl::Font font(u"Liberation Sans"_ustr, Size(0, 110));
tdf#160430: Fix glyph bounds calculation, and use basegfx::B2DRectangle ... instead of tools::Rectangle. Several problems were there: 1. First, a horizontal bounding rectangle was calculated, with due rounding; and then the result was rotated, and after that, rounded again. That made the resulting rotated rectangle coordinates very imprecise. 2. Also, ceil/floor was applied without normalization; and in case of rotated font, that meant, that sometimes the range could be not expanded to cover partially covered pixels, but instead collapsed. 3. The rotation to angles other than 90 degree multiples was done incorrectly, resulting in cut off parts of characters. 4. For 90 degrees, the imprecise result of sin/cos converted 0.0 into values like 3e-16, which then could be ceil'ed up to 1. Using B2DRectangle and its transform allows to simplify and fix the calculations easily, and avoids premature rounding. Render of rotated text of small size is more stable with this change. Change-Id: Idffd74b9937feb2418ab76a8d325fdaf4ff841b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165553 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-29 20:15:06 +05:00
device->SetFont(font);
vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
const LogicalFontInstance* pFontInstance = device->GetFontInstance();
tdf#160430: Fix glyph bounds calculation, and use basegfx::B2DRectangle ... instead of tools::Rectangle. Several problems were there: 1. First, a horizontal bounding rectangle was calculated, with due rounding; and then the result was rotated, and after that, rounded again. That made the resulting rotated rectangle coordinates very imprecise. 2. Also, ceil/floor was applied without normalization; and in case of rotated font, that meant, that sometimes the range could be not expanded to cover partially covered pixels, but instead collapsed. 3. The rotation to angles other than 90 degree multiples was done incorrectly, resulting in cut off parts of characters. 4. For 90 degrees, the imprecise result of sin/cos converted 0.0 into values like 3e-16, which then could be ceil'ed up to 1. Using B2DRectangle and its transform allows to simplify and fix the calculations easily, and avoids premature rounding. Render of rotated text of small size is more stable with this change. Change-Id: Idffd74b9937feb2418ab76a8d325fdaf4ff841b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165553 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-29 20:15:06 +05:00
basegfx::B2DRectangle aBoundRect;
vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
const auto LATIN_SMALL_LETTER_B = 0x0062;
tdf#160436: fix glyph bounds calculation for vertical glyphs It is unclear if LogicalFontInstance::GetGlyphBoundRect can be called for both normal and rotated variants of the same glyph in the same font. If yes, then the normal and vertical variants must be cached separately, or possibly vertical variant can be not cached, but always calculated. This problem already existed before, so this change doesn't introduce a new issue. Change-Id: I9b50ef340c9e38db7bef890165519aadc96d3ffa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165581 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-31 00:45:25 +05:00
const auto SECTION_SIGN = 0x00A7; // UTR#50: Vertical_Orientation (vo) property value U
vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
pFontInstance->GetGlyphBoundRect(pFontInstance->GetGlyphIndex(LATIN_SMALL_LETTER_B), aBoundRect,
false);
tdf#160430: Fix glyph bounds calculation, and use basegfx::B2DRectangle ... instead of tools::Rectangle. Several problems were there: 1. First, a horizontal bounding rectangle was calculated, with due rounding; and then the result was rotated, and after that, rounded again. That made the resulting rotated rectangle coordinates very imprecise. 2. Also, ceil/floor was applied without normalization; and in case of rotated font, that meant, that sometimes the range could be not expanded to cover partially covered pixels, but instead collapsed. 3. The rotation to angles other than 90 degree multiples was done incorrectly, resulting in cut off parts of characters. 4. For 90 degrees, the imprecise result of sin/cos converted 0.0 into values like 3e-16, which then could be ceil'ed up to 1. Using B2DRectangle and its transform allows to simplify and fix the calculations easily, and avoids premature rounding. Render of rotated text of small size is more stable with this change. Change-Id: Idffd74b9937feb2418ab76a8d325fdaf4ff841b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165553 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-29 20:15:06 +05:00
CPPUNIT_ASSERT_DOUBLES_EQUAL(7.1, aBoundRect.getMinX(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-79.7, aBoundRect.getMinY(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(49.5, aBoundRect.getWidth(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(80.8, aBoundRect.getHeight(), 0.05);
vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
tdf#160436: fix glyph bounds calculation for vertical glyphs It is unclear if LogicalFontInstance::GetGlyphBoundRect can be called for both normal and rotated variants of the same glyph in the same font. If yes, then the normal and vertical variants must be cached separately, or possibly vertical variant can be not cached, but always calculated. This problem already existed before, so this change doesn't introduce a new issue. Change-Id: I9b50ef340c9e38db7bef890165519aadc96d3ffa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165581 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-31 00:45:25 +05:00
// tdf#160436: test vertically oriented glyphs
pFontInstance->GetGlyphBoundRect(pFontInstance->GetGlyphIndex(SECTION_SIGN), aBoundRect, true);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-79.7, aBoundRect.getMinX(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-55.0, aBoundRect.getMinY(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(88.9, aBoundRect.getWidth(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(48.8, aBoundRect.getHeight(), 0.05);
tdf#160430: Fix glyph bounds calculation, and use basegfx::B2DRectangle ... instead of tools::Rectangle. Several problems were there: 1. First, a horizontal bounding rectangle was calculated, with due rounding; and then the result was rotated, and after that, rounded again. That made the resulting rotated rectangle coordinates very imprecise. 2. Also, ceil/floor was applied without normalization; and in case of rotated font, that meant, that sometimes the range could be not expanded to cover partially covered pixels, but instead collapsed. 3. The rotation to angles other than 90 degree multiples was done incorrectly, resulting in cut off parts of characters. 4. For 90 degrees, the imprecise result of sin/cos converted 0.0 into values like 3e-16, which then could be ceil'ed up to 1. Using B2DRectangle and its transform allows to simplify and fix the calculations easily, and avoids premature rounding. Render of rotated text of small size is more stable with this change. Change-Id: Idffd74b9937feb2418ab76a8d325fdaf4ff841b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165553 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-29 20:15:06 +05:00
font.SetOrientation(900_deg10);
device->SetFont(font);
pFontInstance = device->GetFontInstance();
pFontInstance->GetGlyphBoundRect(pFontInstance->GetGlyphIndex(LATIN_SMALL_LETTER_B), aBoundRect,
false);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-79.7, aBoundRect.getMinX(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-56.6, aBoundRect.getMinY(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(80.8, aBoundRect.getWidth(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(49.5, aBoundRect.getHeight(), 0.05);
tdf#160436: fix glyph bounds calculation for vertical glyphs It is unclear if LogicalFontInstance::GetGlyphBoundRect can be called for both normal and rotated variants of the same glyph in the same font. If yes, then the normal and vertical variants must be cached separately, or possibly vertical variant can be not cached, but always calculated. This problem already existed before, so this change doesn't introduce a new issue. Change-Id: I9b50ef340c9e38db7bef890165519aadc96d3ffa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165581 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-31 00:45:25 +05:00
// tdf#160436: test vertically oriented glyphs
pFontInstance->GetGlyphBoundRect(pFontInstance->GetGlyphIndex(SECTION_SIGN), aBoundRect, true);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-55.0, aBoundRect.getMinX(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-9.2, aBoundRect.getMinY(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(48.8, aBoundRect.getWidth(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(88.9, aBoundRect.getHeight(), 0.05);
tdf#160430: Fix glyph bounds calculation, and use basegfx::B2DRectangle ... instead of tools::Rectangle. Several problems were there: 1. First, a horizontal bounding rectangle was calculated, with due rounding; and then the result was rotated, and after that, rounded again. That made the resulting rotated rectangle coordinates very imprecise. 2. Also, ceil/floor was applied without normalization; and in case of rotated font, that meant, that sometimes the range could be not expanded to cover partially covered pixels, but instead collapsed. 3. The rotation to angles other than 90 degree multiples was done incorrectly, resulting in cut off parts of characters. 4. For 90 degrees, the imprecise result of sin/cos converted 0.0 into values like 3e-16, which then could be ceil'ed up to 1. Using B2DRectangle and its transform allows to simplify and fix the calculations easily, and avoids premature rounding. Render of rotated text of small size is more stable with this change. Change-Id: Idffd74b9937feb2418ab76a8d325fdaf4ff841b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165553 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-29 20:15:06 +05:00
font.SetOrientation(450_deg10);
device->SetFont(font);
pFontInstance = device->GetFontInstance();
pFontInstance->GetGlyphBoundRect(pFontInstance->GetGlyphIndex(LATIN_SMALL_LETTER_B), aBoundRect,
false);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-51.3, aBoundRect.getMinX(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-96.4, aBoundRect.getMinY(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(92.1, aBoundRect.getWidth(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(92.1, aBoundRect.getHeight(), 0.05);
tdf#160436: fix glyph bounds calculation for vertical glyphs It is unclear if LogicalFontInstance::GetGlyphBoundRect can be called for both normal and rotated variants of the same glyph in the same font. If yes, then the normal and vertical variants must be cached separately, or possibly vertical variant can be not cached, but always calculated. This problem already existed before, so this change doesn't introduce a new issue. Change-Id: I9b50ef340c9e38db7bef890165519aadc96d3ffa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165581 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-31 00:45:25 +05:00
// tdf#160436: test vertically oriented glyphs
pFontInstance->GetGlyphBoundRect(pFontInstance->GetGlyphIndex(SECTION_SIGN), aBoundRect, true);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-95.3, aBoundRect.getMinX(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(-45.4, aBoundRect.getMinY(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(97.4, aBoundRect.getWidth(), 0.05);
CPPUNIT_ASSERT_DOUBLES_EQUAL(97.4, aBoundRect.getHeight(), 0.05);
vcl: test getting glyph boundary rect from LogicalFontInstance MacOS produces a slightly different glyph height. Quoting from Khaled in dev IRC: "Currently GetGlyphBoundRect() calls different platform-specific implementations on each platform, so even with the same font it is possible to get some difference. So my suggestion is to use a large font size and allow for some fuzziness". Consequently I'm using a 110pt font, and taking into account some fuzziness. Change-Id: I0dace6bfa0d1f4e6f3b8852e957d2d518d37795b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143322 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-19 11:20:19 +02:00
}
CPPUNIT_TEST_SUITE_REGISTRATION(VclLogicalFontInstanceTest);
/* vim:set shiftwidth=4 softtabstop=4 expandtab cinoptions=b1,g0,N-s cinkeys+=0=break: */
Reference in New Issue Copy Permalink