[Libreoffice-qa] Hijack bulk bug updates to remind about Bugzilla Migration
Quick reminder: The next time we (read: probably Joel) do some bulk updates of bug reports, we shoudl leverage that opportunity to insert a small reminder about the migration of Bugzilla, password reset, etc. Linking to this would probably be good: https://wiki.documentfoundation.org/QA/Bugzilla/TDF_Bugzilla_Proposal/Migration_Userguide#After_the_Migration Thanks, --R -- Robinson Tryon QA Engineer - The Document Foundation LibreOffice Community Outreach Herald qu...@libreoffice.org ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Bug 60739] cut/paste coding redux
https://bugs.documentfoundation.org/show_bug.cgi?id=60739 --- Comment #10 from Michaël Lefèvre lefevr...@yahoo.fr --- Factorise FN_WORDCOUNT_DIALOG case in https://gerrit.libreoffice.org/14182 . More cases could be cleaned up : FN_FORMAT_FOOTNOTE_DLG FN_NUMBERING_OUTLINE_DLG: SID_OPEN_XML_FILTERSETTINGS ... I'm planning to change the other ones, referencing this bug. Any objection ? -- You are receiving this mail because: You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: 9 commits - drawinglayer/source external/boost external/cppunit external/harfbuzz external/icu external/libodfgen filter/source include/com include/registry include/rtl
RepositoryExternal.mk|2
drawinglayer/source/drawinglayeruno/xprimitive2drenderer.cxx |1
external/boost/UnpackedTarball_boost.mk |1
external/boost/rtti.patch.0 | 20 +
external/cppunit/UnpackedTarball_cppunit.mk |1
external/cppunit/rtti.patch.0| 15 +++
external/harfbuzz/ubsan.patch| 42 +++
external/icu/UnpackedTarball_icu.mk |1
external/icu/rtti.patch.0| 11 ++
external/libodfgen/ExternalProject_libodfgen.mk |2
external/libodfgen/UnpackedTarball_libodfgen.mk |1
external/libodfgen/rtti.patch| 11 ++
filter/source/graphicfilter/ipict/ipict.cxx |3
include/com/sun/star/uno/Any.h |2
include/com/sun/star/uno/Reference.h |2
include/com/sun/star/uno/Sequence.h |2
include/com/sun/star/uno/Type.h |2
include/registry/regtype.h |6 -
include/rtl/alloc.h |2
include/rtl/string.hxx |2
include/rtl/unload.h |2
include/rtl/ustring.h|2
include/rtl/ustring.hxx |2
include/sfx2/childwin.hxx|8 +-
include/tools/ref.hxx|2
include/typelib/typedescription.h|6 -
include/uno/any2.h |2
include/uno/dispatcher.h |2
include/uno/environment.h|4 -
include/uno/mapping.h|2
package/source/xstor/xfactory.cxx|3
sal/textenc/tenchelp.hxx |2
sc/inc/filter.hxx|2
sc/source/ui/view/tabvwsh.cxx|3
scripting/source/vbaevents/service.cxx |6 -
sd/source/filter/eppt/eppt.cxx |7 +
sd/source/filter/html/HtmlOptionsDialog.cxx |1
svl/source/uno/pathservice.cxx |1
svtools/source/control/asynclink.cxx |8 --
sw/qa/extras/ooxmlexport/data/fdo79822-SPECIAL.docx |binary
sw/source/uibase/web/wdocsh.cxx |3
sw/source/uibase/web/wformsh.cxx |3
sw/source/uibase/web/wfrmsh.cxx |3
sw/source/uibase/web/wgrfsh.cxx |3
sw/source/uibase/web/wlistsh.cxx |3
sw/source/uibase/web/wtabsh.cxx |3
sw/source/uibase/web/wtextsh.cxx |3
sw/source/uibase/web/wview.cxx |3
vcl/inc/salframe.hxx |4 -
vcl/inc/unx/desktops.hxx |6 +
vcl/source/components/dtranscomp.cxx |1
vcl/source/components/fontident.cxx |1
vcl/unx/generic/plugadapt/salplug.cxx| 11 ++
xmloff/source/chart/SchXMLExport.cxx |1
xmloff/source/draw/animationimport.cxx |1
xmloff/source/meta/MetaImportComponent.cxx |1
xmloff/source/transform/OOo2Oasis.cxx|1
xmloff/source/transform/Oasis2OOo.cxx|1
58 files changed, 202 insertions(+), 44 deletions(-)
New commits:
commit 6de91546198e5bfbe0399274284114b550e2f030
Author: Stephan Bergmann sberg...@redhat.com
Date: Mon Jan 26 15:16:48 2015 +0100
Make sure _nEventId gets reset after calling RemoveUserEvent
Change-Id: I8f90fb809d5275e8a74964776f01f4d563f2e657
diff --git a/svtools/source/control/asynclink.cxx
b/svtools/source/control/asynclink.cxx
index 1efd934..ca745b2 100644
--- a/svtools/source/control/asynclink.cxx
+++ b/svtools/source/control/asynclink.cxx
@@ -48,13 +48,7 @@ bAllowDoubles
DBG_ASSERT( bAllowDoubles ||
( !_nEventId ( !_pIdle || !_pIdle-IsActive() ) ),
Schon ein Call unterwegs );
-if( _nEventId )
-{
-if( _pMutex ) _pMutex-acquire();
-Application::RemoveUserEvent( _nEventId );
-if( _pMutex )
Re: New Defects reported by Coverity Scan for LibreOffice
On Mon, 2015-01-26 at 14:49 +0100, Stephan Bergmann wrote: What was the state of these builds again, they're implicitly --disable-debug, --disable-assert-always-abort, and making them --enable-debug would run out of resources? Could they be made --enable-assert-always-abort, in the hope that that would silence the above false positive (or would that need some explicit coverity comment annotation anyway)? I'll add --enable-assert-always-abort for the next run to see what happens. Coverity allows us two slots every 7 days (next slot is Jan 29). Each build+upload+analysis takes about a day. There is/was some (unknown) timeout on the coverity side for the analysis, something like 12-16 hours and a few times in the past we've hit it, nearly always at weekends. Quite possibly a bunch of projects have a run coverity automatically at the w/e process making us vulnerable that the coverity servers don't have enough capacity to complete our analysis before the timeout if we submit at those times. IIRC I hit the timeout with an --enable-dbgutil build every time I tried it. But it might be that an --enable-debug would work ok (I'm not even sure if there would be a difference to what coverity would scrape out of our source between --enable-assert-always-abort and --enable-debug) and I can experiment again but it's a bit like trying to steer a supertanker. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 88808] New: VIEWING: Content of text OLE object inserted in Draw is not displayed correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=88808 Bug ID: 88808 Summary: VIEWING: Content of text OLE object inserted in Draw is not displayed correctly Product: LibreOffice Version: Inherited From OOo Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Drawing Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: fdb...@neosheffield.co.uk This bug is split from bug 51508 Reproduced on LO 4.4.0.2 (Ubuntu 14.04, OSX 10.10) and 3.3.0.4 (OSX 10.10) When a text OLE object is inserted into Draw, its rendering is not correct after ending editing of the object Steps to reproduce: 1. Open a blank Draw document 2. Insert a text OLE object (Insert - Object - OLE Object - LibreOffice Text) 3. Without resizing (to avoid bug 51508), type a few lines of text 4. Open Format - Page - Area and select a coloured fill (e.g. Light red) 5. Click outside the OLE object to end editing 6. Select the OLE object by clicking to show the bounds Expected result - The text is contained within the OLE frame Actual result - The text is shifted downwards from the displayed OLE frame and spills out of it (although the page background does not) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 83309] FILEOPEN: text paragraph indentation/tab stops in .DOCX displayed incorrectly
https://bugs.documentfoundation.org/show_bug.cgi?id=83309 Timur gti...@gmail.com changed: What|Removed |Added Summary|.docx displayed incorrectly |FILEOPEN: text paragraph ||indentation/tab stops in ||.DOCX displayed incorrectly -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88809] EDITING: Position of OLE text object in Draw different when opened for editing
https://bugs.documentfoundation.org/show_bug.cgi?id=88809 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||808 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 87043] The SUBTOTAL() function in Calc does not ignore hidden rows as in Excel
https://bugs.documentfoundation.org/show_bug.cgi?id=87043 --- Comment #4 from Rajendra Parmar ca.rajendra.par...@gmail.com --- Created attachment 112806 -- https://bugs.documentfoundation.org/attachment.cgi?id=112806action=edit Subtotal() function does not ignore hidden rows - Subtotal() function does not ignore hidden rows in CALC. Most users of spreadsheets, need such facility of and on. EXCEL offers this facility. To make the Libreoffice effectve and attract user to shift over to CALC from EXCEL, this change is must and need immediate attention. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-commits] core.git: sc/inc sc/source
sc/inc/address.hxx |3 ++
sc/source/core/tool/address.cxx | 45
sc/source/filter/excel/xestream.cxx | 10
sc/source/filter/excel/xetable.cxx | 14 ---
sc/source/filter/inc/xestream.hxx |2 +
5 files changed, 71 insertions(+), 3 deletions(-)
New commits:
commit 0d2ce71afe0cb2657a6919e641e54c8fc9ba288c
Author: László Németh laszlo.nem...@collabora.com
Date: Mon Jan 26 15:45:05 2015 +0100
fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX export
Change-Id: Ie6a024463e7ee9b0f4492b2431533708a578faf0
diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index 06c450b..aa05a58 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,6 +325,9 @@ public:
ExternalInfo* pExtInfo = NULL,
const css::uno::Sequencecss::sheet::ExternalLinkInfo*
pExternalLinks = NULL );
+SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
+ const ScDocument* pDocument = NULL,
+ const Details rDetails = detailsOOOa1)
const;
SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
const ScDocument* pDocument = NULL,
const Details rDetails = detailsOOOa1)
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index 39fc9a4..886b866 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,6 +1745,51 @@ static OUString getFileNameFromDoc( const ScDocument*
pDoc )
return sFileName;
}
+/** Tries to obtain a simple address without OUString/OString allocation
+ *
+ * @returns TRUE at success (it is enough to call OUString Format() at FALSE)
+ *
+ */
+
+bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
+ const Details rDetails) const
+{
+if( nFlags SCA_VALID )
+nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
+if(( pDoc (nFlags SCA_VALID_TAB ) ( nTab = pDoc-GetTableCount()
|| ( nFlags SCA_TAB_3D ))) ||
+ ! (nFlags SCA_VALID_COL) || ! (nFlags SCA_VALID_ROW) ||
+(nFlags SCA_COL_ABSOLUTE) != 0 || (nFlags SCA_ROW_ABSOLUTE) !=
0 )
+{
+ return false;
+}
+
+switch( rDetails.eConv )
+{
+default :
+// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following
simple addresses
+case formula::FormulaGrammar::CONV_OOO:
+case formula::FormulaGrammar::CONV_XL_A1:
+case formula::FormulaGrammar::CONV_XL_OOX:
+if (nCol = 26 * 26)
+// TODO: extend it for full column range
+return false;
+if( nCol 26 )
+*s = 'A' + nCol;
+else
+{
+*s = 'A' + nCol / 26 - 1;
+s++;
+*s = 'A' + nCol % 26;
+}
+sprintf(s + 1, %d, nRow + 1);
+break;
+case formula::FormulaGrammar::CONV_XL_R1C1:
+// not used in XLSX export
+return false;
+}
+return true;
+}
+
OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details rDetails) const
{
diff --git a/sc/source/filter/excel/xestream.cxx
b/sc/source/filter/excel/xestream.cxx
index e5ff50c..188fcd6 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,6 +718,11 @@ OString XclXmlUtils::ToOString( const OUString s )
return OUStringToOString( s, RTL_TEXTENCODING_UTF8 );
}
+bool XclXmlUtils::TryToChar( char * s, const ScAddress rAddress )
+{
+return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1));
+}
+
OString XclXmlUtils::ToOString( const ScAddress rAddress )
{
OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1)));
@@ -760,6 +765,11 @@ static ScAddress lcl_ToAddress( const XclAddress rAddress
)
return aAddress;
}
+bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress rAddress )
+{
+return TryToChar( s, lcl_ToAddress( rAddress ));
+}
+
OString XclXmlUtils::ToOString( const XclAddress rAddress )
{
return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx
b/sc/source/filter/excel/xetable.cxx
index 70f3373..dd527d3 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,6 +41,11 @@ using namespace ::oox;
namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
+// max string length of simple addresses (eg. ABC100\0)
+#if MAXROWCOUNT_DEFINE 999
+#define SIMPLEADDRESSLEN 11
+#endif
+
// Helper records for cell records
XclExpStringRec::XclExpStringRec( const XclExpRoot rRoot, const OUString
rResult ) :
@@ -630,9 +635,10 @@ static OString lcl_GetStyleId( XclExpXmlStream rStrm,
const XclExpCellBase rCe
[Libreoffice-bugs] [Bug 88360] LibreOffice Crashes during Test Procedure of Bug 43020
https://bugs.documentfoundation.org/show_bug.cgi?id=88360 Harald Koester harald.koes...@mail.de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Harald Koester harald.koes...@mail.de --- After the state has been set back to UNCONFIRMED it's now possible to set the status to NEW. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88801] Android: Can't load flat ODF
https://bugs.documentfoundation.org/show_bug.cgi?id=88801 Robinson Tryon (qubit) qu...@runcibility.com changed: What|Removed |Added CC||qu...@runcibility.com --- Comment #1 from Robinson Tryon (qubit) qu...@runcibility.com --- TESTING with Android 4.4.4 + LibreOffice 4.5.0.0.alpha0+ Master tinderbox: buildname: Android-ARM@24-Bytemark-Hosting tinderbox: tree: MASTER tinderbox: pull time 2015-01-26 04:29:24 tinderbox: git sha1s core:4735ad02167576036c9f3c9dffb3ccbd0a884db7 (In reply to Miklos Vajna from comment #0) Currently the flat license button in the about dialog of the Android app loads a plain text version of the license, as we have plain text and flat ODF in git, and flat ODF is *also* opened as plain text, as in showing the raw XML markup instaed of some nicely formatted document. REPRO steps: - Open LO on Android - three button thing - About - Show License PROBLEM: See XML markup NOREPRO -- Looks okay to me. I just see a bunch of licenses in a monospace font. It would be great to track down why flat ODF doesn't work in the Android app, then we could start shipping the flat ODF version of the license document instead. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88808] VIEWING: Content of text OLE object inserted in Draw is not displayed correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=88808 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||809 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 58808] MAILMERGE: Wizard quits when Print Preview is shown
https://bugs.documentfoundation.org/show_bug.cgi?id=58808 Timur gti...@gmail.com changed: What|Removed |Added CC||gti...@gmail.com Version|unspecified |Inherited From OOo Summary|Mail Merge Wizard quits |MAILMERGE: Wizard quits |when Print Preview is shown |when Print Preview is shown -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 51169] FILESAVE: Saving odt to doc: removed pagenumbers
https://bugs.documentfoundation.org/show_bug.cgi?id=51169 --- Comment #12 from Timur gti...@gmail.com --- Seems like footer with pagenumbers is now preserved with LO 4.3.5 and 4.4.0. I suggest this be confirmed and closed as WorksForMe. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88811] New: FILEOPEN: Drawing lines not imported from RTF
https://bugs.documentfoundation.org/show_bug.cgi?id=88811 Bug ID: 88811 Summary: FILEOPEN: Drawing lines not imported from RTF Product: LibreOffice Version: 4.3.0.4 release Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: filters and storage Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: fdb...@neosheffield.co.uk This is split from bug 58736. Observed on OSX 10.10/LO 4.3.0.4 and 4.4.0.2. Not observed on LO 4.2.6.3 Steps to reproduce: 1. Load the RTF file from attachment 72096 Expected result: - Drawing lines should show the borders of a table around the imported text Actual result: - Most of the lines are missing -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: [Libreoffice-qa] [LibreOffice Bugzilla Migration] We're done! Please visit the new site to reset your password!
On Mon, Jan 26, 2015 at 7:17 AM, Pedro pedl...@gmail.com wrote: Robinson Tryon wrote Before you can log-in and start working on bugs, you'll need to reset your password. Read more here: https://wiki.documentfoundation.org/QA/Bugzilla/TDF_Bugzilla_Proposal/Migration_Userguide#After_the_Migration The Bugzilla email with subject Bugzilla Change Password Request went directly into my GMail Spam mailbox. So this is a warning for people who use Google Mail (and possibly other email providers): If don't receive any email for resetting the Bugzilla password in your Primary, Social or Promotions mailbox, then you should check the Spam mailbox. Thanks, Pedro -- I've updated the guide to tell people to check their Spam folder. Best, --R -- Robinson Tryon QA Engineer - The Document Foundation LibreOffice Community Outreach Herald qu...@libreoffice.org ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams
2015-01-26 12:15 GMT+01:00 Tom Davies tomc...@gmail.com: Hi :) Hi Tom! Yes that suggestion was put forwards in the previous thread Good! And thank you for telling me that. and i still think it is an excellent idea - or at least has a lot of merit. I absolutely agree ;-). I seem to remember there were excellent reasons why it might be unworkable I am curious to see those reasons. Guess I will have to browse through the discussion to find it. But it is rather long, so I might not do that right now. but i'm not sure if they really are total blockers. I can't see how they could be total blockers. LibreOffice comes in hundreds of languages, so this would just be a new language like any other, and adding new languages has never seemed to be a big problem before. There could even still be a language-simplistic version of LibreOffice with only the unpolished source code keys used and no translation to polished en-us (if anybody prefer such a version?), but people that want the language to be polished and correct would just pick up the en-us translation like everybody else picks up the translation for their own local language. Why should en-us have any special status in the construction of the final product? It doesn't solve the problems with adding colons etc. to existing strings – changes like that should of course still be automated. But it would solve problems resulting from changes in style, correction of non-semantic typos, etc. And everybody working in Pootle could still add the polished and correct en-us translation as one of their alternative source languages (you can do that in the settings [1]) and we could all therefore still use the polished, correct en-us translation as the basis of our translations if we prefer that over the more coarse, non-polished key strings from the source code. Of course I might be repeating arguments that have already been stated in the earlier discussion. If anyone can find the right part of the original discussion (perhaps because they know what to search for because they remember the discussion) they are more than welcome to point it out to me. [1]: https://translations.documentfoundation.org/accounts/edit/ Regards from Jesper Regards from Tom :) On 26 January 2015 at 10:52, Jesper Hertel jesper.her...@gmail.com wrote: Hi Sophie and everybody else, Well I didn't answer as I didn't feel like finding out what the projects@ list was and joining that list to be able to join the discussion there. I will answer here. I did not read the whole previous discussion but did anyone suggest to add a new en-us translation language in Pootle and let that be the place where all non-semantic changes to the en-us strings happen? That way the current strings in the source code will turn into mere translation keys written in en-us. The final en-us polishing will then happen in the translation files just like any other language and will of course not affect any of the other languages. Any semantic change should of course still happen in the keys, i.e. the source code, but non-semantic changes should be prohibited there and instead made in the en-us translation in Pootle. This might be something obvious that you already talked a lot about, but I just want to make sure this option isn't overlooked. Jesper Den 26/01/2015 09.34 skrev Sophie gautier.sop...@gmail.com: Hi, Resending as there was no answer to the proposals :) Cheers Sophie Le 19/01/2015 11:03, Sophie a écrit : Hi all, [Please follow-up the discussion on projects@ list to keep the history of the thread there and ease the discussion, thanks :-)] I would like to open a discussion about the way developers team, UX team and l10n team should interact and work together. There has been a heavy discussion [see this thread 1] during this round of translation. The l10n team was a bit frustrated that there were again so many changes in the en_US version that does not concern the l10n versions (like adding colon at the end or capitals in the middle of the strings). Each time, it seems part of this could be automated or a reflection on how to avoid messing the l10n work should have been introduced before those changes are committed. For example, if I decide to change FR localization to have sentence capitalization in the menu entries, none of the 100 other localizations won't and shouldn't be affected. It should be the same for en_US version or if really impossible, try to find a solution that lower the impact on all localizations. None of the l10n teams is against changing or correcting the UI of the en_US version and none is against the natural evolution of the suite. What is not bearable is when you have 100 000 changes in en_US and only a 1/3 concerns all the other languages and it is repeated over the branches. We are trying to change our
[Libreoffice-bugs] [Bug 88809] EDITING: Position of OLE text object in Draw different when opened for editing
https://bugs.documentfoundation.org/show_bug.cgi?id=88809 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added CC||fdb...@neosheffield.co.uk See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=51 ||508 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 51508] Resizing OLE text objects makes them unusable
https://bugs.documentfoundation.org/show_bug.cgi?id=51508 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||809 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 83920] PRINTING: slowliness to display dialog boxes related to printing
https://bugs.documentfoundation.org/show_bug.cgi?id=83920 haewa GmbH e...@haewa.de changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from haewa GmbH e...@haewa.de --- Slow Preview rendering in Print Dialog is a common problem on slow computers or complex environments, also see https://bugs.documentfoundation.org/show_bug.cgi?id=67905 *** This bug has been marked as a duplicate of bug 67905 *** -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 67905] Enhancement: Add ability to turn off preview in print dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=67905 haewa GmbH e...@haewa.de changed: What|Removed |Added CC||informatique@ville-barcelon ||nette.fr --- Comment #4 from haewa GmbH e...@haewa.de --- *** Bug 83920 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88808] VIEWING: Content of text OLE object inserted in Draw is not displayed correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=88808 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added CC||fdb...@neosheffield.co.uk --- Comment #1 from Matthew Francis fdb...@neosheffield.co.uk --- Created attachment 112804 -- https://bugs.documentfoundation.org/attachment.cgi?id=112804action=edit Sample Draw document -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: New Defects reported by Coverity Scan for LibreOffice
On 01/25/2015 02:23 PM, scan-ad...@coverity.com wrote:
*** CID 1266445: Explicit null dereferenced (FORWARD_NULL)
/cppuhelper/source/component_context.cxx: 747 in
cppu::ComponentContext::disposing()()
741 envs, envCount, rtl_allocateMemory, OUString(java).pData);
742 assert(envCount = 0);
743 assert(envCount == 0 || envs != nullptr);
744 for (sal_Int32 i = 0; i != envCount; ++i) {
745 assert(envs[i] != nullptr);
746 assert(envs[i]-dispose != nullptr);
CID 1266445: Explicit null dereferenced (FORWARD_NULL)
Dereferencing null pointer envs.
747 (*envs[i]-dispose)(envs[i]);
What was the state of these builds again, they're implicitly
--disable-debug, --disable-assert-always-abort, and making them
--enable-debug would run out of resources? Could they be made
--enable-assert-always-abort, in the hope that that would silence the
above false positive (or would that need some explicit coverity comment
annotation anyway)?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Workflow between dev, UX and l10n teams
Hi Sophie, Mihovil, Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100: Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us I see 2 problems here: 1) There is no tool that would detect these trivial changes, and would act accordingly. 2) The texts for translations are updated in big 'code' drops, without possibility for translators to affect the process in any way - for them it is too late. Regarding 1) - I thought that Pootle is detecting the trivial changes some way, and offering the original translation. Is it not? What can be done to improve that, so that for translators it is just a matter of checking; not a matter of translating? [Or even what you suggest - that it would just update the source strings without touching the translations?] Regarding 2) - I'm glad that you say that the strings will be now getting to Pootle immediately after the code / string changes in master. I think it is important that the translators will be able to deal with the changes immediately, not several months later, so that they can cooperate, and not only react. In general, I don't think that setting extremely strict rules works, unless you have means how to enforce them - like via a commit hook or so (and it is extremely unpopular way to do things). It is always much better to communicate - if you see a developer who commits a change that causes you grief, please _do_ tell _him/her_ immediately, and - if possible - in a friendly way. I'm sure he/she will do much better the next time. Unfortunately I did not see any signs of notice that this or that change was problematic for localization on the development mailing list - were there such warnings there? Like commit XY caused AB - please don't do such things, unless we agree how to do that effectively / without pain? Or was it impossible so far because the strings in Pootle were not synced with master? Also - should we have a 'Localization' recurring topic in the ESC? Who would be the right representative there, please? All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: vcl/workben
vcl/workben/vcldemo.cxx |8
1 file changed, 4 insertions(+), 4 deletions(-)
New commits:
commit 1854a92340bb46d892d24265d28b9781309c1d6b
Author: LuboÅ¡ LuÅák l.lu...@collabora.com
Date: Thu Dec 18 11:47:28 2014 +0100
there's no bigger or smaller half
Change-Id: Ida0e92abd806d017d17365fa2ac53b4f7cb2ebad
diff --git a/vcl/workben/vcldemo.cxx b/vcl/workben/vcldemo.cxx
index 888c7b1..a932c06 100644
--- a/vcl/workben/vcldemo.cxx
+++ b/vcl/workben/vcldemo.cxx
@@ -251,6 +251,10 @@ public:
};
for (size_t i = 0; i aRegions.size(); i++)
{
+// Half of them not-anti-aliased ..
+if (i = aRegions.size()/2)
+rDev.SetAntialiasing(nOldAA);
+
static const struct {
double nX, nY;
} aPoints[] = {
@@ -265,10 +269,6 @@ public:
aSub.Top() +
aSub.GetHeight() * aPoints[j].nY));
}
rDev.DrawPolyLine(aPoly, aLineWidths[i], eJoins[i],
eLineCaps[i]);
-
-// Half of them not-anti-aliased ..
-if (i aRegions.size()/2)
-rDev.SetAntialiasing(nOldAA);
}
}
else
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: New Defects reported by Coverity Scan for LibreOffice
On Sun, 2015-01-25 at 05:23 -0800, scan-ad...@coverity.com wrote: Hi, Please find the latest report on new defect(s) introduced to LibreOffice found with Coverity Scan. 70 new defect(s) introduced to LibreOffice found with Coverity Scan. 503 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. We're now using the latest coverity release of 7.6.0 which comes with extra warnings. So what's going on here with the +70 is newly detected warnings with old code. and the -503 is because the previous build failed to build ~500 cxx files under coverity 7.5.0 with some unknown parse error which prompted to upgrade to 7.6.0 which worked again. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 88807] New: Table cell diagonal line not supported
https://bugs.documentfoundation.org/show_bug.cgi?id=88807 Bug ID: 88807 Summary: Table cell diagonal line not supported Product: LibreOffice Version: 4.3.5.2 release Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: daniel.grigo...@movidius.com Hi, Please add support for inserting diagonal lines in table cells. Microsoft Word has this feature for long time now, and I miss this in LibreOffice. Being able to draw diagonal lines within a table cell is highly necessary in some cases. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88808] VIEWING: Content of text OLE object inserted in Draw is not displayed correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=88808 --- Comment #2 from Matthew Francis fdb...@neosheffield.co.uk --- Created attachment 112805 -- https://bugs.documentfoundation.org/attachment.cgi?id=112805action=edit Screenshot (4.4.0.2) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88808] VIEWING: Content of text OLE object inserted in Draw is not displayed correctly
https://bugs.documentfoundation.org/show_bug.cgi?id=88808 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=51 ||508 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 51508] OLE text objects in Draw change aspect ratio when resized while open for editing (summary: comment 34)
https://bugs.documentfoundation.org/show_bug.cgi?id=51508 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added CC||fdb...@neosheffield.co.uk Summary|Resizing OLE text objects |OLE text objects in Draw |makes them unusable |change aspect ratio when ||resized while open for ||editing (summary: comment ||34) Whiteboard|BSA bibisectRequest |BSA notBibisectable --- Comment #34 from Matthew Francis fdb...@neosheffield.co.uk --- One bug should contain one issue. Restating this bug for the first issue mentioned on comment 0. (See bug 88808 and bug 88809 for issues (2) and (3)) Issue (1), that the aspect ratio of an OLE text object in Draw is changed when resizing it while it is open for editing, will continue to be dealt with on this bug. The issue does appear to be a regression, and probably introduced, or at least worsened during the range of the bibisect 43all repository. Frustratingly though, the exact point of origin defies identification. There is at least a range towards the beginning in which it appears to occur only intermittently. - Replaced Whiteboard:bibisectRequest with notBibisectable - Updated Summary to reflect the issue dealt with on this bug -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 87360] Spacing to content should be 0.00 cm when adding border to image
https://bugs.documentfoundation.org/show_bug.cgi?id=87360 Jay Philips philip...@hotmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #2 from Jay Philips philip...@hotmail.com --- We had discussed this in one of the design/ux meetings and kendy stated that there is problems with default setting as it also alters the size of the image. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 87360] Spacing to content should be 0.00 cm when adding border to image
https://bugs.documentfoundation.org/show_bug.cgi?id=87360 Jay Philips philip...@hotmail.com changed: What|Removed |Added Status|REOPENED|NEW -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88800] 4.4 doesn't start
https://bugs.documentfoundation.org/show_bug.cgi?id=88800 --- Comment #2 from k-j o...@sophia-louise.de --- The solution won't help for a long time. After opening a file from Explorer Libo went on shortly and vanished. I give up and install 4.3.5 again. This works fine here. (By the way no problem with a WIN10 VM and 4.4.0.3) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88806] New: Table cell fill tool doesn't fill the entire cell when applied to a single cell
https://bugs.documentfoundation.org/show_bug.cgi?id=88806 Bug ID: 88806 Summary: Table cell fill tool doesn't fill the entire cell when applied to a single cell Product: LibreOffice Version: 4.3.5.2 release Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: daniel.grigo...@movidius.com Created attachment 112803 -- https://bugs.documentfoundation.org/attachment.cgi?id=112803action=edit Sceenshot and its source document that proove the single table cell colour fill issue Hi, I noticed a long time ago, but forgot to report this bug, that when only a single table cell is filled with a background colour the cell is not filled entirely. See the screenshot attached as well as its source example document. Hope this gets fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-commits] core.git: libreofficekit/source
libreofficekit/source/gtk/lokdocview.c |4
1 file changed, 4 insertions(+)
New commits:
commit 64235bc9896911b4abfca47089ac1e71056afea7
Author: Miklos Vajna vmik...@collabora.co.uk
Date: Mon Jan 26 14:08:45 2015 +0100
lokdocview: fix for missing gtk_table_get_size()
Change-Id: Ib3f9849c2f28375a7e8bcd6575a6c3da0860d4fb
diff --git a/libreofficekit/source/gtk/lokdocview.c
b/libreofficekit/source/gtk/lokdocview.c
index 7264563..372fa9d 100644
--- a/libreofficekit/source/gtk/lokdocview.c
+++ b/libreofficekit/source/gtk/lokdocview.c
@@ -163,10 +163,14 @@ void renderDocument(LOKDocView* pDocView, GdkRectangle*
pPartial)
// Same as nRows / nColumns, but from the previous renderDocument()
call.
guint nOldRows, nOldColumns;
+#if GTK_CHECK_VERSION(2,22,0)
gtk_table_get_size(GTK_TABLE(pDocView-pTable), nOldRows,
nOldColumns);
if (nOldRows != nRows || nOldColumns != nColumns)
// Can't do partial rendering, document size changed.
pPartial = NULL;
+#else
+pPartial = NULL;
+#endif
}
if (!pPartial)
{
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: Jenkins verification of gerrit patches
On Mon, Jan 26, 2015 at 11:40:33AM +0100, Michael Stahl wrote: On 26.01.2015 09:57, Miklos Vajna wrote: On Mon, Jan 26, 2015 at 05:28:29AM +0100, Lionel Elie Mamane lio...@mamane.lu wrote: Is there some way to get the compilation result? That could be a nice way to verify patches for a platform one does not have a build environment for, and/or to give an experimental version to test to a bug reporter. Yes, it's possible, just the Jenkins UI is confusing a bit. E.g. you get this link in gerrit: http://ci.libreoffice.org/job/lo_gerrit_master/272/ Now hover your mouse over the interesting platform and click on the small black down arrow that appears, and select console output. I believe Lionel was interested in installation sets, not the build log Indeed. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 51508] Resizing OLE text objects makes them unusable
https://bugs.documentfoundation.org/show_bug.cgi?id=51508 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||808 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88752] DOC import: text grid size mismatch
https://bugs.documentfoundation.org/show_bug.cgi?id=88752 --- Comment #2 from Caolán McNamara caol...@redhat.com --- Back in the day when we first implemented the text grid I suggested we should have the same text grid rules as word (whatever they are) for ease of interoperability, but the powers that be said they wanted a text-grid that was better than words and so we have different rules for it, which is a frustrating nightmare. The table confuses things, but if you remove it and compare word against writer for 15 lines per page (writer: format page-text grid with cjk features enabled word: page setup-document grid) and put 15 lines into word and writer for this doc then word fits 15 lines into the page and writer fits 14. I remember just giving up and settings things so that the numbers are the same in word and writer wrt lines per page and base text size. I don't think it's as simple as just scaling the font size by 0.9 (but maybe it is) https://wiki.openoffice.org/w/images/1/1c/Text_Grid_Enhancement_for_CJK.odt which has some details on what's wrong with our grid that *might* be useful. You probably need to find the code in writer that calculates the grid and see how it calculates it in order to feed it numbers that will make it behave like word. It might be that to get the same layout as word you have to add/subtract page margins and/or header/footer heights or something like that. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88809] New: EDITING: Position of OLE text object in Draw different when opened for editing
https://bugs.documentfoundation.org/show_bug.cgi?id=88809 Bug ID: 88809 Summary: EDITING: Position of OLE text object in Draw different when opened for editing Product: LibreOffice Version: Inherited From OOo Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Drawing Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: fdb...@neosheffield.co.uk This is split off bug 51508 (See also bug 88808 regarding the mis-rendering of the content of the text object) Observed on LO 4.4.0.2 (Ubuntu 14.04, OSX 10.10) and 3.3.0.4 (OSX 10.10) When an OLE text object in Draw is opened for editing, it is displayed in a different position to its bounds when not editing Steps to reproduce 1. Open the attached sample file 2. Double click on the OLE text object (in the middle of 4 lines which mark its boundary) to edit it Expected results - Either the whole OLE editor or at least its active editing area should be within the lines which mark its display boundary Actual results - The OLE editor is offset from its displayed bounds -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88810] New: FILESAVE: avoid unnecessary massive OUString/OString allocations in XLSX export
https://bugs.documentfoundation.org/show_bug.cgi?id=88810 Bug ID: 88810 Summary: FILESAVE: avoid unnecessary massive OUString/OString allocations in XLSX export Product: LibreOffice Version: unspecified Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: Spreadsheet Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: nem...@numbertext.org During the export of an OOXML file, creating the simple A1-like addresses of cells are solved by (for example, million unnecessary) OUString and OString allocations, resulting noticeable overhead. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88811] FILEOPEN: Drawing lines not imported from RTF
https://bugs.documentfoundation.org/show_bug.cgi?id=88811 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added Keywords||regression CC||fdb...@neosheffield.co.uk See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=58 ||736 Whiteboard||bibisected --- Comment #1 from Matthew Francis fdb...@neosheffield.co.uk --- Bibisect results from 43all: c50786b73d50e49dc6491e46957dcb0c3900cdcd is the first bad commit commit c50786b73d50e49dc6491e46957dcb0c3900cdcd Author: Bjoern Michaelsen bjoern.michael...@canonical.com Date: Sun May 11 13:24:02 2014 + source-hash-54cbd46dc52c51dda1594ee090f0619a7b92d56a commit 54cbd46dc52c51dda1594ee090f0619a7b92d56a # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4 git bisect start 'latest' 'last42onmaster' # bad: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e git bisect bad 4fcd68ce4979f85fda4568f4b419a4b41d07345f # good: [0d4c20a601a3cfff27d6685d0e81463086bd9d74] source-hash-f1b1e73227471192682d303a58618ca8bd65a74d git bisect good 0d4c20a601a3cfff27d6685d0e81463086bd9d74 # good: [3c72d6d27e2a0c420f74941355400b0834c550bb] source-hash-c30677731c55688c764a669ecea1b1c4d17ae57d git bisect good 3c72d6d27e2a0c420f74941355400b0834c550bb # skip: [c70dac3423c13ae0c425212ed71f0e7503555c5a] source-hash-1f74a3ce201bad68f160584900285e2c087ab2c0 git bisect skip c70dac3423c13ae0c425212ed71f0e7503555c5a # bad: [6738b3ad82bbc77ce9a788be07da490e530de3ff] source-hash-43fc67adcc3bdc5efaaaf9b0d65e53e99880b18a git bisect bad 6738b3ad82bbc77ce9a788be07da490e530de3ff # bad: [4563c2121c987ab142c58f0cd6c665dd8790a8c9] source-hash-14829a84ff4f77091767cf4503db0c8a6624f036 git bisect bad 4563c2121c987ab142c58f0cd6c665dd8790a8c9 # good: [d25426a90080eae2d7a21b2258245dd1a7d28f1a] source-hash-33c7ecf870b47bdadda908834cc259ea81d69754 git bisect good d25426a90080eae2d7a21b2258245dd1a7d28f1a # bad: [a7dc22c40cc4b6c8c0ecf73268597c873aa2543a] source-hash-f4ae06c6b558628457f3abdade1f2a705bf8b886 git bisect bad a7dc22c40cc4b6c8c0ecf73268597c873aa2543a # good: [4cb28129efbb5aaf54b37ea5eab772c822a80298] source-hash-9bf907a8278cecd816368db7b8c4ab745a914a59 git bisect good 4cb28129efbb5aaf54b37ea5eab772c822a80298 # bad: [c50786b73d50e49dc6491e46957dcb0c3900cdcd] source-hash-54cbd46dc52c51dda1594ee090f0619a7b92d56a git bisect bad c50786b73d50e49dc6491e46957dcb0c3900cdcd # first bad commit: [c50786b73d50e49dc6491e46957dcb0c3900cdcd] source-hash-54cbd46dc52c51dda1594ee090f0619a7b92d56 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=68 ||137 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 58736] FILEOPEN: Writer hangs with 50% CPU when open particular .RTF file
https://bugs.documentfoundation.org/show_bug.cgi?id=58736 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added Status|NEW |RESOLVED CC||fdb...@neosheffield.co.uk Resolution|--- |WORKSFORME Whiteboard|bibisectRequest | --- Comment #11 from Matthew Francis fdb...@neosheffield.co.uk --- The original issue reported on this bug, that attachment 72096 fails to load, no longer occurs as of LO 4.3.5.1 and 4.4.0.2. As only a single issue should be dealt with on a bug, I am closing this bug. A separate issue with the table border lines in attachment 72096, and the slow speed of importing attachment 82177 have been raised separately as bug 88811 and 88812 respectively. - RESOLVED WORKSFORME (as the specific commit which fixed the issue has not been identified) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 68137] ODT Document crash when editing script fields / script editor
https://bugs.documentfoundation.org/show_bug.cgi?id=68137 Timur gti...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW CC||gti...@gmail.com Version|4.1.0.4 release |4.0.0.0 beta1 See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=50 ||640 OS|Windows (All) |All --- Comment #14 from Timur gti...@gmail.com --- Looks like it started from 4.0 because 3.6.7.2 was OK. Regression? Happens both on Windows and Linux. Reproduce on 4.4.0. Previously added backtrace for the file to reproduce a bug. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: Workflow between dev, UX and l10n teams
Hi Kendy, Le 26/01/2015 15:43, Jan Holesovsky a écrit : Hi Sophie, Mihovil, Mihovil Stanić píše v Po 26. 01. 2015 v 10:25 +0100: Cosmetic changes (~ to _ or Status to Status: or ... to … or those different quote styles I don't even have on my keyboard) and anything similliar - NOT OK if you don't script it for all languages Cosmetic changes (Big brown fox - Big Brown Fox) - NOT OK at all, change just for en_us, don't change my strings and don't even notify me you did it in en_us I see 2 problems here: 1) There is no tool that would detect these trivial changes, and would act accordingly. 2) The texts for translations are updated in big 'code' drops, without possibility for translators to affect the process in any way - for them it is too late. Regarding 1) - I thought that Pootle is detecting the trivial changes some way, and offering the original translation. Is it not? What can be done to improve that, so that for translators it is just a matter of checking; not a matter of translating? [Or even what you suggest - that it would just update the source strings without touching the translations?] Pootle will show you a modified string, even if it doesn't affect your translation you will have to validate the string again to have it on a translated state. Also we don't all work on Pootle, several of us are working off line and Pootle is only a repository for our files. That's why we were thinking of a en_US version as a real language and different from the sources and also about scripting changes when possible (like the substitution of ~ by _) Regarding 2) - I'm glad that you say that the strings will be now getting to Pootle immediately after the code / string changes in master. I think it is important that the translators will be able to deal with the changes immediately, not several months later, so that they can cooperate, and not only react. yes, that's much better, even if we have to be cautious about the workflow. In general, I don't think that setting extremely strict rules works, unless you have means how to enforce them - like via a commit hook or so (and it is extremely unpopular way to do things). It is always much better to communicate - if you see a developer who commits a change that causes you grief, please _do_ tell _him/her_ immediately, and - if possible - in a friendly way. I'm sure he/she will do much better the next time. Translators are for most of them non technical people and will not see a commit, but only the result on Pootle, sometimes months later. In the same way the developer who is doing tons of changes for en_US is invited to discuss them with the l10n team :) Unfortunately I did not see any signs of notice that this or that change was problematic for localization on the development mailing list - were there such warnings there? Like commit XY caused AB - please don't do such things, unless we agree how to do that effectively / without pain? Or was it impossible so far because the strings in Pootle were not synced with master? Yes, I think it was too late and when the l10n team is at work, it's the rush i.e RC time for developers, so not the best period to discuss hot topics ;) That's why I've waited to open this discussion. Also, even if I've discussed as much as possible about l10n on issues concerning UI changes, it's a lot of work to follow each commit that could have an effect. Sharing the effort between developers/UX/l10n teams should be possible. As we follow Gnome HIG, adding it as pre-requisite for UI changes/adds may prevent to have to rewrite dialogs for example. Also - should we have a 'Localization' recurring topic in the ESC? Who would be the right representative there, please? Maybe not as a recurring topic, but something that should be in mind of UX team and developers when they commit or check for commits that have a huge impact on l10n. Cheers Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Co-founder - Release coordinator The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 88810] FILESAVE: avoid unnecessary massive OUString/OString allocations in XLSX export
https://bugs.documentfoundation.org/show_bug.cgi?id=88810 László Németh nem...@numbertext.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 68137] ODT Document crash when editing script fields / script editor
https://bugs.documentfoundation.org/show_bug.cgi?id=68137 --- Comment #13 from Timur gti...@gmail.com --- Created attachment 112809 -- https://bugs.documentfoundation.org/attachment.cgi?id=112809action=edit Kundenzahlungen crash backtrace with LO 4.4.0 on Win7 x64.txt -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 51169] FILESAVE: Saving odt to doc: removed pagenumbers
https://bugs.documentfoundation.org/show_bug.cgi?id=51169 Joel Madero jmadero@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 49641] Tables lost in a frame
https://bugs.documentfoundation.org/show_bug.cgi?id=49641 Beluga todven...@suomi24.fi changed: What|Removed |Added CC||todven...@suomi24.fi --- Comment #3 from Beluga todven...@suomi24.fi --- Created attachment 112810 -- https://bugs.documentfoundation.org/attachment.cgi?id=112810action=edit PDF output of .doc opened in MSO 2013 PDF saved from MSO 2013 for reference. LibO renders the .doc badly. Win 8.1 32-bit LibreOffice Version: 4.5.0.0.alpha0+ Build ID: 784d069cc1d9f1d6e6a4e543a278376ab483d1eb TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-25_23:07:36 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 47047] [FORMATTING, FILESAVE] Paragraph spacing not properly exported to xls in comments
https://bugs.documentfoundation.org/show_bug.cgi?id=47047 Beluga todven...@suomi24.fi changed: What|Removed |Added CC||todven...@suomi24.fi --- Comment #5 from Beluga todven...@suomi24.fi --- Still happens. Win 8.1 32-bit MSO 2013 LibreOffice Version: 4.5.0.0.alpha0+ Build ID: 784d069cc1d9f1d6e6a4e543a278376ab483d1eb TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-25_23:07:36 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Joel Madero jmadero@gmail.com changed: What|Removed |Added Keywords||want-backtrace CC||jmadero@gmail.com --- Comment #8 from Joel Madero jmadero@gmail.com --- Would be good to get a backtrace on this: https://wiki.documentfoundation.org/Development/How_to_debug -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 58736] FILEOPEN: Writer hangs with 50% CPU when open particular .RTF file
https://bugs.documentfoundation.org/show_bug.cgi?id=58736 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||811 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88812] New: FILEOPEN: Performance regression in speed of RTF import
https://bugs.documentfoundation.org/show_bug.cgi?id=88812 Bug ID: 88812 Summary: FILEOPEN: Performance regression in speed of RTF import Product: LibreOffice Version: 4.0.6.2 release Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: filters and storage Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: fdb...@neosheffield.co.uk This is split from bug 58736. Observed on OSX 10.10, LO 4.0.6.2 and later. Speed is good up to at least 3.4.6.2; releases after 3.4.6.2 and before 4.0.6.2 are slow but also hang at the end of the import. Steps to reproduce: 1. Load the RTF file from attachment 82177 Expected result: - File loads as quickly as in LO 3.3.0 Actual result: - File loads much more slowly than in LO 3.3.0 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88810] FILESAVE: avoid unnecessary massive OUString/OString allocations in XLSX export
https://bugs.documentfoundation.org/show_bug.cgi?id=88810 --- Comment #2 from László Németh nem...@numbertext.org --- Created attachment 112808 -- https://bugs.documentfoundation.org/attachment.cgi?id=112808action=edit kcachegrind profile of the optimization -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-commits] core.git: unotools/qa unotools/source vcl/generic
unotools/qa/unit/testGetEnglishSearchName.cxx |7 +++ unotools/source/misc/fontdefs.cxx |2 -- vcl/generic/fontmanager/fontcache.cxx |2 +- 3 files changed, 4 insertions(+), 7 deletions(-) New commits: commit 15e1c881684c0127c0ca989924bbf2508b4fd780 Author: Caolán McNamara caol...@redhat.com Date: Mon Jan 26 15:00:29 2015 + don't strip font names of apparent script suffixes anymore e.g. CM Roman CE should be left alone. bump font cache id to invalidate old cached lists I think this practice stems from Window 3.1/Word 95 where the encoding was included in the font name http://www.webcenter.ru/~kazarn/eng/fonts_ttf.htm#charsettbl Microsoft Office still generates RTF files with weird-ass Win 3.1 style fontnames but any actual existing fonts that happen to have names that fall into that pattern should be left alone now. Change-Id: Ibb704048d63b33ce510d6b1076700c6e94a0af2a diff --git a/unotools/qa/unit/testGetEnglishSearchName.cxx b/unotools/qa/unit/testGetEnglishSearchName.cxx index dbc8b17..c9d8e1f 100644 --- a/unotools/qa/unit/testGetEnglishSearchName.cxx +++ b/unotools/qa/unit/testGetEnglishSearchName.cxx @@ -39,12 +39,11 @@ void Test::testSingleElement() //trailingWhitespaces test1 = GetEnglishSearchFontName( Symbol ); CPPUNIT_ASSERT_EQUAL(OUString(symbol),test1); -//removing Skripts +//no longer remove script suffixes test1 = GetEnglishSearchFontName( Symbol(SIP) ); CPPUNIT_ASSERT_EQUAL(OUString(symbol(sip)),test1); -//remove Whitespaces between -test1 = GetEnglishSearchFontName( Symbol (thai) ); -CPPUNIT_ASSERT_EQUAL( OUString(symbol),test1); +test1 = GetEnglishSearchFontName( CM Roman CE ); +CPPUNIT_ASSERT_EQUAL( OUString(cmromance),test1); //remove special characters; leave semicolon, numbers test1 = GetEnglishSearchFontName( sy;mb?=ol129 ); CPPUNIT_ASSERT_EQUAL( OUString(sy;mbol129),test1); diff --git a/unotools/source/misc/fontdefs.cxx b/unotools/source/misc/fontdefs.cxx index f368cc6..04c6fc4 100644 --- a/unotools/source/misc/fontdefs.cxx +++ b/unotools/source/misc/fontdefs.cxx @@ -367,8 +367,6 @@ OUString GetEnglishSearchFontName(const OUString rInName) if ( i != nLen ) rName.truncate(i); -// Remove Script at the end -rName = StripScriptFromName(rName.toString()); nLen = rName.getLength(); // remove all whitespaces and converts to lower case ASCII diff --git a/vcl/generic/fontmanager/fontcache.cxx b/vcl/generic/fontmanager/fontcache.cxx index 56a15bf..e978eb7 100644 --- a/vcl/generic/fontmanager/fontcache.cxx +++ b/vcl/generic/fontmanager/fontcache.cxx @@ -38,7 +38,7 @@ #endif #define FONTCACHEFILE /user/psprint/pspfontcache -#define CACHE_MAGIC LibreOffice PspFontCacheFile format 5 +#define CACHE_MAGIC LibreOffice PspFontCacheFile format 6 using namespace std; using namespace psp; ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 --- Comment #7 from Timur gti...@gmail.com --- Created attachment 112812 -- https://bugs.documentfoundation.org/attachment.cgi?id=112812action=edit Third example for crash on browsing Fields via Edit Fields I add a third example for crash on browsing Fields via Edit Fields: 1. turn on View-Field Shadings 2. click on some of the grayed fields 3. now that Edit-Fields is enabled, open it 4. in the Edit Fields dialog, browse with right arrow till the end 5. LO Writer crashes Fields do not have to be hidden, and this one seems easier to reproduce. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 68137] ODT Document crash when editing script fields / script editor
https://bugs.documentfoundation.org/show_bug.cgi?id=68137 Timur gti...@gmail.com changed: What|Removed |Added Keywords||have-backtrace -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
Le 26/01/2015 10:49, Miklos Vajna a écrit : Hi Miklos, https://wiki.documentfoundation.org/Development/ReleaseBuilds documents that the gdrive flags are also used for TDF builds, so they are available for the general public. Thanks, but that page references x86 builds for MacOSX and not x86_64. Is it still applicable for our 64bit OSX releases ? Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 88787] FILEOPEN: Numbers formatted as dates before AD 1-01-04 corrupted
https://bugs.documentfoundation.org/show_bug.cgi?id=88787 raal r...@post.cz changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||r...@post.cz Ever confirmed|0 |1 --- Comment #1 from raal r...@post.cz --- I can confirm with Version: 4.5.0.0.alpha0+ Build ID: 60143f4f7bc50054dcef923218b8c7c3bc154933 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-21_04:58:34 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 --- Comment #10 from Timur gti...@gmail.com --- OK, done under 5 minutes, I hope it's acceptable :) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88794] EDITING, editing subtotal function options adds columns group
https://bugs.documentfoundation.org/show_bug.cgi?id=88794 raal r...@post.cz changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||r...@post.cz Version|4.3.5.2 release |3.5.0 release Ever confirmed|0 |1 OS|Windows (All) |All --- Comment #1 from raal r...@post.cz --- I can confirm with Version: 4.5.0.0.alpha0+ Build ID: 60143f4f7bc50054dcef923218b8c7c3bc154933 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-21_04:58:34 Reproducible with LO 3.5, lowering version -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: Workflow between dev, UX and l10n teams
Hi Sophie, Sophie píše v Po 26. 01. 2015 v 16:19 +0100: Pootle will show you a modified string, even if it doesn't affect your translation you will have to validate the string again to have it on a translated state. Also we don't all work on Pootle, several of us are working off line and Pootle is only a repository for our files. But the offline files are taken from Pootle too - right? So if fixes are done at the time of uploading to Pootle, everybody gets them - correct? That's why we were thinking of a en_US version as a real language and different from the sources and But at some stage this will have to apply to the sources - and at that time, it will be even worse than now :-( I'm afraid having en_US as a separate language will make the situation worse, not better. also about scripting changes when possible (like the substitution of ~ by _) Sure - so I think this was something that could have been automatized with a trivial script; when this was noticed for the first time, please? Pity that it was not brought to the ESC as a problem... Translators are for most of them non technical people and will not see a commit, but only the result on Pootle, sometimes months later. The months later is the problem, not the non-technicality :-) It is enough to send something happened yesterday - please check what's up; similarly to how people are checking the daily builds. Also - should we have a 'Localization' recurring topic in the ESC? Who would be the right representative there, please? Maybe not as a recurring topic, but something that should be in mind of UX team and developers when they commit or check for commits that have a huge impact on l10n. Well - if it's not recurring, it's easy to forget ;-) Also I think it will be more effective to discuss this there - are you able to join this Thursday? All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 88810] FILESAVE: avoid unnecessary massive OUString/OString allocations in XLSX export
https://bugs.documentfoundation.org/show_bug.cgi?id=88810 --- Comment #3 from László Németh nem...@numbertext.org --- Submitted patch: https://gerrit.libreoffice.org/#/c/14187/ -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Joel Madero jmadero@gmail.com changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 --- Comment #9 from Timur gti...@gmail.com --- Created attachment 112813 -- https://bugs.documentfoundation.org/attachment.cgi?id=112813action=edit Timur's koverta from Comment 7 - backtrace.txt -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added Keywords||have-backtrace -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 58736] FILEOPEN: Writer hangs with 50% CPU when open particular .RTF file
https://bugs.documentfoundation.org/show_bug.cgi?id=58736 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||812 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88812] FILEOPEN: Performance regression in speed of RTF import
https://bugs.documentfoundation.org/show_bug.cgi?id=88812 Matthew Francis fdb...@neosheffield.co.uk changed: What|Removed |Added Keywords||regression CC||fdb...@neosheffield.co.uk See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=58 ||736 Whiteboard||perf preBibisect --- Comment #1 from Matthew Francis fdb...@neosheffield.co.uk --- Looking past the fact that the file fails to finish loading in the early part of the 43all bibisect repo, the speed at which the import occurs (before the hang) suggests that this problem is pre-bibisect Adjusting metadata to suit. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88803] Document Text Doesn't Reflow on Zoom
https://bugs.documentfoundation.org/show_bug.cgi?id=88803 --- Comment #1 from definesinsan...@gmail.com --- This is not a bug. You can't just go and change all of the formatting on a word processor document. Must remember that the target for a document will most likely be printed paper. The entire system is designed to show you the document exactly as it will appear on physical paper. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added CC||gti...@gmail.com --- Comment #6 from Timur gti...@gmail.com --- Created attachment 112811 -- https://bugs.documentfoundation.org/attachment.cgi?id=112811action=edit Leif's BrevSkabelon from Comment 0 - backtrace.txt I can reproduce Leif's example with attachment 62451: 1. turn on View-Field Shadings and View-Field Names 2. click within the first of the 4 Hidden Paragraph fields (in the frame) 3. now that Edit-Fields is enabled, open it 4. in the Edit Fields dialog, browse with right arrow till the end 5. LO Writer crashes Tested with Lo 4.3.5 and 4.4.0.2. Set as inherited and Reopened. Please set as New. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added Version|3.6.0.0.alpha1 |Inherited From OOo -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 56768] FILESAVE: xls file with pivot table when saved with password pivot table will not work when re-open
https://bugs.documentfoundation.org/show_bug.cgi?id=56768 Beluga todven...@suomi24.fi changed: What|Removed |Added Status|NEW |RESOLVED CC||todven...@suomi24.fi Resolution|--- |WORKSFORME --- Comment #3 from Beluga todven...@suomi24.fi --- Could not repro. I used an example pivot table from here: http://www.ahuka.com/?page_id=911 In LibO, I did Tools - Protect document - Sheet. Saved as .xls. Nothing was lost. Closing as WFM. Win 8.1 32-bit LibreOffice Version: 4.5.0.0.alpha0+ Build ID: 784d069cc1d9f1d6e6a4e543a278376ab483d1eb TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-25_23:07:36 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added OS|Linux (All) |All -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: Workflow between dev, UX and l10n teams
Hi Kendy, Le 26/01/2015 16:40, Jan Holesovsky a écrit : Hi Sophie, Sophie píše v Po 26. 01. 2015 v 16:19 +0100: Pootle will show you a modified string, even if it doesn't affect your translation you will have to validate the string again to have it on a translated state. Also we don't all work on Pootle, several of us are working off line and Pootle is only a repository for our files. But the offline files are taken from Pootle too - right? So if fixes are done at the time of uploading to Pootle, everybody gets them - correct? yes, I'll have a meeting with Dwayne (Pootle developer) during Fosdem and will discuss with him about that. That's why we were thinking of a en_US version as a real language and different from the sources and But at some stage this will have to apply to the sources - and at that time, it will be even worse than now :-( I'm afraid having en_US as a separate language will make the situation worse, not better. Yes, I'm not sure either also about scripting changes when possible (like the substitution of ~ by _) Sure - so I think this was something that could have been automatized with a trivial script; when this was noticed for the first time, please? Pity that it was not brought to the ESC as a problem... It was brought on the dev list, but when the l10n team discovered it, it was too late. Cloph has already scripted several changes, but he can't do it all. Translators are for most of them non technical people and will not see a commit, but only the result on Pootle, sometimes months later. The months later is the problem, not the non-technicality :-) It is enough to send something happened yesterday - please check what's up; similarly to how people are checking the daily builds. that will be possible now that some of us are translating on master Also - should we have a 'Localization' recurring topic in the ESC? Who would be the right representative there, please? Maybe not as a recurring topic, but something that should be in mind of UX team and developers when they commit or check for commits that have a huge impact on l10n. Well - if it's not recurring, it's easy to forget ;-) Also I think it will be more effective to discuss this there - are you able to join this Thursday? Thanks for the invitation and yes, let me know the time and I'll join. Cheers Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Co-founder - Release coordinator The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 88810] FILESAVE: avoid unnecessary massive OUString/OString allocations in XLSX export
https://bugs.documentfoundation.org/show_bug.cgi?id=88810 --- Comment #1 from László Németh nem...@numbertext.org --- Created attachment 112807 -- https://bugs.documentfoundation.org/attachment.cgi?id=112807action=edit kcachegrind profile/overhead of the original function -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 50640] CRASH when EDITING hidden paragraphs fields
https://bugs.documentfoundation.org/show_bug.cgi?id=50640 Timur gti...@gmail.com changed: What|Removed |Added Status|REOPENED|NEW -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 56183] [APPHANG][docx] [fileopen] Writer doesn't open large table
https://bugs.documentfoundation.org/show_bug.cgi?id=56183 Timur gti...@gmail.com changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=59 ||918 --- Comment #3 from Timur gti...@gmail.com --- I think this is inherited. Reproduced with LO 4.2.8 and 4.3.5 but behavior changed starting from LO 4.4.0: Writer doesn't hang but opens the DOCX file very slowly (takes 2 minutes for 321 pages). Working with this file is also slow. I suggest this be renamed to FILEOPEN: Writer extremely slow to open and handle specific DOCX. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 59918] FILESAVE: FILEOPEN: save document as docx and reopen result in an freeze/endless loop
https://bugs.documentfoundation.org/show_bug.cgi?id=59918 Timur gti...@gmail.com changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=56 ||183 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88512] TOOLBARS: Character style drop down control
https://bugs.documentfoundation.org/show_bug.cgi?id=88512 --- Comment #4 from Jay Philips philip...@hotmail.com --- (In reply to Cor Nouws from comment #3) Never new there was a shortcut for the styles dropdown. :D Oh dear, so much to learn ;p Yes dear, i'm not a heavy keyboard user. :D I now see that Ctrl+Shft+F11 is Update Style... Dangerous one! Shall we asign Ctrl+Alt+F11 to apply character style? Or dump the assigment to Update Style and use Ctrl+Shft+F11? Wouldnt really know about this as i'm not a keyboard user. Maybe ask sophie. :D Well the idea would be that users who only use styles would likely disable the font name drop down and replace it with the character style drop down, or simply just enable it next to it if they have a sufficiently wide resolution. OK, maybe a preference pops up gradually to add it by default. We'll see. I am contemplating how best to include it by default but seem to fall short on it because i see the benefit of having all four drop downs, but think they would take up way to much space. [side note: ever considered a style drop down in Calc?] I've considered it but we dont have a good set of default styles in calc ( https://redmine.documentfoundation.org/boards/1/topics/493 ) and we dont have any free space in the toolbar for it presently. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-commits] core.git: Branch 'libreoffice-4-4' - sc/inc sc/source
sc/inc/address.hxx |3 --
sc/source/core/tool/address.cxx | 45
sc/source/filter/excel/xestream.cxx | 10
sc/source/filter/excel/xetable.cxx | 14 ++-
sc/source/filter/inc/xestream.hxx |2 -
5 files changed, 3 insertions(+), 71 deletions(-)
New commits:
commit 8820d21f81a9b6f89e40216f2191c019651cfe4d
Author: Németh László nem...@numbertext.org
Date: Mon Jan 26 19:13:53 2015 +
Revert fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX
export
This reverts commit ace8f9c2a31795cc2329c6bb27deacde9f4c18df.
(Interestingly, reverting the original patch in the master pushed this one
in libreoffice-4-4 automatically, sorry.)
Change-Id: I0d3048b58aea0c84fa0b287e711a5d7cda7ab8fc
Reviewed-on: https://gerrit.libreoffice.org/14188
Reviewed-by: Németh László nem...@numbertext.org
Tested-by: Németh László nem...@numbertext.org
diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index aa05a58..06c450b 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,9 +325,6 @@ public:
ExternalInfo* pExtInfo = NULL,
const css::uno::Sequencecss::sheet::ExternalLinkInfo*
pExternalLinks = NULL );
-SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
- const ScDocument* pDocument = NULL,
- const Details rDetails = detailsOOOa1)
const;
SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
const ScDocument* pDocument = NULL,
const Details rDetails = detailsOOOa1)
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index bb7a1bf..1efcac7 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,51 +1745,6 @@ static OUString getFileNameFromDoc( const ScDocument*
pDoc )
return sFileName;
}
-/** Tries to obtain a simple address without OUString/OString allocation
- *
- * @returns TRUE at success (it is enough to call OUString Format() at FALSE)
- *
- */
-
-bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
- const Details rDetails) const
-{
-if( nFlags SCA_VALID )
-nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
-if(( pDoc (nFlags SCA_VALID_TAB ) ( nTab = pDoc-GetTableCount()
|| ( nFlags SCA_TAB_3D ))) ||
- ! (nFlags SCA_VALID_COL) || ! (nFlags SCA_VALID_ROW) ||
-(nFlags SCA_COL_ABSOLUTE) != 0 || (nFlags SCA_ROW_ABSOLUTE) !=
0 )
-{
- return false;
-}
-
-switch( rDetails.eConv )
-{
-default :
-// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following
simple addresses
-case formula::FormulaGrammar::CONV_OOO:
-case formula::FormulaGrammar::CONV_XL_A1:
-case formula::FormulaGrammar::CONV_XL_OOX:
-if (nCol = 26 * 26)
-// TODO: extend it for full column range
-return false;
-if( nCol 26 )
-*s = 'A' + nCol;
-else
-{
-*s = 'A' + nCol / 26 - 1;
-s++;
-*s = 'A' + nCol % 26;
-}
-sprintf(s + 1, %d, nRow + 1);
-break;
-case formula::FormulaGrammar::CONV_XL_R1C1:
-// not used in XLSX export
-return false;
-}
-return true;
-}
-
OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details rDetails) const
{
diff --git a/sc/source/filter/excel/xestream.cxx
b/sc/source/filter/excel/xestream.cxx
index 188fcd6..e5ff50c 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,11 +718,6 @@ OString XclXmlUtils::ToOString( const OUString s )
return OUStringToOString( s, RTL_TEXTENCODING_UTF8 );
}
-bool XclXmlUtils::TryToChar( char * s, const ScAddress rAddress )
-{
-return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1));
-}
-
OString XclXmlUtils::ToOString( const ScAddress rAddress )
{
OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1)));
@@ -765,11 +760,6 @@ static ScAddress lcl_ToAddress( const XclAddress rAddress
)
return aAddress;
}
-bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress rAddress )
-{
-return TryToChar( s, lcl_ToAddress( rAddress ));
-}
-
OString XclXmlUtils::ToOString( const XclAddress rAddress )
{
return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx
b/sc/source/filter/excel/xetable.cxx
index f32cdce..23adf6e 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,11 +41,6 @@ using namespace ::oox;
namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
[Libreoffice-bugs] [Bug 88500] Android: documents in third level folder are not opened
https://bugs.documentfoundation.org/show_bug.cgi?id=88500 --- Comment #10 from Cor Nouws c...@nouenoff.nl --- Build ID: 3ac52a60d570fb8afb3d8ad063e35f0667b385cb Was too lazy ;) -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88807] Table cell diagonal line not supported
https://bugs.documentfoundation.org/show_bug.cgi?id=88807 A (Andy) stgohi-lob...@yahoo.de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from A (Andy) stgohi-lob...@yahoo.de --- Marked as enhancement request -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: [Libreoffice-qa] [LibreOffice Bugzilla Migration] We're done! Please visit the new site to reset your password!
On 24.01.2015 21:50, Robinson Tryon wrote: If you have any questions or encounter any problems, please stop by the QA IRC channel or drop us a note on the mailing list: https://wiki.documentfoundation.org/QA/IRC https://wiki.documentfoundation.org/QA/Mailing_List if i go to Saved Searches there are a whole bunch of XOrg and GPU driver related ones imported from FDO; somebody with sufficient privileges needs to clean up there. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice-bugs] [Bug 88496] LibreOffice does handles Header Tables in unpredictable way in specific conditions; different from MSWord
https://bugs.documentfoundation.org/show_bug.cgi?id=88496 tommy27 ba...@quipo.it changed: What|Removed |Added Status|NEW |NEEDINFO CC||ba...@quipo.it Version|4.3.5.2 release |3.6.4.3 release --- Comment #3 from tommy27 ba...@quipo.it --- I update the version field to 3.6.4.3 which is the first release where you reproduced the bug. I revert status to UNCONFIRMED since status NEW has to be set only after independent confirmation by another user. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88496] LibreOffice does handles Header Tables in unpredictable way in specific conditions; different from MSWord
https://bugs.documentfoundation.org/show_bug.cgi?id=88496 tommy27 ba...@quipo.it changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88803] Document Text Doesn't Reflow on Zoom
https://bugs.documentfoundation.org/show_bug.cgi?id=88803 --- Comment #5 from V Stuart Foote vstuart.fo...@utsa.edu --- It is rendering the XML of ODF and OOXML documents into correct WYSIWYG representations of the document. Scrolling with swiping, or zooming with pinch, of that fully rendered document is the only interface intended. It is not an e-Book reader. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88814] New: VIEWING: Subform linked to Addressbook results in parameter count error
https://bugs.documentfoundation.org/show_bug.cgi?id=88814 Bug ID: 88814 Summary: VIEWING: Subform linked to Addressbook results in parameter count error Product: LibreOffice Version: unspecified Hardware: All OS: Mac OS X (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Database Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: tanta...@gmx.net Created attachment 112815 -- https://bugs.documentfoundation.org/attachment.cgi?id=112815action=edit Standalone form to be connected to a name database and address book Hello, I have a simple standalone form with the main form attached to a ODB database with a firstname|lastname table and a subform linked to the standard address book. The two tables are connected via first and last name matches (s. attachement). The original intention was to display additional contact information stored in the address book related to a particular name. On a Mac using OSX Yosemite, the form doesn't work and an error pops up telling me, that the entered number of parameters does not match the number of actual parameters (SQL-Status: HY000). The same form works without any problems using Ubuntu! When I switch the main and subform and its dependencies then it works on the Mac too; but that's now what I need. Regards -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88813] Lack of alpha-numeric list numbering for proper appendix numbering
https://bugs.documentfoundation.org/show_bug.cgi?id=88813 A (Andy) stgohi-lob...@yahoo.de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from A (Andy) stgohi-lob...@yahoo.de --- Marked as enhancement request -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
On Mon, Jan 26, 2015 at 05:16:14PM +0100, Alexander Thurgood alex.thurg...@gmail.com wrote: Thanks, but that page references x86 builds for MacOSX and not x86_64. Is it still applicable for our 64bit OSX releases ? Norbert, am I right that just a simple x86 - 64bit rename is needed at https://wiki.documentfoundation.org/Development/ReleaseBuilds#Mac_x86, or you use different switches? Thanks, Miklos signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 86355] executable bit is set on non-executable files CREDITS, LICENSE and NOTICE
https://bugs.documentfoundation.org/show_bug.cgi?id=86355 --- Comment #5 from Robinson Tryon (qubit) qu...@runcibility.com --- (In reply to Richard PALO from comment #4) Some more setup needed for my git clone? Yep, there are git submodules, so after the clone, do ./g checkout master I believe that will do the right thing with submodules, both init-ing and updating them. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88801] Android: Can't load flat ODF
https://bugs.documentfoundation.org/show_bug.cgi?id=88801 Robinson Tryon (qubit) qu...@runcibility.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|unspecified |4.5.0.0.alpha0+ Master Ever confirmed|0 |1 Whiteboard||filter:fodt --- Comment #2 from Robinson Tryon (qubit) qu...@runcibility.com --- (In reply to Robinson Tryon (qubit) from comment #1) Using same setup to test. It would be great to track down why flat ODF doesn't work in the Android app, then we could start shipping the flat ODF version of the license document instead. Here's another FODT test file: attachment 111034 (Bug 87483 - weird list behavior) (I have trouble trying to download that file with Firefox or w/the default Android browser. Side-loading it from my laptop, the filetype isn't recognized in Android and associated with LibreOffice) Because I can't manage to open an external FODT file at all, Status - NEW -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88803] Document Text Doesn't Reflow on Zoom
https://bugs.documentfoundation.org/show_bug.cgi?id=88803 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||vstuart.fo...@utsa.edu Resolution|--- |INVALID --- Comment #2 from V Stuart Foote vstuart.fo...@utsa.edu --- If you select text and resize the text larger, it will reflow within the current view. That is the effect you may be thinking of and is common with e-readers. Sorry, not very useful for a productivity suite, even just a viewer like this for Android. -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
On Mon, Jan 26, 2015 at 11:22 AM, Miklos Vajna vmik...@collabora.co.uk wrote: On Mon, Jan 26, 2015 at 05:16:14PM +0100, Alexander Thurgood alex.thurg...@gmail.com wrote: Thanks, but that page references x86 builds for MacOSX and not x86_64. Is it still applicable for our 64bit OSX releases ? Norbert, am I right that just a simple x86 - 64bit rename is needed at https://wiki.documentfoundation.org/Development/ReleaseBuilds#Mac_x86, or you use different switches? s/x86/Intel/ should be enough. As I said the reason we mention x86 is to distinguish with ppc... it has never been a 32/64 bits issue. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-bugs] [Bug 86355] executable bit is set on non-executable files CREDITS, LICENSE and NOTICE
https://bugs.documentfoundation.org/show_bug.cgi?id=86355 --- Comment #4 from Richard PALO rich...@netbsd.org --- Some more setup needed for my git clone? richard@omnis:/home/richard/src$ umask 0022 richard@omnis:/home/richard/src$ export LO_GIT=/home/richard/src/libreofficerichard@omnis:/home/richard/src$ $LO_GIT/bin/lo-pack-sources --xz --set-version=4.3.5.2 $LO_GIT Source: /home/richard/src/libreoffice Detected module: core did not found: /home/richard/src/libreoffice/dictionaries/.git Warning: dictionaries sources are not available - skipping did not found: /home/richard/src/libreoffice/helpcontent2/.git Warning: help sources are not available - skipping did not found: /home/richard/src/libreoffice/translations/.git Warning: translations sources are not available - skipping New version : 4.3.5.2 Waiting 3 seconds... --- Generating core --- Copying /home/richard/src/libreoffice/ - /tmp/libreoffice-7KOsxk/libreoffice-4.3.5.2/... Removing empty submodule: dictionaries... Error: Can't remove submodule directory: /tmp/libreoffice-7KOsxk/libreoffice-4.3.5.2//dictionaries at /home/richard/src/libreoffice/bin/lo-pack-sources line 101. richard@omnis:/home/richard/src$ -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-commits] core.git: sc/inc sc/source
sc/inc/address.hxx |3 --
sc/source/core/tool/address.cxx | 45
sc/source/filter/excel/xestream.cxx | 10
sc/source/filter/excel/xetable.cxx | 14 ++-
sc/source/filter/inc/xestream.hxx |2 -
5 files changed, 3 insertions(+), 71 deletions(-)
New commits:
commit 06c752f405ec95c85045632aa41664cc8f34d493
Author: László Németh laszlo.nem...@collabora.com
Date: Mon Jan 26 19:40:17 2015 +0100
Revert fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX
export
Build problem on Android-ARM platform...
This reverts commit 0d2ce71afe0cb2657a6919e641e54c8fc9ba288c.
diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index aa05a58..06c450b 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,9 +325,6 @@ public:
ExternalInfo* pExtInfo = NULL,
const css::uno::Sequencecss::sheet::ExternalLinkInfo*
pExternalLinks = NULL );
-SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
- const ScDocument* pDocument = NULL,
- const Details rDetails = detailsOOOa1)
const;
SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
const ScDocument* pDocument = NULL,
const Details rDetails = detailsOOOa1)
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index 886b866..39fc9a4 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,51 +1745,6 @@ static OUString getFileNameFromDoc( const ScDocument*
pDoc )
return sFileName;
}
-/** Tries to obtain a simple address without OUString/OString allocation
- *
- * @returns TRUE at success (it is enough to call OUString Format() at FALSE)
- *
- */
-
-bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
- const Details rDetails) const
-{
-if( nFlags SCA_VALID )
-nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
-if(( pDoc (nFlags SCA_VALID_TAB ) ( nTab = pDoc-GetTableCount()
|| ( nFlags SCA_TAB_3D ))) ||
- ! (nFlags SCA_VALID_COL) || ! (nFlags SCA_VALID_ROW) ||
-(nFlags SCA_COL_ABSOLUTE) != 0 || (nFlags SCA_ROW_ABSOLUTE) !=
0 )
-{
- return false;
-}
-
-switch( rDetails.eConv )
-{
-default :
-// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following
simple addresses
-case formula::FormulaGrammar::CONV_OOO:
-case formula::FormulaGrammar::CONV_XL_A1:
-case formula::FormulaGrammar::CONV_XL_OOX:
-if (nCol = 26 * 26)
-// TODO: extend it for full column range
-return false;
-if( nCol 26 )
-*s = 'A' + nCol;
-else
-{
-*s = 'A' + nCol / 26 - 1;
-s++;
-*s = 'A' + nCol % 26;
-}
-sprintf(s + 1, %d, nRow + 1);
-break;
-case formula::FormulaGrammar::CONV_XL_R1C1:
-// not used in XLSX export
-return false;
-}
-return true;
-}
-
OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details rDetails) const
{
diff --git a/sc/source/filter/excel/xestream.cxx
b/sc/source/filter/excel/xestream.cxx
index 188fcd6..e5ff50c 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,11 +718,6 @@ OString XclXmlUtils::ToOString( const OUString s )
return OUStringToOString( s, RTL_TEXTENCODING_UTF8 );
}
-bool XclXmlUtils::TryToChar( char * s, const ScAddress rAddress )
-{
-return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1));
-}
-
OString XclXmlUtils::ToOString( const ScAddress rAddress )
{
OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1)));
@@ -765,11 +760,6 @@ static ScAddress lcl_ToAddress( const XclAddress rAddress
)
return aAddress;
}
-bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress rAddress )
-{
-return TryToChar( s, lcl_ToAddress( rAddress ));
-}
-
OString XclXmlUtils::ToOString( const XclAddress rAddress )
{
return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx
b/sc/source/filter/excel/xetable.cxx
index dd527d3..70f3373 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,11 +41,6 @@ using namespace ::oox;
namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
-// max string length of simple addresses (eg. ABC100\0)
-#if MAXROWCOUNT_DEFINE 999
-#define SIMPLEADDRESSLEN 11
-#endif
-
// Helper records for cell records
XclExpStringRec::XclExpStringRec( const XclExpRoot rRoot, const OUString
rResult ) :
@@ -635,10 +630,9 @@ static OString
[Libreoffice-commits] core.git: Branch 'libreoffice-4-4' - sc/inc sc/source
sc/inc/address.hxx |3 ++
sc/source/core/tool/address.cxx | 45
sc/source/filter/excel/xestream.cxx | 10
sc/source/filter/excel/xetable.cxx | 14 ---
sc/source/filter/inc/xestream.hxx |2 +
5 files changed, 71 insertions(+), 3 deletions(-)
New commits:
commit ace8f9c2a31795cc2329c6bb27deacde9f4c18df
Author: László Németh laszlo.nem...@collabora.com
Date: Mon Jan 26 15:45:05 2015 +0100
fdo#88810 avoid unnecessary massive O(U)String allocations in XLSX export
Change-Id: Ie6a024463e7ee9b0f4492b2431533708a578faf0
diff --git a/sc/inc/address.hxx b/sc/inc/address.hxx
index 06c450b..aa05a58 100644
--- a/sc/inc/address.hxx
+++ b/sc/inc/address.hxx
@@ -325,6 +325,9 @@ public:
ExternalInfo* pExtInfo = NULL,
const css::uno::Sequencecss::sheet::ExternalLinkInfo*
pExternalLinks = NULL );
+SC_DLLPUBLIC bool TryFormat( char * s, sal_uInt16 nFlags = 0,
+ const ScDocument* pDocument = NULL,
+ const Details rDetails = detailsOOOa1)
const;
SC_DLLPUBLIC OUString Format( sal_uInt16 nFlags = 0,
const ScDocument* pDocument = NULL,
const Details rDetails = detailsOOOa1)
const;
diff --git a/sc/source/core/tool/address.cxx b/sc/source/core/tool/address.cxx
index 1efcac7..bb7a1bf 100644
--- a/sc/source/core/tool/address.cxx
+++ b/sc/source/core/tool/address.cxx
@@ -1745,6 +1745,51 @@ static OUString getFileNameFromDoc( const ScDocument*
pDoc )
return sFileName;
}
+/** Tries to obtain a simple address without OUString/OString allocation
+ *
+ * @returns TRUE at success (it is enough to call OUString Format() at FALSE)
+ *
+ */
+
+bool ScAddress::TryFormat(char * s, sal_uInt16 nFlags, const ScDocument* pDoc,
+ const Details rDetails) const
+{
+if( nFlags SCA_VALID )
+nFlags |= ( SCA_VALID_ROW | SCA_VALID_COL | SCA_VALID_TAB );
+if(( pDoc (nFlags SCA_VALID_TAB ) ( nTab = pDoc-GetTableCount()
|| ( nFlags SCA_TAB_3D ))) ||
+ ! (nFlags SCA_VALID_COL) || ! (nFlags SCA_VALID_ROW) ||
+(nFlags SCA_COL_ABSOLUTE) != 0 || (nFlags SCA_ROW_ABSOLUTE) !=
0 )
+{
+ return false;
+}
+
+switch( rDetails.eConv )
+{
+default :
+// Note: length of s (defined by SIMPLEADDRESSLEN) supports the following
simple addresses
+case formula::FormulaGrammar::CONV_OOO:
+case formula::FormulaGrammar::CONV_XL_A1:
+case formula::FormulaGrammar::CONV_XL_OOX:
+if (nCol = 26 * 26)
+// TODO: extend it for full column range
+return false;
+if( nCol 26 )
+*s = 'A' + nCol;
+else
+{
+*s = 'A' + nCol / 26 - 1;
+s++;
+*s = 'A' + nCol % 26;
+}
+sprintf(s + 1, %d, nRow + 1);
+break;
+case formula::FormulaGrammar::CONV_XL_R1C1:
+// not used in XLSX export
+return false;
+}
+return true;
+}
+
OUString ScAddress::Format(sal_uInt16 nFlags, const ScDocument* pDoc,
const Details rDetails) const
{
diff --git a/sc/source/filter/excel/xestream.cxx
b/sc/source/filter/excel/xestream.cxx
index e5ff50c..188fcd6 100644
--- a/sc/source/filter/excel/xestream.cxx
+++ b/sc/source/filter/excel/xestream.cxx
@@ -718,6 +718,11 @@ OString XclXmlUtils::ToOString( const OUString s )
return OUStringToOString( s, RTL_TEXTENCODING_UTF8 );
}
+bool XclXmlUtils::TryToChar( char * s, const ScAddress rAddress )
+{
+return rAddress.TryFormat(s, SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1));
+}
+
OString XclXmlUtils::ToOString( const ScAddress rAddress )
{
OUString sAddress(rAddress.Format(SCA_VALID, NULL, ScAddress::Details(
FormulaGrammar::CONV_XL_A1)));
@@ -760,6 +765,11 @@ static ScAddress lcl_ToAddress( const XclAddress rAddress
)
return aAddress;
}
+bool XclXmlUtils::TryToChar( sal_Char * s, const XclAddress rAddress )
+{
+return TryToChar( s, lcl_ToAddress( rAddress ));
+}
+
OString XclXmlUtils::ToOString( const XclAddress rAddress )
{
return ToOString( lcl_ToAddress( rAddress ) );
diff --git a/sc/source/filter/excel/xetable.cxx
b/sc/source/filter/excel/xetable.cxx
index 23adf6e..f32cdce 100644
--- a/sc/source/filter/excel/xetable.cxx
+++ b/sc/source/filter/excel/xetable.cxx
@@ -41,6 +41,11 @@ using namespace ::oox;
namespace ApiScriptType = ::com::sun::star::i18n::ScriptType;
+// max string length of simple addresses (eg. ABC100\0)
+#if MAXROWCOUNT_DEFINE 999
+#define SIMPLEADDRESSLEN 11
+#endif
+
// Helper records for cell records
XclExpStringRec::XclExpStringRec( const XclExpRoot rRoot, const OUString
rResult ) :
@@ -630,9 +635,10 @@ static OString lcl_GetStyleId( XclExpXmlStream rStrm,
const XclExpCellBase rCe
[Libreoffice-bugs] [Bug 48783] Clipboard cleared on exit on Linux
https://bugs.documentfoundation.org/show_bug.cgi?id=48783 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||804 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 49853] EDITING: Attempting paste into find bar with Edit:Paste (or Cmd-V on OS X) pastes into document
https://bugs.documentfoundation.org/show_bug.cgi?id=49853 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=88 ||804 -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
[Libreoffice-bugs] [Bug 88804] LibreOffice blocks other applications from opening the MS Windows clipboard
https://bugs.documentfoundation.org/show_bug.cgi?id=88804 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added Summary|LibreOffice blocks other|LibreOffice blocks other |applications from opening |applications from opening |the clipboard |the MS Windows clipboard Severity|blocker |normal --- Comment #2 from V Stuart Foote vstuart.fo...@utsa.edu --- this is not a blocker in any sense -- You are receiving this mail because: You are the assignee for the bug. ___ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
