For Mac version, is it possible to build language packages directly into main package?
Hi all, For Mac version, currently released packages are a main package (LibreOffice_24.0.3_MacOS_x86-64.dmg) and different language packages (LibreOffice_24.0.3_MacOS_x86-64_langpack_*.dmg). But it is really difficult to install those packages in a MacOS system and caused a lot of complaints from our customers. We are thinking if it is possible to build a main packages with certain language pack (for example, en and zh_TW) into it to form ONE dmg package instead of three? If yes, what options should we use when compiling? If not, is there any other solution for that, to simplify the installation on a MacOS system? Thanks, Dev
core.git: sc/source
sc/source/filter/xml/xmlwrap.cxx | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
New commits:
commit e91290190e4b2ef3cc07efb2bda42ea37b246354
Author: Lodev
AuthorDate: Tue Dec 5 14:27:17 2023 +0800
Commit: Mike Kaganski
CommitDate: Tue Dec 12 10:47:42 2023 +0100
tdf#158388 Allow user to open ODS file with corrupted meta.xml &
settings.xml
1. Follow sd/sw module to give corrupted meta.xml and settings.xml only
warnings instead of blocking user to open.
2. only set rError after all the if's and Removing the unnecessary bRet
assignment
Change-Id: I6dd6acd919d1fbec91ef4a0d0e78623f0c65dc40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160605
Reviewed-by: Mike Kaganski
Tested-by: Mike Kaganski
diff --git a/sc/source/filter/xml/xmlwrap.cxx b/sc/source/filter/xml/xmlwrap.cxx
index 9794af9593a1..a701b6e913f5 100644
--- a/sc/source/filter/xml/xmlwrap.cxx
+++ b/sc/source/filter/xml/xmlwrap.cxx
@@ -518,24 +518,16 @@ bool ScXMLImportWrapper::Import( ImportFlags nMode,
ErrCodeMsg& rError )
if (xStatusIndicator.is())
xStatusIndicator->end();
-bool bRet = false;
if (nDocRetval)
-{
rError = nDocRetval;
-if (nDocRetval == SCWARN_IMPORT_RANGE_OVERFLOW ||
-nDocRetval == SCWARN_IMPORT_ROW_OVERFLOW ||
-nDocRetval == SCWARN_IMPORT_COLUMN_OVERFLOW ||
-nDocRetval == SCWARN_IMPORT_SHEET_OVERFLOW)
-bRet = true;
-}
else if (nStylesRetval)
rError = nStylesRetval;
else if (nMetaRetval)
rError = nMetaRetval;
else if (nSettingsRetval)
rError = nSettingsRetval;
-else
-bRet = true;
+
+bool bRet = !rError.IsError();
::svx::DropUnusedNamedItems(xModel);
Re: #tdf51510: Change the DPI to get better resolution, but failed the unit test
Hi,
Following sos' suggestion, we tried to get Image Preferred DPI from file
properties. We thought to use this value directly to draw bitmap.
After asking the last question we found a sample in
sfx2/source/dialog/dinfdlg.cxx to get this property value. So we added
the following code to get the DPI:
/* get Image Preferred DPI from File/Properties. User can specify DPI
they wanted
* to exported. */
SfxObjectShell* pDocSh = SfxObjectShell::Current();
sal_Int32 nImagePreferredDPI = 0;
if(pDocSh)
{
try
{
uno::Reference< lang::XMultiServiceFactory >
xFac( pDocSh->GetModel(), uno::
UNO_QUERY_THROW );
uno::Reference< beans::XPropertySet >
xProps( xFac->createInstance("com.sun.
star.document.Settings"), uno::UNO_QUERY_THROW );
xProps->getPropertyValue("ImagePreferredDPI") >>=
nImagePreferredDPI;
}
catch( uno::Exception& )
{
}
}
then sent the nImagePreferredDPI to generate the bitmap. It worked! At
least we can use designated DPI to get a better bitmap quality.
Then when we tried to patch it to latest libreoffice.core and compile
it, it failed to link:
/usr/bin/ld:
/home/lodev/git/libreoffice.core/workdir/CxxObject/vcl/source/gdi/vectorgraphicdata.o:
in function
`convertPrimitive2DSequenceToBitmapEx(std::deque,
std::allocator
> > const&, basegfx::B2DRange const&, unsigned int, o3tl::Length,
std::optional const&)':
vectorgraphicdata.cxx:(.text+0x226d): undefined reference to
`SfxObjectShell::Current()'
/usr/bin/ld: vectorgraphicdata.cxx:(.text+0x228f): undefined reference
to `SfxObjectShell::GetModel() const'
collect2: error: ld returned 1 exit status
make[1]: ***
[/home/lodev/git/libreoffice.core/vcl/Library_vcl.mk:20：/home/lodev/git/libreoffice.core/instdir/program/libvcllo.so]
錯誤 1
We thought that the time we succeeded should be because the related
objects (sfx2) had been there when we tried, so it could compiled and
linked successfully. This time we did it from starting so it failed
because the object files were no longer there, and we have no idea how
to make sfx objects compile first.
So again we're stuck. We did prove the idea, using Image Preferred DPI
to generate better bitmap, works. User can specify a bigger DPI there
to get better bitmap resolutions after exporting to OOXML. Just that
maybe we shouldn't use sfx object to get the property. But we have no
idea how to get the property value since we're not very familiar with
the reference things.
Would anyone please give a little help and hints here?
Thanks, Dev
Lodev 於 2023/9/11 21:32 寫道:
Hi,
sos 於 2023/8/31 17:53 寫道:
Sorry to come back to this: every document has a property called
"Image Preferred DPI" that can be used to represent the printing
intentions of that document.
Apparent dimensions are a result of deviding the available pixels in
the Image by the print intentions .
if the user like to send the document to a professional printing
house then all images need to have a DPI of minimal 254, laser
printers need 150 DPI and on screen presentations 96 DPI
Tomaz has this implemented a feature called "Image Preferred DPI" so
the dimensions of an image in the document can been
checked/controled by the number of pixels in the image and the print
intentions off a document.
With a Preferred DPI of 254 and 2450 pixels in the image, the image
can be displayed at a maximum size of 10 inches. If the image is
smaller, then fewer than 2450 pixels are needed.
So the "Image Preferred DPI" can be used to determine the "Print
Intentions" for a Document, and it can easily calculate how many DPI
or pixels an image needs.
grtz
Fernand
Sorry for disturbing again, but we're not experienced enough.
Following your instruction, we thought about getting the "Image
Preferred DPI" property and used it as aDPI when creating bitmaps.
That way, at least user could try to assign a large DPI to get better
resolution. However we failed to find out how to get it. We know it
is in File-Properties and we know it is set in
sfx2/source/dialog/dinfdlg.cxx,
xProps->setPropertyValue("ImagePreferredDPI",
uno::Any(nImagePreferredDPI));
But we couldn't find out how to get this "ImagePreferredDPI" property
value and use it in vcl/source/gdi/vectorgraphicdata.cxx. A little
more help here please?
Dev
Re: #tdf51510: Change the DPI to get better resolution, but failed the unit test
Hi,
sos 於 2023/8/31 17:53 寫道:
Sorry to come back to this: every document has a property called
"Image Preferred DPI" that can be used to represent the printing
intentions of that document.
Apparent dimensions are a result of deviding the available pixels in
the Image by the print intentions .
if the user like to send the document to a professional printing house
then all images need to have a DPI of minimal 254, laser printers
need 150 DPI and on screen presentations 96 DPI
Tomaz has this implemented a feature called "Image Preferred DPI" so
the dimensions of an image in the document can been checked/controled
by the number of pixels in the image and the print intentions off a
document.
With a Preferred DPI of 254 and 2450 pixels in the image, the image
can be displayed at a maximum size of 10 inches. If the image is
smaller, then fewer than 2450 pixels are needed.
So the "Image Preferred DPI" can be used to determine the "Print
Intentions" for a Document, and it can easily calculate how many DPI
or pixels an image needs.
grtz
Fernand
Sorry for disturbing again, but we're not experienced enough.
Following your instruction, we thought about getting the "Image
Preferred DPI" property and used it as aDPI when creating bitmaps. That
way, at least user could try to assign a large DPI to get better
resolution. However we failed to find out how to get it. We know it is
in File-Properties and we know it is set in sfx2/source/dialog/dinfdlg.cxx,
xProps->setPropertyValue("ImagePreferredDPI",
uno::Any(nImagePreferredDPI));
But we couldn't find out how to get this "ImagePreferredDPI" property
value and use it in vcl/source/gdi/vectorgraphicdata.cxx. A little more
help here please?
Dev
Confusing unit test error
Hi,
We sent a patch to gerrit. Before sending it we did "make sw.check" and
passed. But after submitting Jenkins reported a unit test error. So we
tried to "make check" again.
It failed, but not the way Jenkins reported.
[CUT]i18npool_transliteration
[_RUN_] (anonymous namespace)::IndexEntry::testJapanese
unknown:0:(anonymous namespace)::IndexEntry::testJapanese
An uncaught exception of type
com.sun.star.loader.CannotActivateFactoryException
- no constructor symbol
"i18npool_IndexEntrySupplier_ja_phonetic_alphanumeric_first_by_consonant_get_imp
lementation" in component library
at
/opt/git/libreoffice.core/cppuhelper/source/shlib.cxx:344
(anonymous namespace)::IndexEntry::testJapanese finished in: 4ms
##Failure Location unknown## : Error
Test name: (anonymous namespace)::IndexEntry::testJapanese
An uncaught exception of type
com.sun.star.loader.CannotActivateFactoryException
- no constructor symbol
"i18npool_IndexEntrySupplier_ja_phonetic_alphanumeric_first_by_consonant_get_imp
lementation" in component library
at
/opt/git/libreoffice.core/cppuhelper/source/shlib.cxx:344
Failures !!!
Run: 1 Failure total: 1 Failures: 0 Errors: 1
on Jenkins https://ci.libreoffice.org/job/gerrit_master_ml/2094/ the
error was:
Execution time for tdf147755.Tdf147755.test_tdf147755: 0.866
close
FAIL
==
FAIL: test_tdf147755 (tdf147755.Tdf147755)
--
Traceback (most recent call last):
File
"/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/uitest/math_tests/tdf147755.py",
line 30, in test_tdf147755
self.assertEqual("%ALPHA ", get_state_as_dict(xEditView)["Text"])
AssertionError: '%ALPHA ' != '%ALPHA'
- %ALPHA
? -
+ %ALPHA
--
Ran 5 tests in 9.984s
FAILED (failures=1)
Tests run: 5
Tests failed: 1
Tests errors: 0
Tests skipped: 0
tearDown: calling terminate()...
...done
Either one we have no idea what to do and how to solve it. Could anyone
please give us some hints and advice?
Thanks, Dev
What is the "dynamic" flag in errcode?
Hi, In the ErrCode definition (include/comphelper/errcode.hxx) error codes are defined as a 32-bit integer. There is a "Dynamic" area in bit 30-26. Also in ErrCode class it defines some methods like isDynamic(), StripDynamic(), ... etc. But we didn't find any comments or documents saying what this "Dynamic" flags means, and didn't find where this flag is set. We're looking at an issue about an ods file with empty meta.xml. The return errcode was SCWARN_IMPORT_FILE_ROWCOL but the Dynamic flag was set, but we couldn't find where and why it was set. Would anyone please tell me about this dynamic flag/area? Thanks, Dev
Re: #tdf51510: Change the DPI to get better resolution, but failed the unit test
Hi, Tomaž Vajngerl 於 2023/8/31 03:13 寫道: Hi, On Tue, Aug 29, 2023 at 9:09 AM Lodev wrote: Sorry if I'm asking a stupid question here. First, I've never seen or used a document with "multiple instances that all point to the same image in the document". That's easy - drag the image while holding ctrl and drop. It will make a copy of the Graphic, but it still references the same instance and you can resize each one independently. If you save the document there will be only one image saved. Thanks. And I take "the image in the document" or "The size the image takes up in the document" seems to be the "Apparent dimensions", 4.24" in this case. Is it? Yes - the document has a size and combined with the size of the image (in the document, not what it is set in SVG) you can calculate the actual needed DPI relative to the document. That is, even if there are multiple images in this document which the source is the same one (I still don't know how to do that), shouldn't it be calculated regarding to the "Apparent dimensions" here? I mean, after all, that is what user set in the document. That's the point - what is important is the size of the image in the document, not what the size is the SVG image. Since the image shown in the document is actually 4.24"x4.24", while the original svg file is 0.21"x0.21, shouldn't it be 20 times (4.24/0.21 ~= 20) DPI, that is, 96*20 = 1920 sent to xBitmap()? Yes, that seems correct. But this is only for this case - another case would need another factor. For example if you resize the image in the document to 0.42 x 0.42, you would use the factor 2. We tried to set Size(20,20) to get aDPI, or directly set aDPI to (1920,1920), they both ended up 4.24"x4.24" with 99DPI, which is good enough. Do you think it a reasonable thought? That's only for this image where 20 is correct - you would need another number calculated per image. Also use a constant DPI factor as I already said at the beginning, not the size of the output device. So you will need to first find the place where conversion for the embedded PNG and properly calculate the size at that place - not inside this method. The size should be the Apparent dimensions, since in the document it was set to that size. That's what we thought. Yes - it needs to be the size in the document, not the size of SVG. BTW, if so, how can we get the Apparent dimensions in this method? You will have to set it from the outside as a parameter - as it depends on the image and here you don't have the information. So, that's what we thought - to calculate the necessary DPI by Apparent dimensions every time we export to docx. Could you please give us some hint about where to get the Apparent dimensions? It's not very trivial to us. We'd like to give it a try to provide a patch for this issue. Thanks for your help, Dev
Re: #tdf51510: Change the DPI to get better resolution, but failed the unit test
Tomaž Vajngerl 於 2023/8/22 20:17 寫道:
Hi,
On Mon, Aug 21, 2023 at 10:30 PM Lodev wrote:
In fact, when we were doing more test, we found the behavior somewhat strange.
We used attachment 170646 in tdf#51510.
vcl/source/gdi/vectorgraphicdata.cxx, line 77:
// get system DPI
Size aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1,
1), MapMode(MapUnit::MapInch)));
if (rTargetDPI.has_value())
{
aDPI = *rTargetDPI;
}
const uno::Reference< rendering::XBitmap > xBitmap(
xPrimitive2DRenderer->rasterize(
comphelper::containerToSequence(rSequence),
aViewParameters,
aDPI.getWidth(),
aDPI.getHeight(),
aRealRect,
nMaximumQuadraticPixels));
First, Size aDPI: Application::GetDefaultDevice()->LogicToPixel(Size(1,1),
MapMode(MapUnit::MapInch)), here we did get aDPI is (96, 96).
However, after saving as docx, the PNG image information (in Compress Image
dialog) we got is:
Actual dimensions: 0.21"x0.21" (21x21 px)
Apparent dimensions: 4.24" x 4.24" at 4 DPI
If we set LogicToPixel(Size(4,4), ...), we got:
Actual dimensions: 0.84"x0.84" (84x84 px)
Apparent dimensions: 4.24" x 4.24" at 19 DPI
Ah yes - I think I know what's the issue. For example if you have a
small SVG file that has a size of 1" by 1" (you can specify that
exactly for a SVG file) and you import that into LO, you probably want
to increase its size to something bigger inside the document (for
example you increase it to 10" x 10" for simplicity), which you can
freely do as the SVG image is a vector image and it will still look
good.
However, this calculation here is not performed compared to the size
the image is taking up in the document (10" x 10"), but compared to
its original size (1" x 1"), so the Apparent DPI is smaller.
So to solve this properly you would need to actually get the size the
image takes up in the document, and calculate and set all the sizes
from the outside. The reason this doesn't and can't work as expected
here is that you can have multiple instances that all point to the
same image in the document, but the size of the image in the document
is different.
Sorry if I'm asking a stupid question here. First, I've never seen or
used a document with "multiple instances that all point to the same
image in the document". And I take "the image in the document" or "The
size the image takes up in the document" seems to be the "Apparent
dimensions", 4.24" in this case. Is it? That is, even if there are
multiple images in this document which the source is the same one (I
still don't know how to do that), shouldn't it be calculated regarding
to the "Apparent dimensions" here? I mean, after all, that is what user
set in the document. Since the image shown in the document is actually
4.24"x4.24", while the original svg file is 0.21"x0.21, shouldn't it be
20 times (4.24/0.21 ~= 20) DPI, that is, 96*20 = 1920 sent to xBitmap()?
We tried to set Size(20,20) to get aDPI, or directly set aDPI to
(1920,1920), they both ended up 4.24"x4.24" with 99DPI, which is good
enough. Do you think it a reasonable thought?
So you will need to first find the place where conversion for the
embedded PNG and properly calculate the size at that place - not
inside this method.
The size should be the Apparent dimensions, since in the document it was
set to that size. That's what we thought.
BTW, if so, how can we get the Apparent dimensions in this method?
Thanks for your reply,
Dev
Re: #tdf51510: Change the DPI to get better resolution, but failed the unit test
Hi, Tomaž,
Tomaž Vajngerl 於 2023/8/11 17:31 寫道:
Hi,
On Fri, Aug 11, 2023 at 8:06 AM Lodev wrote:
Hi,
We're trying to fix #tdf51510: "Exporting documents with embedded SVG to
doc or docx converts the image to low-resolution pixel graphics" since
it bothers us and it seems more and more bugs duplicated or related to
this one. We changed in vcl/source/gdi/vectorgraphicdata.cxx:78
-Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1),
MapMode(MapUnit::MapInch)));
+Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(50, 50),
MapMode(MapUnit::MapInch)));
To get better resolutions. It worked. Exported docx file with embedded
png now gets better resolution.
However this change couldn't pass unit test :
sw/qa/extras/ooxmlexport/ooxmlexport16.cxx:762, tdf136841.docx . It
seems to be fixed, expecting low resolution converted images.
Since it didn't pass the unit test, we didn't commit the patch to
gerrit. So here, first we'd like to know if this solution, changing
size(1,1) to size(50,50) is acceptable or not?
I wouldn't do it like that. The purpose of that LogicToPixel
conversion is to figure out the DPI (number of pixels/inch) of the
output device - changing that to 50 doesn't make sense considering
what that call tries to achieve (you ask what's the number of pixels
per 50inches).
The next issue is that this will result in a 50x bigger size - that's
a lot! Typically the device DPI is 96 - this makes it 50*96 = 4800,
which means a 3 x 3 inch image (not that A4 paper size is 8.3 x 11.7
inch, so 3x3 inch image is typical) will have the resolution of
14400x14400 pixels!
Note also that in ODF we store a PNG bitmap for vector images in
addition the the vector image, which serves as a fall-back. For that
we go through the same code path, so the file size would increase
significantly.
What I suggest is to not depend on the output device DPI (which causes
us a lot of trouble because the result then depends on the system and
OS) and set a constant but high enough DPI, that will be good enough
in most cases. 300DPI is usually good enough for printing so I think
that would be a good constant to use here (it's 3x bigger than typical
96DPI of an output device).
Tomaž
In fact, when we were doing more test, we found the behavior somewhat
strange.
We used attachment 170646 in tdf#51510.
vcl/source/gdi/vectorgraphicdata.cxx, line 77:
// get system DPI
Size
aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1),
MapMode(MapUnit::MapInch)));
if (rTargetDPI.has_value())
{
aDPI = *rTargetDPI;
}
const uno::Reference< rendering::XBitmap > xBitmap(
xPrimitive2DRenderer->rasterize(
comphelper::containerToSequence(rSequence),
aViewParameters,
aDPI.getWidth(),
aDPI.getHeight(),
aRealRect,
nMaximumQuadraticPixels));
First, Size aDPI:
Application::GetDefaultDevice()->LogicToPixel(Size(1,1),
MapMode(MapUnit::MapInch)), here we did get aDPI is (96, 96).
However, after saving as docx, the PNG image information (in Compress
Image dialog) we got is:
Actual dimensions: 0.21"x0.21" (21x21 px)
Apparent dimensions: 4.24" x 4.24" at 4 DPI
If we set LogicToPixel(Size(4,4), ...), we got:
Actual dimensions: 0.84"x0.84" (84x84 px)
Apparent dimensions: 4.24" x 4.24" at 19 DPI
Second, We then tried to directly assign 300DPI by adding
aDPI.setWidth(300);
aDPI.setHeight(300);
before calling xBitmap(xPrimitive2DRenderer0>rasterize()). We printed
aDPI.getWidth() and aDPI.getHeight() and did got 300, 300.
However the PNG image information saved in docx file
Actual dimensions: 0.68 x 0.68 (66x66 px)
Apparent dimensions: 4.24" x 4.24" at 15 DPI
Is the above way to correctly "set a constant but high enough DPI"? But
even if I assigned 300DPI the result DPI is still very low. So, what is
the exactly way to set constant 300DPI?
BTW, the rTargetDPI was a parameter of
convertPrimitive2DSequenceToBitmapEx, which was called only once and
the parameter rTargetDPI was never used.
That is, it is always nullptr by default, according to its declaration.
This parameter seems to be useless at all.
Any suggestion will be appreciated.
Thanks for your help.
Dev
#tdf51510: Change the DPI to get better resolution, but failed the unit test
Hi, We're trying to fix #tdf51510: "Exporting documents with embedded SVG to doc or docx converts the image to low-resolution pixel graphics" since it bothers us and it seems more and more bugs duplicated or related to this one. We changed in vcl/source/gdi/vectorgraphicdata.cxx:78 - Size aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(1, 1), MapMode(MapUnit::MapInch))); + Size aDPI(Application::GetDefaultDevice()->LogicToPixel(Size(50, 50), MapMode(MapUnit::MapInch))); To get better resolutions. It worked. Exported docx file with embedded png now gets better resolution. However this change couldn't pass unit test : sw/qa/extras/ooxmlexport/ooxmlexport16.cxx:762, tdf136841.docx . It seems to be fixed, expecting low resolution converted images. Since it didn't pass the unit test, we didn't commit the patch to gerrit. So here, first we'd like to know if this solution, changing size(1,1) to size(50,50) is acceptable or not? If not, is there any better suggestion to solve this? If yes, how can we pass the unit test given that patch? Thanks for your suggestion. Dev
