Re: Bugs report

[Németh László]

Hi Davide,

Davide Piva  ezt írta (időpont: 2023. aug. 11., P,
9:36):

> Hello László, thank you for your reply.
>
> I still had discover and currently use a workaround to exit the table,
> as for other issues in the application.
>

I'm sure it's very useful to report all the annoying things, especially
regressions.


> I follow your suggestion to list bugs/regression, please find enclosed a
> summary table. Maybe I recall or discover something else: should it be,
> I'll create a new table :-)
>

Thanks! :)

Your list seems to be quite useful (I've listed at the end of this mail).
I've tried to check the reported problems in the bug tracker, and I've
found, that the last but one has already been reported, and it is under
investigation:

https://bugs.documentfoundation.org/show_bug.cgi?id=155211 " Regression:
dashed lines become solid when breaking imported SVG / exporting to SVG"

I've created a metabug for Technical writers, and I've added this bug to it:

https://bugs.documentfoundation.org/show_bug.cgi?id=156767 "Technical"

I would like to ask you to file the other problems, and give this number
(156767) to their "Blocks:" field to extend the new metabug.

Regressions can be easily analyzed, as I wrote, so I hope we will get
information soon about the other reported problems, too.

The bug tracker will help to ask for more information or suggest
workarounds. For example, for #3 (an user-friendly document format/package
with linked images) maybe an extended hybrid PDF format could be the
solution. (Or is it the solution already?). We can also ask for help from
QA and UX experts. For example, #4 bug "Renaming 'Image' to 'Rotation' is
really confusing. It would be better to rename it to "Position" or keeping
"Image" (at least, if "Link" is there on this pane).

Thanks and best regards,
László

Writer

>From release 7.5.4.2 (regression)

Sidebar doesn't maintain its size, for example after reload the document.
Example: Choose >Navigator from side bar, fix a width, choose Styles in
navigator bar, File > Reload, go back to Navigator: side bar is narrower
than before.

Writer

>From release 7.5.4.2 (regression)

Choose Tools > Language > For all text > Italian

The program freezes. Not all files, example file for check is available

Writer

Feature request

Create a package with document and all linked and embedded images

Similar extension exists by Kai Struck but doesn't do this

Writer

>From release 7.5.4.2 (regression?)

Image properties window

Image link is in the Rotation tab

Draw

>From release 7.1 (regression)

Straight line, curves and polygons, other shapes: Line style set to other
than Continuous

Exporting to svg the line returns continuous

Calc

Feature request

Export to pdf

Export should be possible according to print area





>
> Thanks a lot for your help.
>
>
> --
>
> ___
> Davide Piva
>
>
> --
> Questa email è stata esaminata alla ricerca di virus dal software
> antivirus Avast.
> www.avast.com

Re: Request of information

[Németh László]

Hello Davide,

Davide Piva  ezt írta (időpont: 2023. aug. 8., K,
16:23):

> Hello László.
>
> I really don't understand how to create a metabug, for example for
> Technical writers. I visited
> https://bugs.documentfoundation.org/show_bug.cgi?id=129434
>
I don't know how to add your mail address when submitting a bug. Anyway I
> submitted a request:
>
> https://bugs.documentfoundation.org/show_bug.cgi?id=156515.
>
> Unfortunately it has no solution so far.
>

First of all, many thanks for your bug report!

Unfortunately, there are only workarounds here, because this is a UX
problem, as described in
https://bugs.documentfoundation.org/show_bug.cgi?id=156515#c6 by Daveo.

I've listed a few workarounds, yet:

https://bugs.documentfoundation.org/show_bug.cgi?id=156515#c12


> It appears to me too complicated, maybe the interface is difficult to
> navigate and understand.
>
> I can't proceed.
>

I think a metabug is a plain bug, with the [META] label in its title, and
with a few or more bugs in its Depends on: field (created automatically by
adding the number of the metabug to the Blocks: field of the associated
bugs).

If you report or collect a few bugs, I can create a metabug for Technical
writers.

Best regards,
László

P. S. Thanks to your mail and bug report, and QA by Stéphane Guillou, I've
noticed Tomasz Sztejka's great bug report (
https://bugs.documentfoundation.org/show_bug.cgi?id=156492 "Alt+Enter in
last (rightmost merged) cell in a table doesn't add paragraph below the
table"), and I've already fixed it here:

https://gerrit.libreoffice.org/c/core/+/16

(Interestingly, reading the associated code I've noticed that it's not
possible to insert an empty paragraph before an empty 1-cell table with a
single alt-Enter: in this case, inserting an empty paragraph after the
table is the preferred operation).


> Il 19/07/2023 13:20, Németh László ha scritto:
>
> Hi Davide,
>
> Davide Piva  ezt írta (időpont: 2023. júl. 19.,
> Sze, 11:45):
>
>> Hi all.
>> I have a number of issues concerning LibreOffice Writer, I would like
>> to inform.. Particularly, problems arised along the 7.. release. May I
>> submit it to this list?
>>
> I'm a regular user of the package since its birth. I'm a technical
>> writer and I can do with Writer, quickly and better, the same work
>> others do with InDesign or other costly and complicated software.
>> This is the reason why I wish to contribute to some improvementes, if
>> possible.
>> Thank you.
>>
>
> Please add my e-mail address to the reported bugs in the bug tracker. I am
> very interested in using Writer professionally, so I appreciate your
> feedback in advance. If the problems are reproducible regressions,
> especially loss of functionality or crashes, we will give high priority to
> resolving them, and I hope to solve some of them.
>
> Best regards,
> László
>
>
>>
>> Davide Piva
>>
> --
>
> ___
> Davide Piva
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  Privo
> di virus.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> <#m_-3579746281956997662_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Request of information

[Németh László]

Hi Davide,

Also a useful option is to add the most relevant bugs to the metabug
“Authors” (, by adding the bug number 129434 to the Blocks input box of
your selected or newly reported bugs (content of Blocks is a comma
separated list of the number of the metabugs). Also I suggest adding
yourself to the CC List of the bugs, so you will be informed about the
status of the bug reports.

More information:

https://bugs.documentfoundation.org/show_bug.cgi?id=129434 – (Authors) - [META]
Writer (EDITING) Suggested bug fixes, enhancements and features for authors.

Best regards,
László


Stéphane Guillou  ezt írta (időpont:
2023. júl. 19., Sze, 13:39):

> Davide replied directly to me without copying the list in:
>
> On 19/07/2023 12:59, Davide Piva wrote:
>
> Thank you Stephane.
> So far, I'm using 7.5, after bad experiences with other 7.. and 6.. releases.
> To me, the most usable and stable release remains 5.4.
> Time by time things have gone worst and things should be fixed, to
> avoid accumulate bad funcioning along the time.
> I surely evaluated the possibility to use bugzilla, but I see there
> are hundreds of issues more ore less important. I can't say anyway
> about the priprity of these.
> Thank you anyway.
>
> Davide Piva
>
>
> Davide, when things get worse, what is very helpful is to mark the bug
> report as a "regression", with information about which version worked well
> and the first version that had the bug. This allows us to later pinpoint
> exactly what caused the issue, and makes it way more likely to get if fixed.
> We are more than happy to also get you trained in "bibisecting" issues so
> you can go the next step and identify the commit that introduced the issue
> yourself.
>
> Your help in Quality Assurance would be greatly appreciated!
>
> Cheers
>
> On 19/07/2023 13:20, Németh László wrote:
>
> Hi Davide,
>
> Davide Piva  ezt írta (időpont: 2023. júl. 19.,
> Sze, 11:45):
>
>> Hi all.
>> I have a number of issues concerning LibreOffice Writer, I would like
>> to inform.. Particularly, problems arised along the 7.. release. May I
>> submit it to this list?
>>
> I'm a regular user of the package since its birth. I'm a technical
>> writer and I can do with Writer, quickly and better, the same work
>> others do with InDesign or other costly and complicated software.
>> This is the reason why I wish to contribute to some improvementes, if
>> possible.
>> Thank you.
>>
>
> Please add my e-mail address to the reported bugs in the bug tracker. I am
> very interested in using Writer professionally, so I appreciate your
> feedback in advance. If the problems are reproducible regressions,
> especially loss of functionality or crashes, we will give high priority to
> resolving them, and I hope to solve some of them.
>
> Best regards,
> László
>
>
>>
>> Davide Piva
>>
>
> --
> Stéphane Guillou
> Quality Assurance Analyst | The Document Foundation
>
> Email: stephane.guil...@libreoffice.org
> Mobile (France): +33 7 79 67 18 72
> Matrix: @stragu:matrix.org
> Fediverse: @str...@mastodon.indie.host
> Web: https://stragu.gitlab.io/
>
>

Re: Request of information

[Németh László]

Hi Davide,

Davide Piva  ezt írta (időpont: 2023. júl. 19., Sze,
11:45):

> Hi all.
> I have a number of issues concerning LibreOffice Writer, I would like
> to inform.. Particularly, problems arised along the 7.. release. May I
> submit it to this list?
>
I'm a regular user of the package since its birth. I'm a technical
> writer and I can do with Writer, quickly and better, the same work
> others do with InDesign or other costly and complicated software.
> This is the reason why I wish to contribute to some improvementes, if
> possible.
> Thank you.
>

Please add my e-mail address to the reported bugs in the bug tracker. I am
very interested in using Writer professionally, so I appreciate your
feedback in advance. If the problems are reproducible regressions,
especially loss of functionality or crashes, we will give high priority to
resolving them, and I hope to solve some of them.

Best regards,
László


>
> Davide Piva
>

Re: thesaurus.dic Workday 1

[Németh László]

Hi,

Andras Timar  ezt írta (időpont: 2023. jún. 28., Sze,
17:55):

> Hi Alex,
>
> On Wed, Jun 28, 2023 at 5:15 PM Alex  wrote:
>
>> Hi everyone
>>
>> Today I try to determine how to remove two unwanted wordbook files from
>> libreoffice/extras/source/wordbook:
>> hu_AkH11.dic and sl.dic.
>> These foreign language (incomplete) dics should be removed, unless they
>> are used in some unit test.
>> Bug 139961, 68576 etc
>>
>> Can be removed? OK?
>>
>>
>
> I'm not sure, if it's OK. We added these dictionaries for a reason. It's
> better to ask the maintainers first (I CC-ed them).
> From the technical point of view, if you remove the files from source, and
> all references to them, the build should pass. Maybe you need a clean build
> from scratch. Use "git grep sl.dic" and "git grep hu_AkH11.dic" commands,
> they are more reliable than opengrok.
>

You can remove hu_AkH11.dic with the following git command:

$ git revert 6247c966942a0e43320a234302a67c1f92c2eea7

 Because this was added with that commit:

$ git log libreoffice/extras/source/wordbook/hu_AkH11.dic
commit 6247c966942a0e43320a234302a67c1f92c2eea7

But these are not unwanted dictionaries, as András wrote.

In theory, they are packaged only with their language builds, sl-SI and
hu-HU. If not, i.e. en_US or other language builds get these files
unnecessarily, the only task is fixing our packaging. If the packaging
problem is related to some Linux distributions, I believe, our task is only
to report that in their bug trackers.

Is this a GSoC project? I haven't found information about the planned
improvement of the (en_US?) thesaurus or the thesaurus code base.
(By the way, I had an interesting improvement here: English stemming and
affixation during thesaurus usage by adding extra language data to the
en_US spelling dictionary. Unfortunately, by accident this was removed by
the recent maintainer.)

Best regards,
László



>
> Best regards,
> Andras
>
>
>

Re: Moving to LibreOffice 8?

[Németh László]

Hi Italo and All,

Regina Henschel  ezt írta (időpont: 2023. márc.
28., K, 15:40):

> Hi Italo,
>
> the change from 6.x to 7.0 happens together with the change from ODF 1.2
> to ODF 1.3. If the decision it to keep this kind of numbering, I think a
> change to 8.0 should happen when LibreOffice starts support for ODF 1.4.
> ODF 1.4 will hopefully be released end of 2024.
>

After the previous end of lives 4.4, 5.4 and 6.4, moving to 8.0 is more
traditional, than using 7.6, and I agree with Italo, version 8.0 has
greater marketing value, and likely this was the reason to avoid of version
3.7, 4.5, 5.5 and 6.5. (LibreOffice 3.6 was a different case, because that
numbering was inherited from OpenOffice.org, and LibreOffice started with
version 3.3.)

The next release has already got major improvements. My favorites (
https://wiki.documentfoundation.org/ReleaseNotes/7.6):

– Start of multi-page floating tables in Writer blog post
 (Miklos Vajna, Collabora)
– Citation handling: added plumbing in Writer to build Zotero-like
functionality blog post 
(Miklos Vajna, Collabora)
– Added support for OOXML files created in zip64 format tdf#82984
, tdf#94915
 (Attila Szűcs,
Collabora)
– Export to PDF v.1.7 by default. commit

(Michael Stahl, allotropia)
– Tagged PDF

is now produced by default, for improved accessibility. (To further improve
your PDF's accessibility, the PDF/UA

option is available in the export dialog and will trigger the Accessibility
Check

tool). tdf#39667 
(Samuel Mehrbrodt, allotropia)

Related to API changes, 7.6 and 8.0 are the same case.

No problem with year based numbering, but I suggest to use ISO 8601 date
format for the first office suite based on an ISO document format:

LibreOffice 2023-08

or

LibreOffice -23-08.

And what about LibreOffice 365? We can follow that with 366, 367, or
similar to Donald Knuth's numbering scheme for TeX, with approximation,
here to the anomalistic year length in days: 365, 365.2, 365.25, 365.259,
365.2596, 365.25963, 365.259636 etc. [
https://www.washingtonpost.com/news/speaking-of-science/wp/2017/02/24/think-you-know-how-many-days-are-in-a-year-think-again/
]

I think, there is no bad decision, so we can choose the best for marketing,
e.g. 8.0, and that was the essence of Italo's proposal, many thanks for it!
I like also the idea of infinity, and I wish LibreOffice another 38
successful years, which number also contains digit 8 –, also the birth of
our code base: 1985 (StarOffice).

Best regards,
László


> Kind regards,
> Regina
>
> Italo Vignoli schrieb am 27.03.2023 um 19:11:
> > Moving to LibreOffice 8 (instead of 7.6) makes sense for marketing
> > purposes, as media is looking at LibreOffice as the real innovator in
> > the open source office suite market, and the feeling of journalists is
> > that we are forever stuck at 7.x.
> >
> > We all know that the next version will not include any significant
> > innovation which can justify the change of version, apart from the new
> > build system for Windows and the availability of LibreOffice for Arm
> > processors on Windows (which has not been announced).
> >
> > Playing with the number 8, which can be rotated 90° to become the
> > "infinite" symbol, we can frame the next version as LibreOffice for an
> > infinite number of users, as we cover all hardware platforms and all
> > operating systems for personal productivity.
> >
> > This is my opinion. If the community wants to stick with 7.6, I won't
> > insist. I have received enough insults both public and private for the
> > marketing plan, and I am still receiving them from a few people, that I
> > am not willing to enter into that process again (even if the decision on
> > the "community" tag has not been mine, but it looks like people have a
> > very short memory).
> >
> > Looking forward to your thoughts.
>
>

Fixed upload to Vibe WebDav server (Re: Curl build issue causing problematic file size growth fixed)

[Németh László]

Hi Ilmari, Hi All,

Thanks for the good news!

Other good news related to the Curl based WebDav: fixed upload to Micro
Focus (before 2022: Novell) Vibe WebDav server, which was the most urgent
problem for NISZ, and likely for others migrating to LibreOffice 7.4 and
newer versions:

tdf#152493 
ucb WebDAV: fix upload using HTTP 1.0 fallback

https://git.libreoffice.org/core/+/30ca48f4dc0e65a3798e6b21574bc80f6d4953fa%5E%21

tdf#153642 
ucb: fix broken save with cached DAVOptions:
https://git.libreoffice.org/core/+/d6182cb6704c06f33d284874b9fe96c85cce5bf5%5E%21

Thanks to Michael Stahl (allotropia), Pál Kochis, Attila Bakos, Péter Nagy
(NISZ) and their colleagues for helping me to solve the issue before the
deadline.

Best regards,
László


Ilmari Lauhakangas  ezt írta (időpont:
2023. márc. 7., K, 18:03):

> Last year a new developer faced a nasty build issue with a Curl makefile
> growing to fill all the available disk space. After reporting it to
> Curl, I learned it was known since at least 2021 and it was suspected to
> be an automake regression.
>
> In the end, it turned out that we had barked up the wrong tree and
> automake contributor Jan Engelhardt was kind enough to provide a fix in
> Curl:
>
>
> https://github.com/curl/curl/commit/73e9e6d767296c5759972d07f2441c8993ccbb9d
>
> There will be no new point releases of Curl 7, so the fix will be
> shipped in version 8.
>
> Ilmari
>

Re: Request for [API CHANGE] in spell checking: add new options to disable rule-based compounding

[Németh László]

Hi Stephan,

Stephan Bergmann  ezt írta (időpont: 2023. febr. 2.,
Cs, 21:17):

> On 1/6/23 17:42, Németh László wrote:
> > Stephan Bergmann mailto:sberg...@redhat.com>> ezt
> > írta (időpont: 2023. jan. 5., Cs, 10:32):
> > Thus I would suggest to:
> >
> > * Revert the addition of the two new attributes, instead adding
> > documentation to offapi/com/sun/star/linguistic2/XLinguProperties.idl
> > that those two properties are available through the XPropertySet
> > interface since LibreOffice 7.6.
>
> the above is done in
> <
> https://git.libreoffice.org/core/+/537a8de72b935a406e6154a8cc55040ed521741e%5E%21>
>
> "Remove redundant attributes that were added to published
> XLinguProperties", while the below is still up for grab:
>
> > * Optionally, also mark all the other attributes of XLinguProperties
> as
> > deprecated, stating in the documentation that they should instead be
> > accessed via the XPropertySet interface.
>
>
Sorry for my delay. Many thanks for your help!

Best regards,
László

Re: Request for [API CHANGE] in spell checking: add new options to disable rule-based compounding

[Németh László]

Hi Stephan, Hi All,

Stephan Bergmann  ezt írta (időpont: 2023. jan. 5.,
Cs, 10:32):

> On 04/01/2023 14:18, Németh László wrote:
> > I've started to add two new spell checking options to
> > css.linguistic2.XLinguProperties
> [...]
> > Commit:
> https://git.libreoffice.org/core/+/57d79744c77eef96b4c2bd3b16e0a04317ffcf9e%5E%21
> <
> https://git.libreoffice.org/core/+/57d79744c77eef96b4c2bd3b16e0a04317ffcf9e%5E%21
> >
>
> So this is about the addition of
>
> > /** defines whether spell checking should be accept rule-based
> >  closed compounding of dictionary words.
> >
> > @since LibreOffice 7.6
> > */
> > [attribute] boolean IsSpellClosedCompound;
> >
> > /** defines whether spell checking should be accept rule-based
> >  hyphenated compounding of dictionary words.
> >
> > @since LibreOffice 7.6
> > */
> > [attribute] boolean IsSpellHyphenatedCompound;
>
> to the published interface css.linguistic2.XLinguProperties in
> <
> https://git.libreoffice.org/core/+/57d79744c77eef96b4c2bd3b16e0a04317ffcf9e%5E%21>
>
> "tdf#136306 offapi linguistic: add options to disable rule-based
> compounding", which is an ABI-breaking change.
>
> But looking closer, when
> <
> https://git.libreoffice.org/core/+/ef0af5032ad283ffb3b4521eb097a118d58f332a%5E!/>
>
> "fdo#46808, Convert linguistic2::LingProperties to new style" introduced
> that css.linguistic2.XLinguProperties interface, it gave it various
> interface attributes (IsUseDictionaryList, IsIgnoreControlCharacters,
> IsSpellUpperCase, etc.) for no compelling reason:  XLinguProperties is
> meant to be the implementation interface of the service LinguProperties,
> which was changed by that commit from an old-style to a new-style
> service.  The original old-style service implemented XPropertySet and
> listed a number of supported properties.  The XLinguProperties interface
> also inherits from XPropertySet, and that should arguably have been all
> that is necessary to make LinguProperties a new-style service.  But that
> commit also added (some of) the properties of the old-style
> LinguProperties service as attributes to XLinguProperties, for no
> compelling reason.  All those entities should be available through the
> XPropertySet interface, so there is no need to also have them available
> through attribute getters and setters.
>
> Thus I would suggest to:
>
> * Revert the addition of the two new attributes, instead adding
> documentation to offapi/com/sun/star/linguistic2/XLinguProperties.idl
> that those two properties are available through the XPropertySet
> interface since LibreOffice 7.6.
>
> * Optionally, also mark all the other attributes of XLinguProperties as
> deprecated, stating in the documentation that they should instead be
> accessed via the XPropertySet interface.
>

Ah, OK. So I only missed the proposed API. I'm going to make the proposed
changes.

Many thanks for the detailed description!

Best regards,
László

Request for [API CHANGE] in spell checking: add new options to disable rule-based compounding

[Németh László]

Hi,

I've started to add two new spell checking options to
css.linguistic2.XLinguProperties (screen shot:
https://wiki.documentfoundation.org/images/a/a2/Spelling_options_compound.png),
which can improve spell checking a lot. Because API changes need more
attention, please check the Rationale below, comment on the extension, or
the caption of the check boxes, and the patch itself, especially if
backwards compatibility is accidentally broken (I don't know about it.) It
it's ok for you, my plan is to extend the help (and follow on the other
Hunspell problems, e.g. too redundant suggestions in several cases).

>From the commit description:

“For professional proofreaders, it can be more important to avoid the
mistakes of the rule-based compound word recognition, than
to speed up proofreading. Disabling the following two new options
will report all rule-based closed compound words (default in
Dutch, German, Hungarian etc. dictionaries) and rule-based
hyphenated compound words (all languages with BREAK usage in
their Hunspell dictionaries):

- "Accept possible closed compound words"

- "Accept possible hyphenated compound words"

For example, disabling the second one, dictionary word "scot-free"
will be still correct word in English spell checking, but not
the previously accepted compound "arbitrary-word-with-hyphen".”

Commit:
https://git.libreoffice.org/core/+/57d79744c77eef96b4c2bd3b16e0a04317ffcf9e%5E%21

Rationale:

Spell checker of MS Office and Google Docs started to use the "common
knowledge" by collecting words and user feedback from the internet. It's
cheap and up-to-date, and likely good enough for writing private messages,
but it's not for professional document editing (see for example user
feedback of Word „new version of the spell checker is awful”:
https://answers.microsoft.com/en-us/msoffice/forum/all/spell-check-problems/10078dbf-855a-4154-afb4-fac5e5c24ad8).
Several languages, like Dutch, French, German, Hungarian use an academic
approach, i.e. an orthography standardized by the government/national
bodies, see for example the official status of Duden in Germany. A spell
checker, which accepts spelling mistakes, because they are frequently used
by the users, is the opposite of a spell checker, at least in a document
editor. Thanks to the lazy approach of the other document editors, spell
checker of Writer can be more attractive for the professionals than before.
Hunspell and Hunspell dictionaries are not perfect either. An old request
from the editors to disable the rule-based compound words optionally,
because while rule-based approach eliminated the false alarms successfully
(note: German-like orthography generated millions of “single-use” correct
word forms, which not possible to list in a spelling dictionary), it
resulted in the malfunction of spell checking: typos and missing spaces
between words skipped by the spell checker frequently. Hunspell had got a
successful solution to limit this in the most important cases: if the
possible rule-based compound word is also a dictionary word with a serious
spelling mistake, the word form was reported as a spelling mistakes (see
REP and CHECKCOMPOUNDREP in
https://github.com/hunspell/hunspell/blob/master/man/hunspell.5). The new
Hunspell 1.7.2 added a similar feature to the rule-based compound words
composed from 3 or more words (
https://github.com/hunspell/hunspell/commit/ff3591b0f76950f13d73123d03a03edd9a892945).
But this is not enough: other typos are still recognized as compound words
by the rule-based compounding. The new options are not exactly new in the
case of  Hungarian: Lightproof spell checker has already contained the
options “Underline all typo-like compound words” and “Underline all
generated compound words”. This feature is important enough to be available
for all languages with the same potential problem. If the editor wants more
realistic, i.e. strict dictionary-based spell checking, disables these new
options, and with some effort, can fix the typos and the missing spaces
without reading 300 pages of a book (or otherwise, too: reading the book
does not guarantee that you will be able to spot typos).

Best regards,
László

Re: undeclared build-time dependency on libnumbertext 1.0.6

[Németh László]

Hi Rene,

Rene Engelhard  ezt írta (időpont: 2020. aug. 7., P,
17:31):

> Hi,
>
> my LO 7.0.0 build on Debian buster failed:
>
> [...]
> Test name: SwUiWriterTest::testTdf133589
> equality assertion failed
> - Expected: ೥ೋ೓೉೗
> - Actual  : székely 0
>
> Failures !!!
> Run: 305   Failure total: 1   Failures: 1   Errors: 0
>
> This looks like libnumbertext needs to be 1.0.6 which does have this new
> "old hungarian" feature... (yes, "of course" --with-system-libnumbertext
> and libnumbertext in Debian buster is 1.0.5).
>

Ah, indeed. I didn't think of this option...


>
> $ git diff
> diff --git a/configure.ac b/configure.ac
> index 59ec7ec58bf1..d5782d32be4b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -10509,7 +10509,7 @@ AC_SUBST(SYSTEM_LIBEXTTEXTCAT_DATA)
>  dnl ===
>  dnl Checking for libnumbertext
>  dnl ===
> -libo_CHECK_SYSTEM_MODULE([libnumbertext],[LIBNUMBERTEXT],[libnumbertext
> >= 1.0.0])
> +libo_CHECK_SYSTEM_MODULE([libnumbertext],[LIBNUMBERTEXT],[libnumbertext
> >= 1.0.6])
>  if test "$with_system_libnumbertext" = "yes"; then
>  SYSTEM_LIBNUMBERTEXT_DATA=file://`$PKG_CONFIG --variable=pkgdatadir
> libnumbertext`
>  SYSTEM_LIBNUMBERTEXT=YES
>
> The other alternative is to do it like the DLP libraries and only do the
> test needing it if libnumbertext is 1.0.6 and thus support "old
> hungarian"...
>
> Which one would you prefer? The first one of course is trivial :-)
>

I prefer the trivial one, if it's not a problem for you. I gave a +2 for
it, thanks! :)

A question related to this issue: I started to add Old Hungarian numbering
to Writer
(https://gerrit.libreoffice.org/c/core/+/99950) and the UI will contain Old
Hungarian
numbers, see the attached screenshot, so I plan to update the
noto-fonts-20171024.tar.gz
tarball, adding also the fortunately small (45 kB)
NotoSansOldHungarian-Regular.otf to help to
fix the potential font issue [note: the screenshot contains another
problem: showing squares
at the place of 1-character non-Unicode BMP text spans].

There is a bug report for Linux Mint (
https://github.com/linuxmint/cinnamon/issues/9458),
also an older one for Debian (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908817).
I am going to file a bug for my LibreOffice patch related to the numbering,
maybe for
Noto font update in LibreOffice. Do you suggest something similar for
Debian (Ubuntu) etc.,
or it is not necessary?

Thanks,
László




>
> Regards,
>
> Rene
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: undeclared build-time dependency on libnumbertext 1.0.6

[Németh László]

Hi,

Rene Engelhard  ezt írta (időpont: 2020. aug. 7., P,
18:35):

> Hi,
>
> Am 07.08.20 um 18:29 schrieb Rene Engelhard:
> >
> > At least a quick look
> > (
> https://packages.debian.org/search?searchon=contents=NotoSansOldHungarian-Regular.otf=exactfilename=unstable=any
> )
> > suggests that this is not the case.
>
> Ah, nevermind, there's a .ttf:
>
>
> https://packages.debian.org/search?suite=sid=any=filename=contents=OldHungarian


Great! This font solves the UI issue, and it can be good also for text
editing with some refinement (forbidding unnecessary automatic ligature
replacements).

Thanks,
László


>
>
> Regards,
>
>
> Rene
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: CppunitTest_sw_layoutwriter failing on Windows with HiDPI

[Németh László]

Hi Luke,

Luke Benes  ezt írta (időpont: 2019. szept. 17., K,
3:44):

> Sorry. I copy/pasted the wrong commit id. The build started failing after
> the Unit Test added in
>
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=55136439e71b7adc62a46a3d3dc8de26d54d989d
>
> tdf127448 Chart: Avoid distortion of charts with multilevel axis labels
>
> Should the assert be relaxed a bit?
>

Yes, Balazs' patch is there in the gerrit:
https://gerrit.libreoffice.org/#/c/79046/

Thanks for your bug report,
Laszlo


>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Review for "improve import/export of line styles"

[Németh László]

Németh László  ezt írta (időpont: 2019. szept. 2.,
H, 8:19):

> Hi Regina,
>
> Regina Henschel  ezt írta (időpont: 2019. szept.
> 1., V, 19:44):
>
>> Hi all,
>>
>> please have a look at https://gerrit.libreoffice.org/#/c/78372/
>>
>> An important question is whether you agree that I have changed the
>> import and export of our own line styles so that no prstDash line styles
>> are used for them. Instead I export them as custDash elements and
>> reconstruct them in the import.
>>
>
> The original idea with binding preset styles of LO and MSO was to support
> some kind of interoperability: using the same or similar UI to check and
> modify the line styles.
> I can imagine easily, that StarOffice/OpenOffice.org copied the preset
> styles of the old MSO originally. So maybe modifying/extending the preset
> styles of LibreOffice would be the final step to create a better
> interoperability again, and your nice improvement is the first step in this
> direction.
>
>
>>
>> I have not added tests yet. Please tell me, what you think would be good
>> to test.
>>
>
> I believe, testing import/export of preset styles of LO and MSO are the
> most important,
> but only unit testing can guarantee keeping the improvements, so maybe
> it's worth to extend the list.
>
>
>>
>> You know I always have a hard time with C++. So I welcome hints on how
>> to implement something better.
>>
>> And technical question: What do I need to do locally in Git, so that the
>> information, that the no longer needed file "lo_preset_dashes.odt" has
>> to be deleted, is included in my commit?
>>
>
> If you deleted the file accidentally,
>
> git checkout sw/qa/extras/ooxmlexport/data/lo_preset_dashes.odt
>
> and
>
> git rm sw/qa/extras/ooxmlexport/data/lo_preset_dashes.odt
>
> and add deletion to the actual commit:
>
> git commit --amend
>
> Best regards,
> László
>
>
>
>>
>> Kind regards
>> Regina
>> ___
>> LibreOffice mailing list
>> LibreOffice@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About the kikongo speller (kituba)

[Németh László]

Hi,

2017-12-19 12:37 GMT+01:00 Eike Rathke :

> Hi Cyrille,
>
> On Tuesday, 2017-12-12 14:43:05 +0100, Cyrille wrote:
>
> > I come back to you because I think the dictionary is now mature. I would
> > like to know if it is possible to propose it to the github hunspell repo
> >  or
> > better as a new package for Debian/Ubuntu.
>
> It looks like that github page lists dictionaries that are available as
> Debian and Ubuntu packages, so probably trying to add it as a Debian
> package would be best.
>
> > Currently I did already a
> > plugin for firefox and an extension for Libreoffice (even if it is not
> > necessary on Ubuntu if you have the hunspell installed). I did it first
> > for Windows. But I would like to know if it is possible to install it
> > for all applications on Windows too (But maybe I'm not in the right
> > place to ask my question?).
>
> I don't know details, but I think Windows doesn't have a concept of
> central dictionaries.
>

I'm afraid of it, too. (It seems, Microsoft has opened his spell checking
API:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh869853(v=vs.85).aspx,
so maybe it's possible to use it for spell checker developments. If I right
remember, some years ago this API documentation was a product sold by MS).
Mozilla Firefox and Google Chrome use dictionary extensions created by the
users on their add-on sites, so you can add also Kikongo dictionary to them.

If I right think, as an extension to the (future?) Kikongo LibreOffice
localization, you can add your dictionary to the dictionaries/ LibreOffice
repository. This way, Kikongo localization packages of LibreOffice will
contain the spelling and hyphenation dictionaries, too.

Best regards,
László




>
> Maybe best ask László Németh who might know, also other details, see
> https://hunspell.github.io/
>
>   Eike
>
> --
> LibreOffice Calc developer. Number formatter stricken i18n
> transpositionizer.
> GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563
> 2D3A
> Care about Free Software, support the FSFE https://fsfe.org/support/?erack
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Copyright infringement and future of Hunspell

[Németh László]

Hi,

2017-11-17 19:44 GMT+01:00 Димитриј Мијоски :
> Reverted.
> https://github.com/hunspell/hunspell/commit/58dfe79637982c5c49658c57c3b01d
4f44c07c19
> I guess everybody should be happy now. Life goes on. I won't touch
> version 1 code any more.

Thanks for reverting.

2017-11-18 1:00 GMT+01:00 Димитриј Мијоски :

>
> @ everyone in this thread
>
> Ok, can we conclude now. V1 is tri-license back as it was, V2 will be
> LGPLv3 only, for the time being. I did the change because I wanted to
> link V2 into V1, to have full backward compatibility. But, I gave it an
> additional though and there is a simple solution to link V1 into V2 and
> keep the whole package backward compatible (including ABI).
>
> Once V2 is finished, if you like it, put it in LibreOffice. If you don't
> like it, don't do it. We are really trying hard to make a good product.
>

This is not an option, because Hunspell development is part of LibreOffice.
Authors and main contributors are all LibreOffice (OpenOffice.org)
developers.
Caolán and me used GitHub only as a git repository for Hunspell, fixing
Hunspell problems mostly reported by LibreOffice users.
Driving force and main target of Hunspell development is still LibreOffice.


> I apologize for any inconveniences I created.
>

Thanks.

To solve this unfortunate situation, please, separate your "hunspell2"
project
under a different gitHub project and name, without using "Hunspell" or
"Hunspell v2" titles for it.

This will help me a lot to continue Hunspell developments for LibreOffice
in the next few weeks and later.

Best regards,
Laszlo


> Cheers,
> Dimitrij.
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Copyright infringement and future of Hunspell

[Németh László]

Hi,

A week ago you modified Hunspell’s license in the official Hunspell
repository
without permission of the author, me, and the main contributor and
maintainer,
Caolán McNamara.

==
commit d49170ce949dbe0d2e6ad74b6b876e5580704a5e
Author: Dimitrij Mijoski 
Date:   Wed Nov 8 18:30:29 2017 +0100

License everything under LGPLv3+. No more three licenses mumbo jumbo.

commit 6ff9a6fb5a63ee63294131eba7ce4e67624dffa5
Author: PanderMusubi 
Date:   Wed Nov 8 16:45:35 2017 +0100

improved copyright and authors
==

Free licenses and rich functionality helped Hunspell equally to
spread better multilingual spell checking among desktop and web
applications, so I don’t plan to replace the recent MPL/LGPL/GPL
tri-license with LGPL 3.

Moreover, it’s misleading to refer yourselves as the authors of Hunspell
(see your change in Hunspell’s AUTHORS file), when you are contributors
of the project.

If I right think, these modifications are related to your Mozilla funded
Hunspell
development, in which, unfortunately, I wasn’t able to take part in it,
and I didn’t follow  your Mozilla application last year. I read about its
success(?)
and your plan to create a spell checker from scratch only a few weeks ago.
(You have informed Caolán and me only about the first steps of the
application,
if I right know.)

>From its name and place in Hunspell repository, “Hunspell 2” is a
future replacement or successor of Hunspell library and command-line
executable, but it seems, it’s more like a fork of Hunspell development
efforts. According to your plan: “That aim for Hunspell 2.0 is to
recreate the most common functionality in Hunspell 1, and that is
detection and correction of spelling errors.”

Reimplementing a subset of the features and dropping dictionary formats
can result worse spell checking and dictionary incompatibilities between
applications (as I see in the case of Hungarian dictionary in your
project).

“Hunspell 2” won’t contain functions used by LibreOffice, main
target of Hunspell development. For example, every thesaurus uses Hunspell
for stemming, some of them also for morphological generation.

You promise the same spelling as in Hunspell, but you’ve already removed
all unit tests of Hunspell library to the dictionary “v1cmdline”.

Spell checking of LaTeX, HTML/XML and OpenDocument files will be also
“dropped” in your development, but this is a basic function of the
targeted academic publishing and automatized command-line document editing.

As the author of the half of Hunspell’s code base (the second half is
the work of Kevin Hendricks, author of MySpell), I don’t believe your
incomplete rewriting from scratch is a viable option with your limited
resources and experience (one C++ developer, insufficient knowledge
of the aim, usage and implementation of Hunspell features and
dictionaries).

[For example, you wrote the following about the LANG option of Hunspell
affix file in your analysis: “In the source code is no implementation
existing. Deprecate this option?”, while this option is really used
several places in language-specific parts of Hunspell. I have just added
support for special casing of Crimean Tatar language (extending the
Turkish and Azeri support – those were mentioned in Hunspell(5) manual
page), also adapted orthography changes in the special LANG_hu part of the
general compounding functions.]

See why trying to rewrite from scratch is a huge risk:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i

Please, consider Caolán’s more than 700 Hunspell commits: excellent
and unique code-cleaning based on Red Hat, LibreOffice and Coverity bug
reports and – partly covering your aims – massive C++11 porting in
Hunspell library and command-line tool.

I think, the most important thing is to open Hunspell for more languages,
supporting research results of the academic sphere (see
https://pdfs.semanticscholar.org/dad3/5c719bb8bf5dffa8c757166fd1086be4d6c6.pdf
,
http://voikko.puimula.org/architecture.html), improving recent
dictionaries and creating competitive linguistic features, especially for
LibreOffice.

I’m glad of that I can work on the Hungarian Hunspell dictionary these
months supported by FSF.hu Foundation, Hungary, fixing some minor
problems in Hunspell and LibreOffice, too. Moreover, last week I
adapted an interesting Hunspell feature to LibreOffice. I think, this
“Grammar By” improvement of the user dictionaries will be quite useful
for professional Writer users in several languages:
https://wiki.documentfoundation.org/ReleaseNotes/6.0#.E2.80.9CGrammar_By.E2.80.9D_spell_checking
.

I would be glad of fixing the recent regression of the English thesauri
(morphological descriptions were removed by English dictionary update) in
LibreOffice, refining parts in Hunspell related to this and to the
“Grammar By” feature, giving frequency and pronunciation based

Re: Release notes LO 5.0 : nothing about Emoji autocorrection

[Németh László]

Hi,

I will extend the release notes soon about both new improvements here, the
default Emoji, Greek alphabet etc. short name replacements (
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-0id=483390d66b1e1bd899410906f53f3124cacfe73d),
and the new AutoCorrect method for immediately replacements inside words
(this one is useful to define own in-word patterns for linguistics,
mathematics, typography etc. (
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-0id=15c04e1f567e50aff850a65996c65e6465497710
).

Many thanks for your mail and your positive feedback, also thanks in
advance to the translators.
I will try to give some nice examples about the usage of this new feature,
too.

Best regards,
Laszlo


2015-06-30 9:12 GMT+02:00 Jean-Baptiste Faure jbfa...@libreoffice.org:

 Hi,

 If I read correctly, there is nothing in the current version of the
 release notes for LO 5.0 [1] about Emoji autocorrection.

 I think that the developer who did the job should write few lines about
 it. Even if Emoji autocorrection gives us additional translation work, I
 think it is a useful work that should be made more visible.

 [1] https://wiki.documentfoundation.org/ReleaseNotes/5.0

 Best regards.
 JBF
 --
 Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
 Disclaimer: my Internet Provider being located in France, each of our
 exchanges over Internet will be scanned by French spying services.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Writer problem with a dangling SwModify pointer

[Németh László]

Hi Stephan,

I have checked Tamás and my changes, and both of them work well with
your fix. Many thanks for it and for the detailed commit message!

Best regards,
László


2015-06-09 11:27 GMT+02:00 Stephan Bergmann sberg...@redhat.com:
 On 06/01/2015 07:26 PM, Németh László wrote:

 _ImplAdjustVertRelPos( ) function was for only limiting a numerical
 value (vertical position of text frames) without any modification of
 its arguments, but I extended it with a direct modification of a frame
 attribute using this SetFlyFrmAttr call. I am afraid, this was a bad
 idea, when _ImplAdjustVertRelPos() is called during a similar
 modification of an attribute set. Perhaps moving the
 SetFlyFrmAttr/modification to the calling code part will solve this
 problem, I will check it. Thanks for your mail!


 I have now come up with a solution for this that at least makes ASan+UBSan
 make check happy,
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=0eb52534de536fbe33585c91f4f173653b184e24
 Unlock SwCacheObj before potentially deleting it from SwCache.

 László, Tamás, please verify that this does not negatively impact your
 changes
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4dee94afed9ade6ac50237c8d99a6e49d3bebc1
 tdf#91260: allow textboxes extending beyond the page bottom etc. and
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=cb19042f4395c97d123a27c6960d5e30d666c010
 New feature: vertical alignment for text frames: Layout part.

 And I would not mind any Writer expert looking at that The hope is...
 part, either.


 2015-06-01 17:39 GMT+02:00 Stephan Bergmann sberg...@redhat.com:

 I'm chasing a problem that my UBSan build originally pointed me at, but
 where I fail to make good progress.  Maybe some Writer expert has a clue.

 I have broken it down to two pieces of information:

 For one, valgrind reports a dangling SwModify pointer toward the end of
 CppunitTest_sw_ooxmlexport,

 Invalid read of size 1
 at 0x20FD6659: SwModify::SetInCache(bool) (in
 /home/sbergman/lo/core/instdir/program/libswlo.so)
 by 0x215FECD7: SwBorderAttrs::~SwBorderAttrs()
 (/sw/source/core/layout/frmtool.cxx:1872)
 by 0x215FED48: SwBorderAttrs::~SwBorderAttrs()
 (/sw/source/core/layout/frmtool.cxx:1871)
 by 0x20FFE78B: SwCache::~SwCache()
 (/sw/source/core/bastyp/swcache.cxx:123)
 by 0x21640B21: _FrmFinit() (/sw/source/core/layout/newfrm.cxx:369)
 by 0x20FF86CF: _FinitCore() (/sw/source/core/bastyp/init.cxx:750)
 by 0x21EDEBC8: SwDLL::~SwDLL() (/sw/source/uibase/app/swdll.cxx:158)
 by 0x21EE045A: std::default_deleteSwDLL::operator()(SwDLL*) const

 (/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/bits/unique_ptr.h:76)
 by 0x21EE0598: std::unique_ptrSwDLL, std::default_deleteSwDLL

 ::reset(SwDLL*)


 (/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/bits/unique_ptr.h:344)
 by 0x21EDF5EB:
 comphelper::unique_disposing_ptrSwDLL::reset(SwDLL*)
 (/include/comphelper/unique_disposing_ptr.hxx:41)
 by 0x21EDF02D:
 comphelper::unique_disposing_solar_mutex_reset_ptrSwDLL::reset(SwDLL*)
 (/include/comphelper/unique_disposing_ptr.hxx:152)
 by 0x21EDFFA1:

 comphelper::unique_disposing_ptrSwDLL::TerminateListener::disposing(com::sun::star::lang::EventObject
 const) (/include/comphelper/unique_disposing_ptr.hxx:118)
 by 0x21EE01BB: non-virtual thunk to

 comphelper::unique_disposing_ptrSwDLL::TerminateListener::disposing(com::sun::star::lang::EventObject
 const) (/include/comphelper/unique_disposing_ptr.hxx:102)
 by 0xD4A4561:

 cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject
 const) (/cppuhelper/source/interfacecontainer.cxx:312)
 by 0xD4A54C3:

 cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject
 const) (/cppuhelper/source/interfacecontainer.cxx:485)
 by 0x2BB8A540: framework::Desktop::disposing()
 (/framework/source/services/desktop.cxx:1051)
 by 0xD49EB2E: cppu::WeakComponentImplHelperBase::dispose()
 (/cppuhelper/source/implbase.cxx:109)
 by 0x2BB8E710:
 cppu::WeakComponentImplHelper6com::sun::star::lang::XServiceInfo,
 com::sun::star::frame::XDesktop2, com::sun::star::frame::XTasksSupplier,
 com::sun::star::frame::XDispatchResultListener,
 com::sun::star::task::XInteractionHandler,
 com::sun::star::frame::XUntitledNumbers::dispose() (in
 /home/sbergman/lo/core/instdir/program/libfwklo.so)
 by 0x2BB8E988: non-virtual thunk to
 cppu::WeakComponentImplHelper6com::sun::star::lang::XServiceInfo,
 com::sun::star::frame::XDesktop2, com::sun::star::frame::XTasksSupplier,
 com::sun::star::frame::XDispatchResultListener,
 com::sun::star::task::XInteractionHandler,
 com::sun::star::frame::XUntitledNumbers::dispose()
 (/include/cppuhelper/compbase6.hxx:59)
 by 0xD4F3BAD: cppuhelper::ServiceManager::disposing()
 (/cppuhelper/source/servicemanager.cxx:925)
 by 0xD49EB2E: cppu::WeakComponentImplHelperBase::dispose()
 (/cppuhelper

Re: Writer problem with a dangling SwModify pointer

[Németh László]

Hi Stephan,

_ImplAdjustVertRelPos( ) function was for only limiting a numerical
value (vertical position of text frames) without any modification of
its arguments, but I extended it with a direct modification of a frame
attribute using this SetFlyFrmAttr call. I am afraid, this was a bad
idea, when _ImplAdjustVertRelPos() is called during a similar
modification of an attribute set. Perhaps moving the
SetFlyFrmAttr/modification to the calling code part will solve this
problem, I will check it. Thanks for your mail!

Best regards,
Laszlo



2015-06-01 17:39 GMT+02:00 Stephan Bergmann sberg...@redhat.com:
 I'm chasing a problem that my UBSan build originally pointed me at, but
 where I fail to make good progress.  Maybe some Writer expert has a clue.

 I have broken it down to two pieces of information:

 For one, valgrind reports a dangling SwModify pointer toward the end of
 CppunitTest_sw_ooxmlexport,

 Invalid read of size 1
at 0x20FD6659: SwModify::SetInCache(bool) (in
 /home/sbergman/lo/core/instdir/program/libswlo.so)
by 0x215FECD7: SwBorderAttrs::~SwBorderAttrs()
 (/sw/source/core/layout/frmtool.cxx:1872)
by 0x215FED48: SwBorderAttrs::~SwBorderAttrs()
 (/sw/source/core/layout/frmtool.cxx:1871)
by 0x20FFE78B: SwCache::~SwCache()
 (/sw/source/core/bastyp/swcache.cxx:123)
by 0x21640B21: _FrmFinit() (/sw/source/core/layout/newfrm.cxx:369)
by 0x20FF86CF: _FinitCore() (/sw/source/core/bastyp/init.cxx:750)
by 0x21EDEBC8: SwDLL::~SwDLL() (/sw/source/uibase/app/swdll.cxx:158)
by 0x21EE045A: std::default_deleteSwDLL::operator()(SwDLL*) const
 (/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/bits/unique_ptr.h:76)
by 0x21EE0598: std::unique_ptrSwDLL, std::default_deleteSwDLL
 ::reset(SwDLL*)
 (/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/bits/unique_ptr.h:344)
by 0x21EDF5EB: comphelper::unique_disposing_ptrSwDLL::reset(SwDLL*)
 (/include/comphelper/unique_disposing_ptr.hxx:41)
by 0x21EDF02D:
 comphelper::unique_disposing_solar_mutex_reset_ptrSwDLL::reset(SwDLL*)
 (/include/comphelper/unique_disposing_ptr.hxx:152)
by 0x21EDFFA1:
 comphelper::unique_disposing_ptrSwDLL::TerminateListener::disposing(com::sun::star::lang::EventObject
 const) (/include/comphelper/unique_disposing_ptr.hxx:118)
by 0x21EE01BB: non-virtual thunk to
 comphelper::unique_disposing_ptrSwDLL::TerminateListener::disposing(com::sun::star::lang::EventObject
 const) (/include/comphelper/unique_disposing_ptr.hxx:102)
by 0xD4A4561:
 cppu::OInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject
 const) (/cppuhelper/source/interfacecontainer.cxx:312)
by 0xD4A54C3:
 cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear(com::sun::star::lang::EventObject
 const) (/cppuhelper/source/interfacecontainer.cxx:485)
by 0x2BB8A540: framework::Desktop::disposing()
 (/framework/source/services/desktop.cxx:1051)
by 0xD49EB2E: cppu::WeakComponentImplHelperBase::dispose()
 (/cppuhelper/source/implbase.cxx:109)
by 0x2BB8E710:
 cppu::WeakComponentImplHelper6com::sun::star::lang::XServiceInfo,
 com::sun::star::frame::XDesktop2, com::sun::star::frame::XTasksSupplier,
 com::sun::star::frame::XDispatchResultListener,
 com::sun::star::task::XInteractionHandler,
 com::sun::star::frame::XUntitledNumbers::dispose() (in
 /home/sbergman/lo/core/instdir/program/libfwklo.so)
by 0x2BB8E988: non-virtual thunk to
 cppu::WeakComponentImplHelper6com::sun::star::lang::XServiceInfo,
 com::sun::star::frame::XDesktop2, com::sun::star::frame::XTasksSupplier,
 com::sun::star::frame::XDispatchResultListener,
 com::sun::star::task::XInteractionHandler,
 com::sun::star::frame::XUntitledNumbers::dispose()
 (/include/cppuhelper/compbase6.hxx:59)
by 0xD4F3BAD: cppuhelper::ServiceManager::disposing()
 (/cppuhelper/source/servicemanager.cxx:925)
by 0xD49EB2E: cppu::WeakComponentImplHelperBase::dispose()
 (/cppuhelper/source/implbase.cxx:109)
by 0xD484A70:
 cppu::WeakComponentImplHelper8com::sun::star::lang::XServiceInfo,
 com::sun::star::lang::XMultiServiceFactory,
 com::sun::star::lang::XMultiComponentFactory,
 com::sun::star::container::XSet,
 com::sun::star::container::XContentEnumerationAccess,
 com::sun::star::beans::XPropertySet,
 com::sun::star::beans::XPropertySetInfo,
 com::sun::star::lang::XEventListener::dispose() (in
 /home/sbergman/lo/core/instdir/program/libuno_cppuhelpergcc3.so.3)
by 0xD484C78: non-virtual thunk to
 cppu::WeakComponentImplHelper8com::sun::star::lang::XServiceInfo,
 com::sun::star::lang::XMultiServiceFactory,
 com::sun::star::lang::XMultiComponentFactory,
 com::sun::star::container::XSet,
 com::sun::star::container::XContentEnumerationAccess,
 com::sun::star::beans::XPropertySet,
 com::sun::star::beans::XPropertySetInfo,
 com::sun::star::lang::XEventListener::dispose()
 (/include/cppuhelper/compbase8.hxx:59)
by 0xD468F85:
 cppu::try_dispose(com::sun::star::uno::Referencecom::sun::star::uno::XInterface
 

Re: sc/source/core/data/dociter.cxx: really suspicious use of ! in condition

[Németh László]

Hi,

2015-02-18 17:06 GMT+01:00 Stephan Bergmann sberg...@redhat.com:

 (In this particular case, the mistake was only originally introduced a few
 hours earlier, so likely no build with plugins enabled happened to stumble
 over it before it got fixed.)

In this particular case, really a useful compiler warning/error
detected the problem (and I was very glad of it :):

Box name: iOS-ARM@29
 Branch: MASTER
 starttime: 1424212524
 Machine: Darwin sniff.local 14.1.0 Darwin Kernel Version 14.1.0: Mon
Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64
 Configured with: --with-parallelism=1
--with-distro=LibreOfficeiOS
--enable-symbols
--enable-werror
--disable-odk
--with-external-tar=/Users/tml/lo/core/src

 Commits since the last success:

  core 
  a5ab0e3  tdf#89436 handle skipping empty rows

...

[build CXX] sc/source/core/data/dociter.cxx
/Users/tml/lo/master-ios-arm/sc/source/core/data/dociter.cxx:2324:44:
error: logical not is only applied to the left hand side of this
comparison [-Werror,-Wlogical-not-parentheses]
if ( !bRowEmpty  bRepeatedRow  ! nMinNextEnd  nRow ) //
use the data of the previous row
   ^ ~
/Users/tml/lo/master-ios-arm/sc/source/core/data/dociter.cxx:2324:44:
note: add parentheses after the '!' to evaluate the comparison first
if ( !bRowEmpty  bRepeatedRow  ! nMinNextEnd  nRow ) //
use the data of the previous row
   ^
 ( )
/Users/tml/lo/master-ios-arm/sc/source/core/data/dociter.cxx:2324:44:
note: add parentheses around left hand side expression to silence this
warning
if ( !bRowEmpty  bRepeatedRow  ! nMinNextEnd  nRow ) //
use the data of the previous row
   ^
   ()
1 error generated.
make[1]: *** 
[/Users/tml/lo/master-ios-arm/workdir/CxxObject/sc/source/core/data/dociter.o]
Error 1
make: *** [build] Error 2)

Best regards,
Laszlo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: Branch 'libreoffice-4-4' - sc/inc sc/source

[Németh László]

 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;
 

Re: build break for LO 4.2.5.0.0+

[Németh László]

Hi,

Thanks to Caolán McNamara's quick patch, the problem has been fixed.
Thanks for your feedback, sorry for the problem.

Best regards,
László

2014-04-23 12:46 GMT+02:00 Jean-Baptiste Faure jbf.fa...@sud-ouest.org:
 Hi,

 Since the commit update wildcards in French autocorrection file
 http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-2id=53b05e7d11d128d6aac7fc9d4c22b3c479023d67

 building LO 4.2.5.0.0+ fails with the following error message :
 .../extras/source/autotext/lang/fr/acor/DocumentList.xml:17: parser
 error : Unescaped '' not allowed in attributes values
   block-list:block block-list:abbreviated-name=// block-list:name=◄/
^
 Best regards.
 JBF
 --
 Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Issue with libhyphen

[Németh László]

Dear Bert,

It seems for me, that your hyphenation patterns haven't been processed
by the substrings.pl script of libhyphen distribution. Could you check
it?

Thanks for your bug report,

Best regards,
László

2014-03-24 14:44 GMT+01:00 Bert Frees bertfr...@gmail.com:
 Dear László and others,

 We think we may have found a bug in libhyphen. It could be that it is just a
 limitation of the algorithm, but anyway it's an issue for us.

 The problem is that some patterns in a dictionary are ignored in some cases,
 namely when the match string of that pattern is a part of the match string
 of another pattern, and more specifically when it's not just a prefix.

 Let me clarify that with an example. When a dictionary consists of these two
 patterns, the word `foobar' is not hyphenated because the first pattern is
 ignored:

 oo1b
 foob

 The second, longer pattern doesn't even have to match, as the second example
 shows (the first pattern is still ignored):

 oo1b
 foobz

 I have a patch that solves part of the problem:

 https://github.com/bertfrees/libhyphen-nar/blob/adc2b74a19469e4dc93777fcdb82e36e566a0472/src/patches/bug.patch

 With this patch the given examples will be handled correctly, but in other
 situations it will still fail, such as here:

 oo1b
 foobaz

 Have I indeed found a bug here, and does my patch make sense, or am I just
 expecting too much and are we hitting the limits of the algorithm?

 Thanks for considering,
 Bert Frees
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Issue with libhyphen

[Németh László]

Dear Bert,

I am glad of it. Yes, it is not a bug. Thanks for the feedback.

Best regards,

László

2014-03-24 15:57 GMT+01:00 Bert Frees bertfr...@gmail.com:
 Dear László,

 Thanks for your answer. You are right, substrings.pl turns out to be exactly
 what I need.

 So I guess this is not a bug. I missed the section about the substrings
 script in the README, although it is made obvious enough with warnings etc.
 :)

 Cheers,
 Bert


 2014-03-24 15:19 GMT+01:00 Németh László nem...@numbertext.org:

 Dear Bert,

 It seems for me, that your hyphenation patterns haven't been processed
 by the substrings.pl script of libhyphen distribution. Could you check
 it?

 Thanks for your bug report,

 Best regards,
 László

 2014-03-24 14:44 GMT+01:00 Bert Frees bertfr...@gmail.com:
  Dear László and others,
 
  We think we may have found a bug in libhyphen. It could be that it is
  just a
  limitation of the algorithm, but anyway it's an issue for us.
 
  The problem is that some patterns in a dictionary are ignored in some
  cases,
  namely when the match string of that pattern is a part of the match
  string
  of another pattern, and more specifically when it's not just a prefix.
 
  Let me clarify that with an example. When a dictionary consists of these
  two
  patterns, the word `foobar' is not hyphenated because the first pattern
  is
  ignored:
 
  oo1b
  foob
 
  The second, longer pattern doesn't even have to match, as the second
  example
  shows (the first pattern is still ignored):
 
  oo1b
  foobz
 
  I have a patch that solves part of the problem:
 
 
  https://github.com/bertfrees/libhyphen-nar/blob/adc2b74a19469e4dc93777fcdb82e36e566a0472/src/patches/bug.patch
 
  With this patch the given examples will be handled correctly, but in
  other
  situations it will still fail, such as here:
 
  oo1b
  foobaz
 
  Have I indeed found a bug here, and does my patch make sense, or am I
  just
  expecting too much and are we hitting the limits of the algorithm?
 
  Thanks for considering,
  Bert Frees


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [BUG] or [EVOL] about arrow enlargement in libreoffice draw ?

[Németh László]

Hello,

I think, it is not a bug. Using Modify-Convert-To Contour on the
selected black line shapes is the solution.

Best regards,
László

2013/9/12 Gay, Matthieu matthieu@capgemini.com:
 Hello,



 Can you look to the attached file?



 And tell me if the fact that we can't reduce the black lines the same as the
 yellow frame in libreoffice Draw, is a bug?



 Thank You very much,



 Matthieu GAY

 This message contains information that may be privileged or confidential and
 is the property of the Capgemini Group. It is intended only for the person
 to whom it is addressed. If you are not the intended recipient, you are not
 authorized to read, print, retain, copy, disseminate, distribute, or use
 this message or any part thereof. If you receive this message in error,
 please notify the sender immediately and delete all copies of this message.

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Grammar Check not working in Calc?

[Németh László]

Dear Guenter,

Unfortunately, Calc, Draw, moreover, Writer text frames haven't
supported grammar checking, yet.

Best regards,
László

2013/6/3 Guenter Bartsch guenter.bart...@gmail.com:
 dear all,

 just a quick question: are grammar check plugins supposed to work in calc?

 we have implemented a small grammar check plugin which works nicely in
 writer. however, it doesn't seem to get called ever when entering
 tests in calc spreadsheets - is this a bug in our plugin or a problem
 in libreoffice in general?

 thanks,

guenter
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

(more public) license

[Németh László]

All of my past  future contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license.

László Németh

-- Forwarded message --
From: Németh László nem...@numbertext.org
Date: 2011/7/8
Subject: License to my patches
To: le...@documentfoundation.org
Másolatot kap: Andras Timar tima...@gmail.com


Dear Foundation,

All my contributions are under LGPLv3+/MPL.

Best regards,
László Németh
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice text justification

[Németh László]

Hi,

I have added the improved version of the macro to the Typography
toolbar (second icon):

http://extensions.libreoffice.org/extension-center/typography-toolbar

It formats the actual justified paragraph or all justified paragraphs
of the selected text or document (formatting a huge document is quite
slow, so you can stop it by frequent pressing of Ctrl-Shift-Q or by
the icon Interrupt Macro of a customized Standard toolbar).

You can add keyboard event listeners or a background thread eg. in
Python to check and maybe modify the paragraph formatting, but it is
better to implement this feature as a new option of paragraph
formatting. There is a relevant paragraph setting in Writer, the
“expand single” word in the justified last paragraph line.

Best regards,
László



2013/3/8 Chris Tapp opensou...@keylevel.com:
 Hi Németh,

 On 7 Mar 2013, at 15:54, Németh László wrote:

 Hi,

 It seems, LibreOffice uses a TeX-like penalty system for
 justification, but without modifiable options and pdfTeX-like
 microtypography features. There are other problems in this area, for
 example, the (sometimes very ugly) missing kerning before the
 automatic hyphen character and the missing italic correction. (Also
 adding the hyphenation zone setting of the other word processors would
 be fine for left/right aligned paragraphs).

 Maybe a good method to improve typesetting of LibreOffice to add a new
 option for automatic extra (but limited) kerning/scaling of characters
 of lines with extra large spaces, but without the modification of the
 line breaks. I have made a Basic prototype to automatize this
 line-oriented character formatting (for all lines of a document,
 except the last lines of the paragraphs), allowing max. +4% character
 width and max. +3% kerning (for example, max. 0,36 pt extra character
 distance between 12pt characters):

 http://www.numbertext.org/tmp/micro.bas

 (Note: scaling of Graphite fonts doesn't modify the line breaks, so
 remove this section from the prototype to test it with Graphite
 fonts.)

 The test results seem better, than the original typesetting, except
 the hanging hyphen marks (this is a bug):

 http://www.numbertext.org/tmp/micro_all.pdf

 (micro.odt and micro_nohyph.odt are the original test files without
 modified kerning and scaling:

 http://www.numbertext.org/tmp/micro.odt
 http://www.numbertext.org/tmp/micro_kern.odt
 http://www.numbertext.org/tmp/micro_scale.odt
 http://www.numbertext.org/tmp/micro_kern_and_scale.odt
 http://www.numbertext.org/tmp/micro_nohyph.odt
 http://www.numbertext.org/tmp/micro_nohyph_kern.odt
 http://www.numbertext.org/tmp/micro_nohyph_scale.odt
 http://www.numbertext.org/tmp/micro_nohyph_kern_and_scale.odt)

 I plan to add a sophisticated version (maybe with shrinking, testing
 also minimal paragraph width modifications) to the typography toolbar
 (http://extensions.libreoffice.org/extension-center/typography-toolbar)
 to fix the selected paragraphs with one click.

 Thanks for this, it looks like a good place to start :-)

 Will it be possible to trigger the formatting
 using something embedded in the document which then applies it to one or more 
 specific paragraph styles?

 It may also be worth looking at 'runt' control at the same time (though many 
 think these should just be left).
 A 'runt' is the small fragment of text which is sometimes pushed onto the 
 last line of a paragraph. It can be
 controlled by preventing single words on the last line or setting a minimum 
 number of characters. Character
 based control is often better as preventing long words dropping down on their 
 own looks poor.

 Best regards,
 László
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

 Chris Tapp

 opensou...@keylevel.com
 www.keylevel.com



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: typographic freaks: footnotes not vertically aligned to last line of body text in following page (as in good typographic style)

[Németh László]

Hi,

I have added an icon to the Typography toolbar (the first one) to
automatize to set the correct height:

http://extensions.libreoffice.org/extension-center/typography-toolbar

Description: Click on the first icon to 'round' the page margins of
the actual page (style) for precise fitting of the text lines to the
page text area. The modification is based on the font height of the
Text body paragraph style.
Thanks to this setting, register-true page formatting or paragraphs
without extra spacing and headings with base line height based spacing
will result correct alignment of the bottom of normal text and
footnotes.

Regards,
László


2012/12/21 Németh László nemeth.la...@gmail.com:
 Hi, Thanks for your bug report
 (https://bugs.freedesktop.org/show_bug.cgi?id=58573).

 Unfortunately, there is no justified vertical alignment in LibreOffice.

 You can solve this problem with correct page space height (and removing the
 extra spaces between the paragraphs). For example, 12 pt body text and 50
 lines need 12 * 1.15 (default factor of the line height in LibreOffice) * 50
 = 690 pt = 690/72 = 9.583. Set the page margins to leave 9.584 for the
 page space, and the footnote and the body text will be aligned correctly.
 Use also register-true body text (see page and paragraph settings) and
 frames anchored to the top or the bottom of the page space.

 To simplify this process, I suggest a new behavior in the page setting
 dialog: checking the register-true check box or modification its reference
 style could “round” margin heights for the correct (“register-true”) page
 space size. Using the 12 pt reference style of the previous example, 2-2 cm
 top and bottom margins of an A4 page (21 cm x 29,70 cm) will be ~0.5mm-0.5mm
 narrower automatically:

 ((29.7/2.54)*72 - 12*1.15 * round29.7-2*2)/2.54)*72)/(12*1.15)))/72*2.54
 3.8978331
 instead of 4 cm.

 This little modification (1.94-1.94 cm top and bottom margins instead of
 2-2cm in this example) will eliminate the big justification problem of the
 page text and the footnotes and frames anchored to the page text area. Other
 UI option is a new button for this task.

 Regards,
 László







 2012/12/19 siren anna.walker-bodm8...@yopmail.com

 in these months Libreoffice gained new useful features and  team has fixed
 many long-time-unsolved bugs

 but there is a thing that, if we cannot strictly to define as a BUG, is,
 at least, a  defect regarding the right typography

 I mean the behavior of footnotes versus the text body contained in
 subsequent pages

 professionally formatted books, look like this

 http://tli.tl/m2507H

 as you can see, footnotes (last footnote) are perfectly vertically aligned
 with the last line of text in following page

 http://tli.tl/0740NZ (zoom in detail)

 while if we insert a footnote in OpenOffice/Libreoffice, this is what we
 get

 http://tli.tl/2mfCgT

 an horrible difference between footnote and last line of body text that
 result not aligned that makes appereance of documents with footnotes very
 ugly

 if making this enhancement is not too hard, it will be a great step toward
 dtp for LibreOffice
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Fwd: LibreOffice text justification

[Németh László]

Hi,

It seems, LibreOffice uses a TeX-like penalty system for
justification, but without modifiable options and pdfTeX-like
microtypography features. There are other problems in this area, for
example, the (sometimes very ugly) missing kerning before the
automatic hyphen character and the missing italic correction. (Also
adding the hyphenation zone setting of the other word processors would
be fine for left/right aligned paragraphs).

Maybe a good method to improve typesetting of LibreOffice to add a new
option for automatic extra (but limited) kerning/scaling of characters
of lines with extra large spaces, but without the modification of the
line breaks. I have made a Basic prototype to automatize this
line-oriented character formatting (for all lines of a document,
except the last lines of the paragraphs), allowing max. +4% character
width and max. +3% kerning (for example, max. 0,36 pt extra character
distance between 12pt characters):

http://www.numbertext.org/tmp/micro.bas

(Note: scaling of Graphite fonts doesn't modify the line breaks, so
remove this section from the prototype to test it with Graphite
fonts.)

The test results seem better, than the original typesetting, except
the hanging hyphen marks (this is a bug):

http://www.numbertext.org/tmp/micro_all.pdf

(micro.odt and micro_nohyph.odt are the original test files without
modified kerning and scaling:

http://www.numbertext.org/tmp/micro.odt
http://www.numbertext.org/tmp/micro_kern.odt
http://www.numbertext.org/tmp/micro_scale.odt
http://www.numbertext.org/tmp/micro_kern_and_scale.odt
http://www.numbertext.org/tmp/micro_nohyph.odt
http://www.numbertext.org/tmp/micro_nohyph_kern.odt
http://www.numbertext.org/tmp/micro_nohyph_scale.odt
http://www.numbertext.org/tmp/micro_nohyph_kern_and_scale.odt)

I plan to add a sophisticated version (maybe with shrinking, testing
also minimal paragraph width modifications) to the typography toolbar
(http://extensions.libreoffice.org/extension-center/typography-toolbar)
to fix the selected paragraphs with one click.

Best regards,
László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Grammar checker] Undocumented change in the API for LO 4

[Németh László]

Hi,

If I right know, that was an intended change from the original author,
Thomas Lange, supported by the contributors, eg. Marcin Miłkowski and
Daniel Naber, for the real needs, better sentence boundary
disambiguation and grammar checking by LanguageTool and other grammar
checker components. So the recent state is a drawback. I suggest to
revert it (maybe it would be fine to add some comments to the
ProofreadingResult.idl to prevent from similar changes, too).

Best regards,
László

2013/3/4 Olivier R. olivier.nore...@gmail.com:
 Caolán McNamara wrote
 do you get the pre LO 4 behaviour ?

 Probably.
 With LO 3, in doProofreading:
 - nStartOfSentencePos was always the beginning of the paragraph (=0)
 - nSuggestedSentenceEndPos was always the end of the paragraph (=length of
 rText)

 And each paragraph was passed once to the GC.



 Assuming that you do, then it appears to me that the current LO4
 behaviour is the original programmer intent and that the intermediate
 behaviour was a bug (from the programmer intent perspective anyway) in
 whatever versions got released between
 9f2fde7ab5de20926bb25a6b298b4e5dffb66eb2 and LO4

 Yes, we can assume that was the original programmer intent.
 But it worked another way for 3 years and nobody complained about it. :)
 I prefer the unintended behavior, as LO does not  assume wrongly what is the
 end of sentences.

 So what LO will do?

 Olivier



 --
 View this message in context: 
 http://nabble.documentfoundation.org/Grammar-checker-Undocumented-change-in-the-API-for-LO-4-tp4030639p4041580.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Regression - LO Writer 4.0

[Németh László]

Hi,

2013/2/25 Michael Stahl mst...@redhat.com:
 that regression was only on master, not on libreoffice-4-0.

Indeed.

 i rather suspect the performance problem was caused by the synchronous
 word count that is now running async in 4.0.1 (thanks to mmeeks).

Thanks for the information and the fix! László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Regression - LO Writer 4.0

[Németh László]

Hi Ray,

For your information, I have reported a LibO 4.0.0 regression with the
“Clear screen” Logo toolbar button, and fixed by Michael Stahl on
2012-02-18. Also slower selection/handling of drawing objects caused
by this bug, maybe this was the background of your problem, too. See
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2eef912649d277e05203bc79c26f2be5b096a292
– SwXTextView::select(): unselect drawing objects at start...
... and not before selecting each object, which leaves only the last
object selected

Best regards, László

2013/2/22 r_ouellette ray.ouelle...@sympatico.ca:
 I confirm that fluidity is back also on win32 version (winxp at the office),
 LO 4.0.1.1.

 Raymond



 --
 View this message in context: 
 http://nabble.documentfoundation.org/Regression-LO-Writer-4-0-tp4038481p4039356.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: A little info about ligatures and e.g. Calibri

[Németh László]

Hi,

2013/2/7 Stephan Bergmann sberg...@redhat.com

 And do we have decent support to let the user specify where not to use
 ligatures in the input?  Or do users need to insert explicit U+200C ZWNJ
 with their input method of choice?

 (At least for German, where ligatures need to be broken quite frequently,
 I generally don't understand the enthusiasm for ligature-enabled fonts
 anyway, as in the hands of incompetent typists they lead to more harm than
 good.  What could probably help is to have automated rules that tell the
 computer where to break ligatures, similar to hyphenation rules.)


You are right. I knew the special requirement of German typography, but I
didn't check ZWNJ usage with ligature-enabled Linux Libertine G Graphite
font before. (It seems, the ligature replacement is default for German in
the original OpenType version, too). I have filled an issue about the
problems and the possible fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60427.

I have made an initial patch in this direction: now spell checking accepts
the words with ZWNJ and ZWJ characters, also with Unicode f-ligatures in
the case of 8-bit encoded spelling dictionaries. (It seems, users of poor
TTF fonts need this poor man's method:
https://bugs.freedesktop.org/show_bug.cgi?id=59337, for UTF-8 encoded
spelling dictionaries, you can set ICONV and IGNORE Hunspell options, if
needed).

I have already added some language specific exceptions for Dutch f-ligature
replacement in Linux Libertine G, but Graphite is not enough to handle the
requirements of German. Maybe a good method to handle this problem is a new
Localized option of Autocorrect add ZWNJ for German compounds, also an
optional grammar checker feature check ZWNJ in German compound.  Also
hyphenation and search/replacement may need modification.

Regards,
László


 Stephan

 __**_
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.**org LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/**mailman/listinfo/libreofficehttp://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: typographic freaks: footnotes not vertically aligned to last line of body text in following page (as in good typographic style)

[Németh László]

Hi, Thanks for your bug report (
https://bugs.freedesktop.org/show_bug.cgi?id=58573).

Unfortunately, there is no justified vertical alignment in LibreOffice.

You can solve this problem with correct page space height (and removing the
extra spaces between the paragraphs). For example, 12 pt body text and 50
lines need 12 * 1.15 (default factor of the line height in LibreOffice) *
50 = 690 pt = 690/72 = 9.583. Set the page margins to leave 9.584 for the
page space, and the footnote and the body text will be aligned correctly.
Use also register-true body text (see page and paragraph settings) and
frames anchored to the top or the bottom of the page space.

To simplify this process, I suggest a new behavior in the page setting
dialog: checking the register-true check box or modification its reference
style could “round” margin heights for the correct (“register-true”) page
space size. Using the 12 pt reference style of the previous example, 2-2 cm
top and bottom margins of an A4 page (21 cm x 29,70 cm) will be
~0.5mm-0.5mm narrower automatically:

((29.7/2.54)*72 - 12*1.15 * round29.7-2*2)/2.54)*72)/(12*1.15)))/72*2.54
3.8978331
instead of 4 cm.

This little modification (1.94-1.94 cm top and bottom margins instead of
2-2cm in this example) will eliminate the big justification problem of the
page text and the footnotes and frames anchored to the page text area.
Other UI option is a new button for this task.

Regards,
László







2012/12/19 siren anna.walker-bodm8...@yopmail.com

 in these months Libreoffice gained new useful features and  team has fixed
 many long-time-unsolved bugs

 but there is a thing that, if we cannot strictly to define as a BUG, is,
 at least, a  defect regarding the right typography

 I mean the behavior of footnotes versus the text body contained in
 subsequent pages

 professionally formatted books, look like this

 http://tli.tl/m2507H

 as you can see, footnotes (last footnote) are perfectly vertically aligned
 with the last line of text in following page

 http://tli.tl/0740NZ (zoom in detail)

 while if we insert a footnote in OpenOffice/Libreoffice, this is what we
 get

 http://tli.tl/2mfCgT

 an horrible difference between footnote and last line of body text that
 result not aligned that makes appereance of documents with footnotes very
 ugly

 if making this enhancement is not too hard, it will be a great step toward
 dtp for LibreOffice
 __**_
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.**org LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/**mailman/listinfo/libreofficehttp://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: lightproof and python3.3 (was: Re: [Grammar checking] Using LanguageTool lexicons with Lightproof) new possible

[Németh László]

Hi,

Indeed, this is a more general problem with the bundled spelling
dictionaries:

https://bugs.freedesktop.org/show_bug.cgi?id=58503 (Options-Writing Aids
doesn't list the available bundled language modules)

2012/12/18 Rene Engelhard r...@debian.org

 Hi again,

 On Mon, Dec 17, 2012 at 06:49:55PM +0100, Németh László wrote:
 It seems, the LinguServiceManager used by the optlingu.cxx (Writing
 Aids)
 doesn't know the bundled English package (I have checked on Windows
 and
 Linux). I will check the python 3.3 port again.

 FWIW: With

 lightproof of 2012-11-23 and python-uno from this night (built against 2.7)

 this doesn't work either. (doesn't warn, does not appear in
 writing aids/corrects.)

 So it *seems* that it's not only a python 3.3 port problem?


It seems, the configuration problem of the bundled dictionary extension.
Extra installations of dictionary extensions with Lightproof modules works,
moreover, installation of the Hungarian dictionary extension fixes the
missing English spell checking with the bundled English dictionary
extension.



 Regards,

 Rene

 P.S: Is the python3.3-capable lightproof also supporting python2 or does
 it really need
 python 3.3?


I think, python-uno and Lightproof have to work with Python 2, too. (But I
have checked only the bytecode compilation of the newest Lightproof with
Python 2.7).

Thanks,
László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: lightproof and python3.3 (was: Re: [Grammar checking] Using LanguageTool lexicons with Lightproof) new possible

[Németh László]

Hi,

It seems, the LinguServiceManager used by the optlingu.cxx (Writing Aids)
doesn't know the bundled English package (I have checked on Windows and
Linux). I will check the python 3.3 port again.

Regards,
László





2012/12/17 Rene Engelhard r...@debian.org

 Hi,

 On Wed, Dec 05, 2012 at 11:17:21AM +0100, Németh László wrote:
 By the way, I have ported the lightproof modules to Python 3.3, but it
 seems, there is a registration issue with the bundled dictionary
 packages
 with Lightproof components (unfortunately, I couldn't test it
 yesterday,
 because the daily build had a missing library problem on Ubuntu), so I
 will write soon.

 What is the status on this?

 I have
  - a beta1 build with a python3-uno built against system python3.3
(snapshot from weekend is bad, too)
  - lightproof-libreoffice-en. Based on latest git of
http://cgit.freedesktop.org/libreoffice/lightproof, so *with* the
python3.3 port
(both also availale at http://people.debian.org/~rene/libreoffice/4.0.0
 )
  - python3.3 as of Debian experimental (
 http://packages.debian.org/search?keywords=python3.3 and
 http://packages.debian.org/search?keywords=python3)

 and I do still get the unknown state of the lightproof extensions when
 I install them.

 Interestingly, when I installed 4.0.0 beta1 _for Windows_ in a VM it
 worked?!

 (3.6.4-1 and lightproof of 2012-11-23 - before the python 3.3 fixes - do
 also work just fine)

 Regards,

 Rene

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Installing our CLI DLLs on Windows XP SP3 with .NET 2.0 and 3.5 (but no newer) fails

[Németh László]

Hi,

I have ran into this problem.
http://forum.openoffice.org/en/forum/viewtopic.php?f=15t=32902 suggests to
install .NET 4, but its full installation (+40 MB) needs internet
connection under Windows, too. Unfortunatelly, my old, but safe Windows XP
machine has no internet connection.
Best regards,
László



2012/12/10 Andras Timar tima...@gmail.com

 Hi Tor,

 On Mon, Dec 10, 2012 at 8:59 AM, Tor Lillqvist t...@iki.fi wrote:
  This is probably nothing new, but something I just recently became
  aware of, using my build from the libreoffice-4-0 branch. I am not
  sure if I have interpreted my testing correctly, please discuss.
 

 You probably built with .NET 4.0 SDK. There is a CustomAction in
 installer that checks for the required .NET version, which is 2.0.0.0
 at the moment.

 http://opengrok.libreoffice.org/xref/core/setup_native/source/win32/customactions/shellextensions/dotnetcheck.cxx#128
 Either we can bump this (REQUIRED_DOTNET_VERSION) to 4.0.0.0 or we
 should make sure that we use older .NET SDK. I'm happy with both
 options. Are there any users of this assembly at all? It is either
 perfect, or there are no users, because I have not seen any bug
 reports related to this feature.

 Best regards,
 Andras
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

Hello,

I will check your fixes, and make a new release from the Numbertext
extension (with fixes and the new Latvian and Lithuanian modules of the
version 0.9.5). Many thanks for your work and mail!

Best regards,
Laszlo



2012/12/5 julien2412 serval2...@yahoo.fr

 Hello,

 By trying to reproduce an fdo, I got a lot of these on console:
 Python exception: class 'TabError': inconsistent use of tabs and spaces
 in
 indentation (__init__.py, line 70), traceback follows


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/uno.py:265
 in function _uno_import() [return _g_delegatee( name, *optargs, **kwargs )]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/share/extensions/numbertext/
 reg.uno.py:7
 in function createInstance() [import org.Numbertext]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/unohelper.py:292
 in function createInstanceWithContext() [return self.clazz( context )

 So I unzipped src/b8cbca7b3363e6ca2d02bc0ba2b63904-numbertext_0.9.4.oxt and
 runned pep8 (1.3.3 version) on it. Except E501 lines too long, I fixed
 all
 the pep8 warnings. I put all the changes files here:
 changes.tar.bz2
 http://nabble.documentfoundation.org/file/n4022762/changes.tar.bz2

 pylint gives warnings too but I don't know really how to fix them.

 If it's ok, does it worth it to create a new version of numbertext?

 Julien




 --
 View this message in context:
 http://nabble.documentfoundation.org/About-numbertext-tp4022762.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

Hello,

I have made the complete port, tested with LibreOffice 4.0 and 3.6:
http://extensions.libreoffice.org/extension-center/numbertext-1/pscreleasefolder.2012-10-09.7591543982/0.9.5/numbertext-0.9.5.oxt
or
http://www.numbertext.org/dist/numbertext-0.9.5.oxt
Could you update the numbertext src package of the LibreOffice? Thanks in
advance,
Best regards,
Laszlo


2012/12/6 Németh László nem...@numbertext.org

 Hello,

 I will check your fixes, and make a new release from the Numbertext
 extension (with fixes and the new Latvian and Lithuanian modules of the
 version 0.9.5). Many thanks for your work and mail!

 Best regards,
 Laszlo




 2012/12/5 julien2412 serval2...@yahoo.fr

 Hello,

 By trying to reproduce an fdo, I got a lot of these on console:
 Python exception: class 'TabError': inconsistent use of tabs and spaces
 in
 indentation (__init__.py, line 70), traceback follows


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/uno.py:265
 in function _uno_import() [return _g_delegatee( name, *optargs, **kwargs
 )]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/share/extensions/numbertext/
 reg.uno.py:7
 in function createInstance() [import org.Numbertext]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/unohelper.py:292
 in function createInstanceWithContext() [return self.clazz( context )

 So I unzipped src/b8cbca7b3363e6ca2d02bc0ba2b63904-numbertext_0.9.4.oxt
 and
 runned pep8 (1.3.3 version) on it. Except E501 lines too long, I fixed
 all
 the pep8 warnings. I put all the changes files here:
 changes.tar.bz2
 http://nabble.documentfoundation.org/file/n4022762/changes.tar.bz2

 pylint gives warnings too but I don't know really how to fix them.

 If it's ok, does it worth it to create a new version of numbertext?

 Julien




 --
 View this message in context:
 http://nabble.documentfoundation.org/About-numbertext-tp4022762.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

Hello,

I have made the complete port, tested with LibreOffice 4.0 and 3.6:
http://extensions.libreoffice.org/extension-center/numbertext-1/pscreleasefolder.2012-10-09.7591543982/0.9.5/numbertext-0.9.5.oxt
or
http://www.numbertext.org/dist/numbertext-0.9.5.oxt
Could you help to update the numbertext src package of the LibreOffice?
Thanks in advance,
Best regards,
Laszlo

2012/12/6 Németh László nem...@numbertext.org

 Hello,

 I will check your fixes, and make a new release from the Numbertext
 extension (with fixes and the new Latvian and Lithuanian modules of the
 version 0.9.5). Many thanks for your work and mail!

 Best regards,
 Laszlo




 2012/12/5 julien2412 serval2...@yahoo.fr

 Hello,

 By trying to reproduce an fdo, I got a lot of these on console:
 Python exception: class 'TabError': inconsistent use of tabs and spaces
 in
 indentation (__init__.py, line 70), traceback follows


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/uno.py:265
 in function _uno_import() [return _g_delegatee( name, *optargs, **kwargs
 )]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/share/extensions/numbertext/
 reg.uno.py:7
 in function createInstance() [import org.Numbertext]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/unohelper.py:292
 in function createInstanceWithContext() [return self.clazz( context )

 So I unzipped src/b8cbca7b3363e6ca2d02bc0ba2b63904-numbertext_0.9.4.oxt
 and
 runned pep8 (1.3.3 version) on it. Except E501 lines too long, I fixed
 all
 the pep8 warnings. I put all the changes files here:
 changes.tar.bz2
 http://nabble.documentfoundation.org/file/n4022762/changes.tar.bz2

 pylint gives warnings too but I don't know really how to fix them.

 If it's ok, does it worth it to create a new version of numbertext?

 Julien




 --
 View this message in context:
 http://nabble.documentfoundation.org/About-numbertext-tp4022762.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice






2012/12/6 Németh László nem...@numbertext.org

 Hello,

 I will check your fixes, and make a new release from the Numbertext
 extension (with fixes and the new Latvian and Lithuanian modules of the
 version 0.9.5). Many thanks for your work and mail!

 Best regards,
 Laszlo




 2012/12/5 julien2412 serval2...@yahoo.fr

 Hello,

 By trying to reproduce an fdo, I got a lot of these on console:
 Python exception: class 'TabError': inconsistent use of tabs and spaces
 in
 indentation (__init__.py, line 70), traceback follows


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/uno.py:265
 in function _uno_import() [return _g_delegatee( name, *optargs, **kwargs
 )]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/share/extensions/numbertext/
 reg.uno.py:7
 in function createInstance() [import org.Numbertext]


 /home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/unohelper.py:292
 in function createInstanceWithContext() [return self.clazz( context )

 So I unzipped src/b8cbca7b3363e6ca2d02bc0ba2b63904-numbertext_0.9.4.oxt
 and
 runned pep8 (1.3.3 version) on it. Except E501 lines too long, I fixed
 all
 the pep8 warnings. I put all the changes files here:
 changes.tar.bz2
 http://nabble.documentfoundation.org/file/n4022762/changes.tar.bz2

 pylint gives warnings too but I don't know really how to fix them.

 If it's ok, does it worth it to create a new version of numbertext?

 Julien




 --
 View this message in context:
 http://nabble.documentfoundation.org/About-numbertext-tp4022762.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

Hi Stephan, hi Kami,

I'm sorry, the first link was a not public link of the of the extension
with pending approval at LibreOffice Extensions site, and the target of the
second one wasn't updated yet. Here is the right link (extended with the
md5sum):

http://numbertext.org/dist/92973266240813c7bdb44a4b7d85af04-numbertext-0.9.5.oxt

Kami, could you help to copy this extension to the itc.hu?

Many thanks for your help.
Best regards,
Laszlo





2012/12/6 Stephan Bergmann sberg...@redhat.com

 On 12/06/2012 02:02 PM, Németh László wrote:

 I have made the complete port, tested with LibreOffice 4.0 and 3.6:
 http://extensions.libreoffice.**org/extension-center/**
 numbertext-1/pscreleasefolder.**2012-10-09.7591543982/0.9.5/**
 numbertext-0.9.5.oxthttp://extensions.libreoffice.org/extension-center/numbertext-1/pscreleasefolder.2012-10-09.7591543982/0.9.5/numbertext-0.9.5.oxt
 or
 http://www.numbertext.org/**dist/numbertext-0.9.5.oxthttp://www.numbertext.org/dist/numbertext-0.9.5.oxt
 Could you update the numbertext src package of the LibreOffice? Thanks
 in advance,


 LO wants to download the prebuilt oxt from http://ooo.itc.hu/**
 oxygenoffice/download/**libreoffice/**510117359dc91181ea06b4aa8582ed**
 2c-numbertext-0.9.5.oxthttp://ooo.itc.hu/oxygenoffice/download/libreoffice/510117359dc91181ea06b4aa8582ed2c-numbertext-0.9.5.oxt
 (see LO's Makefile.fetch), so if somebody (Kami?) can put it there, that
 would be the easiest.  I can adapt the single line setting
 NUMBERTEXT_EXTENSION_PACK in LO's configure.ac then.

 The first link above leads to a broken oxt, so I assume the second link
 points to what we want (and the md5sum I give above is for that one).

 Stephan


  2012/12/6 Németh László nem...@numbertext.org
 mailto:nem...@numbertext.org**


 Hello,

 I will check your fixes, and make a new release from the Numbertext
 extension (with fixes and the new Latvian and Lithuanian modules of
 the version 0.9.5). Many thanks for your work and mail!

 Best regards,
 Laszlo




 2012/12/5 julien2412 serval2...@yahoo.fr mailto:serval2...@yahoo.fr
 


 Hello,

 By trying to reproduce an fdo, I got a lot of these on console:
 Python exception: class 'TabError': inconsistent use of tabs
 and spaces in
 indentation (__init__.py, line 70), traceback follows

 /home/julien/compile-**libreoffice/libo/solver/**
 unxlngx6/installation/opt/**program/uno.py:265
 in function _uno_import() [return _g_delegatee( name, *optargs,
 **kwargs )]

 /home/julien/compile-**libreoffice/libo/solver/**
 unxlngx6/installation/opt/**share/extensions/numbertext/re**g.uno.py:7http://reg.uno.py:7
 http://reg.uno.py:7

 in function createInstance() [import org.Numbertext]

 /home/julien/compile-**libreoffice/libo/solver/**
 unxlngx6/installation/opt/**program/unohelper.py:292
 in function createInstanceWithContext() [return self.clazz(
 context )

 So I unzipped
 src/**b8cbca7b3363e6ca2d02bc0ba2b639**04-numbertext_0.9.4.oxt and
 runned pep8 (1.3.3 version) on it. Except E501 lines too long,
 I fixed all
 the pep8 warnings. I put all the changes files here:
 changes.tar.bz2
 http://nabble.**documentfoundation.org/file/**
 n4022762/changes.tar.bz2http://nabble.documentfoundation.org/file/n4022762/changes.tar.bz2
 

 pylint gives warnings too but I don't know really how to fix them.

 If it's ok, does it worth it to create a new version of
 numbertext?

 Julien


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

2012/12/6 Matúš Kukan matus.ku...@gmail.com

 On 6 December 2012 14:40, Stephan Bergmann sberg...@redhat.com wrote:
  LO wants to download the prebuilt oxt from
  
 http://ooo.itc.hu/oxygenoffice/download/libreoffice/510117359dc91181ea06b4aa8582ed2c-numbertext-0.9.5.oxt
 
  (see LO's Makefile.fetch), so if somebody (Kami?) can put it there, that
  would be the easiest.  I can adapt the single line setting
  NUMBERTEXT_EXTENSION_PACK in LO's configure.ac then.

 Can't we just change this and use http://dev-www.libreoffice.org/src/ ?


Yes, it would be fine, also with the hunart and the typography toolbar
extensions.

Laszlo




 Matus

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

Hi,

Final release:
http://numbertext.org/dist/b7cae45ad2c23551fd6ccb8ae2c1f59e-numbertext-0.9.5.oxt

Unfortunately, I don't know the exact status of this extension in
LibreOffice. I will publish it on the LibreOffice Extensions site, too
(also the other ones mentioned in my previous letter).

Thanks,
László


2012/12/6 Stephan Bergmann sberg...@redhat.com

 On 12/06/2012 03:23 PM, Matúš Kukan wrote:

 On 6 December 2012 14:40, Stephan Bergmann sberg...@redhat.com wrote:

 LO wants to download the prebuilt oxt from
 http://ooo.itc.hu/**oxygenoffice/download/**libreoffice/**
 510117359dc91181ea06b4aa8582ed**2c-numbertext-0.9.5.oxthttp://ooo.itc.hu/oxygenoffice/download/libreoffice/510117359dc91181ea06b4aa8582ed2c-numbertext-0.9.5.oxt
 
 (see LO's Makefile.fetch), so if somebody (Kami?) can put it there, that
 would be the easiest.  I can adapt the single line setting
 NUMBERTEXT_EXTENSION_PACK in LO's configure.ac then.


 Can't we just change this and use 
 http://dev-www.libreoffice.**org/src/http://dev-www.libreoffice.org/src/?


 My understanding is that Kami/OxygenOffice/ooo.itc.hu (whether and
 however they are actually connected) are the only real consumers to
 include that prebuilt numbertext oxt as a bundled extension in installation
 sets.  As such, I think it is best to keep the sources hosted at
 ooo.itc.hu or, if that does not work well, drop --enable-ext-numbertext
 support from LO.

 My stake in this is merely that I like to misuse the various
 --enable-ext-* switches that appear to be there for the benefit of
 OxygenOffice, to easily have some real extensions as seen in the wild
 installed in the local builds I do, to see there are any problems with
 them.  So if there is a cheap way to keep those --enable-ext-* switches
 alive, I do not mind getting involved in some simple maintenance work
 around them occasionally.  But, on the other hand, I would not cry if they
 were gone for good, either.

 Stephan

 __**_
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.**org LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/**mailman/listinfo/libreofficehttp://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Grammar checking] Using LanguageTool lexicons with Lightproof new possible

[Németh László]

Hi Olivier,

Thanks, I have tested it, quite fast the dictionary lookup!

Best regards,
László



2012/12/6 Olivier R. olivier.nore...@gmail.com

 Hi László,

 In fsa_builder.py, in class DAWG, you can replace :

 self.minimizedNodes = collections.OrderedDict()

 by

 self.minimizedNodes = {}

 Creating the DAWG is much quicker with a simple dictionary than with an
 ordered dictionary.
 I only used the latest to test compression with a sorted DAWG, but it’s
 unuseful with this version of the script.


 Regards,
 Olivier



 --
 View this message in context:
 http://nabble.documentfoundation.org/Grammar-checking-Using-LanguageTool-lexicons-with-Lightproof-new-possible-tp4022489p4022817.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About numbertext

[Németh László]

Hi,

Many thanks for your help. Best regards, László

PS. I have published the source distribution, too:
http://numbertext.org/dist/numbertext-0.9.5.tar.gz.


2012/12/6 Andras Timar tima...@gmail.com

 Hi,

 On Thu, Dec 6, 2012 at 4:30 PM, Németh László nem...@numbertext.org
 wrote:
  Hi,
 
  Final release:
 
 http://numbertext.org/dist/b7cae45ad2c23551fd6ccb8ae2c1f59e-numbertext-0.9.5.oxt
 

 I pushed the changes to master and libreoffice-4-0.

 Best regards,
 Andras

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Grammar checking] Using LanguageTool lexicons with Lightproof new possible

[Németh László]

Hi Olivier,

Great work! Now it's possible to write a full rule converter for the
existing LanguageTool modules. I will add your library to the lightproof
module with an example/test.

By the way, I have ported the lightproof modules to Python 3.3, but it
seems, there is a registration issue with the bundled dictionary packages
with Lightproof components (unfortunately, I couldn't test it yesterday,
because the daily build had a missing library problem on Ubuntu), so I will
write soon.

Best regards,
László


2012/12/4 Olivier R. olivier.nore...@gmail.com

 My connection ended while posting. Here is the full post:


 Hello everyone,

 ## Build indexable binary grammatically tagged dictionaries for
 Lightproof/Grammalecte ##

 The most important limitation for building a grammar checker with
 Lightproof
 was the lack of grammatically tagged dictionaries. Most of Hunspell
 dictionaries, which Lightproof can handle via LibreOffice-UNO, are not
 grammatically tagged and cannot be of any help to retrieve morphological
 information about words.

 LanguageTool has not this problem since it’s using binary indexable
 dictionaries built on huge grammatically tagged lexicons with a
 finite-state
 automaton (fsa) software
 (
 http://www.eti.pg.gda.pl/katedry/kiw/pracownicy/Jan.Daciuk/personal/fsa.html
 )
 written in C. Java has a dedicated library to read these binary files.

 But we had nothing such as this in Python.
 So I tried to understand how this FSA software in C works, but as I am not
 a
 C expert and as I was upset to depend again on another software, I finally
 decided to write my own FSA tool to build such indexable binary
 dictionaries.

 Why build such dictionaries? you may ask. Because lexicons which contain
 words, lemmas and morphological tags are HUGE, up to several megabytes,
 they
 are not indexable as is and it uses much more memory to make them such. So
 the goal is to make them small, compressed, quick to load and to parse, low
 memory consuming, indexable, readable without having to uncompress them.

 That’s what I did with Python 3.3.

 I took all lexicons from LanguageTool and I compressed them in binary
 indexable dictionaries readable with my own script.
 The built dictionaries are not as small as the ones made with the C FSA
 tool
 used by LT, but it’s close enough and there is still room for improvements.
 I’ll work on this later.

 Here are the results:


 These dictionaries are about 5-30 % bigger than the LT ones (and sometimes
 surprisingly twice smaller), but anyhow it’s perfectly usable as is.

 Consequences:
 — it will be possible to use all existing LT lexicons with Lightproof,
 — we will be able to make a stand-alone version of Lightproof/Grammalecte
 as
 it won’t be necessary to use Hunspell anymore,
 — we will be able to write automated tests and prevent regressions when
 writting/modifying rules.


 # Lexicons

 Lexicon are simple text document listing all flexions, their stem and their
 morphological tags:



 Each field is separated with a tabulation.

 With the new tool, lexicons MUST be UTF-8 encoded to be properly converted.


 # Want to test it?

 The code is written with Python 3.3. License: MPL 2.

 Two files:
 — fsa_builder.py  reads all files listed in _lexicons.list.txt and
 builds binary dictionaries with a specific stemming command.
 — fsa_reader.py   reads all files whose name is [lang].bdic, and if
 it
 finds a test file named [lang].test.txt writes results found for each
 word
 in a new file.

 The builder with uncompressed LT lexicons encoded in UTF-8:
 http://dicollecte.free.fr/download/fsa1/pyFSA_builder.7z [130 Mb]

 Type:



 And let it run. Warning: building dictionaries is slow, as lexicons are
 huge. For most langages it takes 1 or 2 minutes for each. But for german,
 polish, galician, russian, czech, it tooks 5 to 10 minutes for each, and it
 consumes a huge amount of memory. The czech uses up to 6 Gb! You have been
 warned. :)

 The dictionary reader with binary dictionaries and test files:
 http://dicollecte.free.fr/download/fsa1/pyFSA_reader.7z [11 Mb]

 Type:



 Let it run. Count to 1 (or 2 if you have a slow computer). And it’s already
 finished. :)
 It has read all binary dictionaries, read the test files, and written the
 results in other files.

 I’ll try to write a more complete web page about this when I have the time.
 I still have to compress it better, for those who might think it’s not
 enough.


 Regards,
 Olivier R.



 --
 View this message in context:
 http://nabble.documentfoundation.org/Grammar-checking-Using-LanguageTool-lexicons-with-Lightproof-new-possible-tp4022489p4022495.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

Re: [ANNOUNCE] Python 3.3 is now bundled with LibreOffice 4.0

[Németh László]

Hi Michael and all,

Many thanks for your great work! I have started to test and fix Lightproof
with Python 3.3, and I will post the results.

Regards,
László


2012/11/28 Olivier Hallot olivier.hal...@documentfoundation.org

 Although the fix for expat and element—tree is is removing dirty expat
 from solenv/, Lightproof is not operational. I did a clean dev-install and
 ./soffice console shows the issue.
 Olivier
 Em 27/11/2012 14:11, Michael Stahl mst...@redhat.com escreveu:


 with the commit 38a22a9026a3d8a67f3e16ec650960a10b527d25 Switch from
 python to python3 Python 3.3 is now bundled with LibreOffice when
 configured --enable-python=internal.

 with the commit 602b746330d21ae1b9c0fc60eb0980ed92cd5680 configure:
 switch system Python minimum to 3.3 the minimum version for a system
 Python (when using --enable-python=system) has been raised to 3.3;
 however for a transition period of a few releases it will still be
 possible to use a Python 2 version 2.6 or later, by explicitly setting
 PYTHON, PYTHON_CFLAGS, PYTHON_LIBS variables.

 there are currently no known issues with pyuno (remotely) and Python
 Script Provider when running on Python 3.

 there are still some bits of Python code that are not yet ported to run
 on Python 3, such as the email sending stuff in scripting/source/pyprov/
 and LightProof but hopefully we'll get that done before 4.0 release.

 thanks to Christian Lohmaier for his work to get internal python3
 packaged on Mac OS X, to Laszlo Nemeth for advice in porting the Python
 Script Provider extension, and to Xisco Fauli for porting the Python
 based Wizards.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Line height depending on characters in that line

[Németh László]

Hello,

Moreover, with register-true page layout, the result is terrible (empty
lines between the lines). Maybe modification of the font file is not
possible, because the formula editor depends from OpenSymbol. A proper
solution would be to add relative size support (like in the Heading styles)
to the character size of the default character style Bullets, and set it to
87,5%.

By the way, there are other problems with these no-name list styles, eg.
their missing localizations. It would be fine to change or add an option to
use named numbering/list styles with Numbering/List icons and automatic
list replacement instead of these awful no-name styles.

Best regards,
László



2012/11/20 Lubos Lunak l.lu...@suse.cz


  Hello,

  I'd need a little help from somebody who knows how exactly line height is
 computed.

  Specifically, create a new document, create a bullet list (2-3 items), and
 change it from bullets to 1. style (RMB-Bullets and
 numbering...-Numbering
 type - any of those). Doing this (visible when repeatedly hitting Ctrl+Z
 and
 Ctrl+Y) noticeably changes the height of all the lines. With MSWord there
 isn't such a big difference, leading to different formatting on .docx
 import
 in a specific bugreport I have.

  I have checked that this change is triggered by the bullet character
 being or
 not being present in the actual string representation of the line, so I
 assume that the bullet character from the OpenSymbol font is somehow higher
 than the rest, or that the font itself specifies this height. But I have no
 idea how this stuff works. What would be the proper way of fixing this?

 --
  Lubos Lunak
  l.lu...@suse.cz
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

LibreLogo

[Németh László]

Hi,

LibreLogo is a new experimental module of LibreOffice for a simple,
Logo-like programming environment in Writer: a lightweight wrapper – 1400
lines in Python/PyUNO – to the embedded Python of LibreOffice and a Writer
toolbar extension.

My LibreOffice conference presentation:
http://www.numbertext.org/logo/librelogo.pdf
Feedback from Cor Nouws:
http://cor4office.blogspot.nl/2012/11/what-arabic-turtle-and-google-have-to.html

Goals of LibreLogo:

Teaching of computing
• Programming (free, portable and modern native Logo alternative with
Python data structures)
• Word processors (text editing, image handling)
• Migration to free software (LibreOffice)

LibreOffice
• Simple programming interface for graphic design and DTP (for example, see
this B2 chess poster created in LibreOffice Writer for the upcoming
conference of Hungarian IT teachers:
http://www.numbertext.org/logo/hu/poszterek/sakk.pdf)

LibreOffice development
• Test bed for graphical features and PyUNO
• Attract more future GSoC etc. developers for LibreOffice (in Hungary, the
Logo programming contest has got 2500–3000 participants/year:
http://logo.inf.elte.hu/diagramlogo2.png).

Thanks to András Tímár, now it's possible to localize the English manual
and the commands/warning messages of the LibreLogo environment, too. I will
post a longer article about LibreLogo soon.

Best regards,
László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Please Add Barack Obama to Dictionary

[Németh László]

Hi,

System installed LibreOffice versions can use older American English
dictionaries. On Ubuntu, the system-wide en_US Hunspell dictionary
doesn't include the word “Obama”:

$ grep Obama /usr/share/hunspell/en_US*
$

But the system installed LibreOffice uses different (the newest)
American English dictionary on Ubuntu, so it works well (under my
system).

Other options: There is/was a bug with the configuration/usage of the
British and American hyphenation patterns, maybe this is a similar
configuration problem of the spelling dictionaries on your
system-installed LibreOffice. Please, check the language of the
document, and the following words in Writer in your LibreOffice
installation: color/colour to detect the British dictionary usage in
American English documents.
Check your private dictionaries for exceptions, too. (see Help F1,
Index: exceptions;user-defined dictionaries).

Best regards,
László


2012/10/26 Joel Madero jmadero@gmail.com:


 On Fri, Oct 26, 2012 at 3:06 AM, Németh László nem...@numbertext.org
 wrote:

 Hi All,

 The word “Obama” is included in the American and Canadian English
 dictionaries:

 $ grep Obama ~/libo/clone/dictionaries/en/en_*dic
 /home/laci/libo/clone/dictionaries/en/en_CA.dic:Obama/3
 /home/laci/libo/clone/dictionaries/en/en_US.dic:Obama/3

 Change the document language to English (USA) or English (Canada) in
 Options » Language Settings » Languages » Western to solve the
 reported problem. Thanks for your bug report, we will extend the
 British English dictionary – English (UK) – in the near future, too.


  Is this a new addition as I live in the USA and I am already set to English
 (USA). I never change this setting so it makes me wonder why the underline
 still :-/ The user who originally posted the bug to the thread also, from my
 understanding, has English (USA) setting.


 Regards,
 Joel
 --
 Joel Madero
 LibO QA Volunteer
 jmadero@gmail.com


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Please Add Barack Obama to Dictionary

[Németh László]

Hi All,

The word “Obama” is included in the American and Canadian English dictionaries:

$ grep Obama ~/libo/clone/dictionaries/en/en_*dic
/home/laci/libo/clone/dictionaries/en/en_CA.dic:Obama/3
/home/laci/libo/clone/dictionaries/en/en_US.dic:Obama/3

Change the document language to English (USA) or English (Canada) in
Options » Language Settings » Languages » Western to solve the
reported problem. Thanks for your bug report, we will extend the
British English dictionary – English (UK) – in the near future, too.

Best regards,
László

PS. For your information, here are the newer words from the American
English dictionary of Wordlist project (missing from LibreOffice yet):

Blu
Bluetooth
ECMAScript
FSF
Facebook
Gere
Netflix
Pleiades
Rhode
Roku
USB
Walmart
analyses
archaeology
begat
caddie
chateaux
cloverleaves
dialyses
draughtboard
eMusic
exabyte
eyeing
faggot
forego
foregoes
gigabit
gigawatt
glamour
hiccough
hiccoughs
hippy
hurrah
hurrahs
iPad
iPhone
magus
paralyses
petabyte
platys
plugin
plummer
plummest
polys
routeing
sequinned
sheikh
sheikhs
sicced
siccing
terabit
terahertz
velour
whiskys
zlotys


2012/10/25 Caolán McNamara caol...@redhat.com:
 On Tue, 2012-10-23 at 10:42 -0700, Joel Madero wrote:
 Hi All,
 Not sure who is responsible for dictionary additions but a user has
 pointed out that Mitt Romney's name is in our dictionary but Obama
 comes out underlined. This is probably no good and could be
 interpreted (incorrectly) as a subliminal message by our team ;)

 So..., our dictionary is derived from http://wordlist.sourceforge.net/

 and Obama was added ages ago to that
 http://sourceforge.net/tracker/index.php?func=detailaid=2779775group_id=10079atid=1014602
 so e.g. the system fedora en-US dictionary includes it due to that.

 What we really should do IMO is to try and resync our dictionary back to
 the upstream wordlist one, finding whatever differences have crept in,
 e.g. addition of LibreOffice and what not and if possible patch them
 in as separate patches, like we do for external libraries.

 As an aside, I think its worth noting that it can be advantageous for a
 spelling dictionary to *not* include every possible word in English.
 e.g. Calender is a real world in English
 http://en.wikipedia.org/wiki/Calender
 but its a super obscure technical thing, and 99% of the time its a
 misspelling of Calendar

 C.

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: spell checker issue

[Németh László]

Hi,

2012/10/25 Caolán McNamara caol...@redhat.com:
 On Mon, 2012-10-15 at 09:37 +0200, Németh László wrote:
 Hi,

 Adding a simple new item to the en_US.dic, like

 men's

 will extend the dictionary. The biggest plus in the American English
 dictionary of LibreOffice is the morphological data (also based on
 Kevin's data and maybe WordNet) for stemming and morphological
 generation in thesaurus suggestions, see the attached conversion
 script in https://issues.apache.org/ooo/show_bug.cgi?id=19563.

 So basically one attractive route to go would be to build our dictionary
 at LibreOffice build time ourselves from wordnet +
 custom-libreoffice-words patch + that script. Which would give us
 something we can easily sync whenever wordnet gets updated without
 losing the extra morphological data. Or is there any gotchas with doing
 that ?

Only a small part of Wordnet – the list of the irregular forms – used
by the script. But the thesaurus of LibreOffice is based on the full
Wordnet, so it would be fine to add the thesaurus generation to the
building process. We would be able to add some attractive thesaurus
improvements, too, like Unicode symbols as synonyms: eg. alpha - α,
skull - ☠, as in the Hungarian thesaurus.

Gotchas: there were some manual fixes (documented in the
README_en_US.txt) to handle Unicode apostrophes and ligatures.
Adding a small list with the most urgent words would be easier for me.

I also tried to find an old OpenOffice.org issue about the quality
analysis/extension of the (American) English dictionary, but I have
found only the
en-GB-oed dictionary for international organizations, see
https://issues.apache.org/ooo/show_bug.cgi?id=51093,
http://ftp.nluug.nl/office/openoffice/contrib/dictionaries/README_en_GB-oed.txt.

Best regards,
László



 C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: spell checker issue

[Németh László]

Hi,

Adding a simple new item to the en_US.dic, like

men's

will extend the dictionary. The biggest plus in the American English
dictionary of LibreOffice is the morphological data (also based on
Kevin's data and maybe WordNet) for stemming and morphological
generation in thesaurus suggestions, see the attached conversion
script in https://issues.apache.org/ooo/show_bug.cgi?id=19563.

By the way, Firefox or Google Chrome
(http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/hunspell_dictionaries/en_US.dic_delta?revision=138928view=markup)
have got some new words, too, as patches.

Regards,
László

2012/10/11 Caolán McNamara caol...@redhat.com:
 On Sun, 2012-09-30 at 12:47 -0700, Steven Howe wrote:
 Who deals with spell checker dictionary issues?

 I'm using the work  men's ; the spell checker thinks this is wrong,
 although spell checker for gmail does not. I've visited webster's
 dictionary online. men's appears to be the correct spelling.

 English - US, right ? Best in general to submit a bug about these
 things. But it does bring up the general case as to what's the
 canonical upstream for the English dictionaries.

 e.g. for Fedora I consider Kevin's wordlist at
 http://wordlist.sourceforge.net/ as the upstream of the en-US dictionary
 and in that light I've submitted
 https://sourceforge.net/tracker/?func=detailaid=3576342group_id=10079atid=1014602
 which would allow men's, women's and other possessive of irregular
 plural nouns.

 I'm not entirely sure of the provenance of the en-US dictionaries we
 have in LibreOffice. I mean, IIRC they are derived ultimately from
 Kevin's list, but I don't know if they are resynced occasionally or if
 Nemeth is maintaining them in some source format somewhere else. Or if
 they have accidentally forked themselves over time.

 They definitely appear to be at least affix compressed or something into
 something sufficiently unreadable I can't trivially see the right way to
 add men's, women's to the copies we have in our tree :-)

 C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] fdo#54843 righthyphenmin fix (patch by Steven Dickson)

[Németh László]

Hi,

Additions to the previous automatic message:

I have checked the result of this 3-line hyphenation patch (sent by
Steven Dickson)

– on 2 million Hungarian words (there is no difference in the
hyphenation, because it only affects the hyphenation of the words with
3-byte or longer UTF-8 multibyte characters),

– on the Telugu test document attached to the fdo#54843
(https://bugs.freedesktop.org/show_bug.cgi?id=54843) (it fixes its
hyphenation problems).

Best regards,
László

2012/9/13 Németh László (via Code Review) ger...@gerrit.libreoffice.org:
 Hi,

 I have submitted a patch for review:

 https://gerrit.libreoffice.org/606

 To pull it, you can do:

 git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/06/606/1

 fdo#54843 righthyphenmin fix (patch by Steven Dickson)

 Change-Id: I42747dffef099f3806178af76e20335f5f033379
 ---
 A hyphen/hyphen-rhmin.patch
 M hyphen/makefile.mk
 2 files changed, 29 insertions(+), 1 deletion(-)


 --
 To view, visit https://gerrit.libreoffice.org/606
 To unsubscribe, visit https://gerrit.libreoffice.org/settings

 Gerrit-MessageType: newchange
 Gerrit-Change-Id: I42747dffef099f3806178af76e20335f5f033379
 Gerrit-PatchSet: 1
 Gerrit-Project: core
 Gerrit-Branch: master
 Gerrit-Owner: Németh László nem...@numbertext.org

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED] fdo#46542, fdo#46559 (small fixes for English grammar checking)

[Németh László]

Hi,

Many thanks, also for the correction.

László

2012/8/27 Andras Timar tima...@gmail.com

 Hi,

 2012/8/26 Németh László nem...@numbertext.org:
  Hi,
 
  The attached 2-line libreoffice-3-6 patch adds two reported words to the
  exceptions of the English grammar checking.
  (It has already been fixed in the master, but with a greater,
 restructured
  code and other improvements.)

 It was fdo#46549, not fdo#46559. I pushed it to libreoffice-3-6 with
 corrected commit message.

 Thanks,
 Andras

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] fdo#46542, fdo#46559 (small fixes for English grammar checking)

[Németh László]

Hi,

The attached 2-line libreoffice-3-6 patch adds two reported words to the
exceptions of the English grammar checking.
(It has already been fixed in the master, but with a greater, restructured
code and other improvements.)

Best regards,
László


0001-fdo-46542-fdo-46559-small-fixes-for-English-grammar-.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH-3-5] fdo#35270 - kill first-use grammar checker freeze ...

[Németh László]

Hi,

First of all, many thanks for the fix to Daniel and Michael. (I
haven't checked yet, but the patch probably solved the similar problem
of the Lightproof editor.)

Indeed, there are some important philosophical differences in level of
the software and also level of its language modules.

I am one of those frustrated users, who are very skeptic about
full-featured grammar checking, see my article here:
http://libreoffice.hu/2011/12/08/grammar-checking-in-libreoffice/. In
the article I haven't mentioned the user-related problem of the
computer aided grammar checking, the limited understanding of grammar
errors and their descriptions. Difficult orthographic rules, moreover
linguicism (linguistic discrimination) combined with the computer may
have very frustrating results. If the (word-level) spell checker
accepts the most intrusive words (yes, it accepts them, but it doesn't
suggest them), we don't have to frustrate users with potentially
dubious or dummy default grammar checker warnings. Less (false
positives) are more. (See the fixes of the false alarms in the
simplest a/an article checking.) [A real life story about orthography
and spell checking: Hungarian dictionary of Hunspell has got the
capability to check the difficult 6-3 rule of Hungarian word
compounding. It seems, this strict rule will be removed from Hungarian
orthography (and from LibreOffice), because it was too difficult and
sometimes controversial.]

About the software: Lightproof is a lightweight proofreader. Instead
of extra libraries or dictionaries, it uses Python for a glue language
between UNO components/language resources of LibreOffice, also fast C
regex library of Python, and for parsing logical expressions in
grammar checking rules (these expressions with arbitrary user
functions give the requested flexibility in the conditions of the
rules). For example, recent Lightproof modules uses Hunspell for spell
checking and morphological analysis (in fact, UNO solution is not
depend from Hunspell: the function spell() of Lightproof will use
Voikko in a possible Finnish module, or the system spell checker on
Mac OS X), Calc for measurement conversion and rounding, moreover, the
Hungarian Lightproof module uses Numbertext Calc function extension to
check number and number name integrity in money amounts.

About the possible integration: For the easiest integration of the
result of the different grammar checker developments, in the Summer we
(Daniel Korostil GSoC student and me) will check a simple more
grammar checking (LanguageTool, AtD) option in LibreOffice (now only
Lightproof) grammar checker settings. (Using LanguageTool via UNO by
Lightproof could be a common/simplier interface for the different
grammar checkers.)

Best regards,
László

2012/5/21 Michael Meeks michael.me...@suse.com:
 Hi Daniel,

 On Sun, 2012-05-20 at 19:11 +0200, Daniel Naber wrote:
 now that this is fixed I searched the archives for the reason LanguageTool
 is not enabled by default. The slowness you talk about in [1] does not
 sound like general Java overhead, it sounds like exactly the issue that has
 just been fixed.

        Indeed ! :-) good to have that nailed - thank you.

  Were there other reasons LanguageTool is disabled by default? Should this
 decision maybe re-evaluated now?

        So - there is/was of course, also the Java issue - that the JRE is not
 present on many machines, whereas we bundle our own python runtime. That
 can lead either to the horrible user-experience of complaining about
 missing JRE's on first-start, and/or simply silently disabling those
 components, or worse moaning about JREs as the user types which is not
 that pleasant either. The other issue that windows Java downloads were
 advertising the competing openoffice project in the past seems also to
 be fixed now.

        I guess many Linux distribution (where Java is ubiquitous) ship
 languagetool, though no doubt having lightproof also enabled by default
 presents some issues there. There is a minor licensing issue around the
 MPL vs. LGPL.

        Personally, I'm looking for a good, consistent out-of-box experience,
 and (given the size of our download) am not really over-eager about
 packaging / bundling an OpenJDK for windows.

        Beyond that - I've no idea :-) presumably there are philosophical
 differences between lightproof and languagetool that I'm not clued-up
 on. It'd be interesting to hear what Laszlo  you think about it, and
 other people's views on the list ...

        What hope is there for sharing work, rules, etc. ? could we (for
 example) have authoritative languagetool Java code, and use one of those
 java2py things to compile it to python ? [ crazy thoughts of course ].
 Would that offend the minimal modus operandi of lightproof ? could that
 light mode be made an option ?

        Thoughts on clever technical solutions much appreciated :-)

        Thanks !

                Michael.

 --
 michael.me...@suse.com  , Pseudo Engineer, itinerant 

Re: Lightproof easyhack

[Németh László]

Hi,

Thanks for the eligible patch. I have fixed some rules, using the
Lightproof rule editor
(http://extensions.libreoffice.org/extension-center/lightproof-editor),
see http://www.numbertext.org/tmp/ukdat.odt.
With a minor extension we will be able to add basic Ukrainian
typo/grammar checking support to LibreOffice.

Best regards,
László

2012/4/13 Коростіль Данило ted.korosti...@gmail.com:
 Hello gentlemen,

 Sorry again for delay. I was really busy because of my defeating of
 pre-thesis report.

 So I've done some initial job that you can estimate. Currently I'm in
 process of improving and porting all Ukrainian rules from LT project.

 The patch attached. If I'm doing something wrong, just inform me. Also I'm
 working at github:
 https://github.com/korostil/lightproof_uk

 Thank you, sirs!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Adding Extension for Experimental Thai Spelling

[Németh László]

Hi,

2012/2/17 Richard Wordingham richard.wording...@ntlworld.com:
 It's a vast improvement - it gives LibreOffice a real Thai
 spell-checker.  Thank you.  I have one worry for Siamese - Németh László
 suggested that there might be a licensing issue back in
 http://openoffice.2283327.n4.nabble.com/Thai-line-breaking-td2791315.html .

There is no problem with the license of the ICU. I'm also very glad of the fix.

Regards,
László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Grammar checker development for LibreOffice

[Németh László]

Hi Cor,

Thanks for your feedback. Last year I was involved in Dutch language
developments (I worked with the Dutch OpenTaal Foundation to improve
Dutch spell checking, sponsored by the Dutch Language Union and the
foundation), but I have known the active and excellent open source
Dutch language developments much longer.

I strongly think, the default grammar checking of LibreOffice have to
prefer the minimalistic, non-intrusive sentence checking/proofreading.
With the Lightproof editor extension, it is not so complicated to
develop these basic Dutch/etc. sentence checking rules, based on the
English ones.

To give the best for other (extra/optional) requirements (writing aids
for beginners and uncomplaining users) is to integrate the rule based
Dutch grammar checking of LanguageTool (developed by Ruud Baars) with
future statistical based Dutch developments of After the Deadline
grammar checker, and adding an option (ie. an After the Deadline
client) to the suggested Lightproof based Dutch grammar checker of
LibreOffice to use it. This optional/extra server based grammar
checking  would be the ideal solution, because the statistical methods
could be quite resource intensive, see 1 GB minimal memory requirement
of contextual (only English) spell checking of MS Office 2010.

Best regards,
László

2012/2/13 Cor Nouws oo...@nouenoff.nl:
 Hi Németh,

 Németh László wrote (13-02-12 16:20)

 Lightproof (from “lightweight proofreader”) is a Python grammar
 checker framework for LibreOffice. Default English, Hungarian and
 [...]


 Thanks for the info and the checker!
 We had some people before in Netherlands community active with spell
 checking and such. See if they are interested. Would be great if some work
 on Dutch grammar checking could be done.

 Cheers,

 --
  - Cor
  - http://nl.libreoffice.org

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Grammar checker development for LibreOffice

[Németh László]

Hi,

Lightproof (from “lightweight proofreader”) is a Python grammar
checker framework for LibreOffice. Default English, Hungarian and
Russian grammar checkers of LibreOffice 3.5 are based on Lightproof
(also the French Grammalecte:
http://extensions.libreoffice.org/extension-center/grammalecte).

Here is an introduction about the concept of Lightproof and grammar
checker development for LibreOffice:
http://libreoffice.hu/2011/12/08/grammar-checking-in-libreoffice/

Source: git://anongit.freedesktop.org/libreoffice/lightproof or see
http://cgit.freedesktop.org/libreoffice/lightproof/tree/

Cloning:

git clone git://anongit.freedesktop.org/libreoffice/lightproof

Compiling of the English grammar checker extension:

python make.py src/en/en.cfg

There is also a new editor extension to speed up the rule development
(it works without the source code, too):

http://extensions.libreoffice.org/extension-center/lightproof-editor

Best regards,
László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] ecofont

[Németh László]

Hi,

LibreOffice has already supported a similar solution to save more ink
with the following improvements:

• Scalable ink saving (20-90%, or arbitrary values);
• extreme ink saving (96%) with excellent readability;
• better layout on low resolution (1200 dpi): instead of ugly spotted
letters it uses low level methods of printers to provide consistent
typefaces;
• it works with all fonts.

Usage: choose Grey 80%...Grey 10% colors for your text (you can add
more colors to the palette:
http://wiki.services.openoffice.org/wiki/Documentation/OOoAuthors_User_Manual/Draw_Guide/Color_palette).
For extreme ink saving, set outlined character formatting (=~60% ink
saving) and combine with Gray 90% text color.

Best regards,
László



2011/12/9 810d4rk 810d...@gmail.com:
 Looking forward, unless EcoFont has a patent on swiss-cheesing fonts,
 one could potentially make swiss-cheese versions of the existing fonts
 in LO.

 That would be very good to have on LO for anyone that wants to save
 ink and use whatever font they like, but will be not be part of
 version 3.5?

 As for merely saving toner/ink when printing, it appears that someone
 did some testing and found that some fonts (e.g. Century Gothic) will
 save more ink per word than the EcoFont.
 http://www.treehugger.com/sustainable-product-design/century-gothic-saves-more-ink-than-ecofont.html

 The ecofont website has tells the advantages of their fonts:
 http://www.ecofont.com/en/products/green/printing/saving-printing-costs-and-eco-friendly/why-ecofont-saves-more-ink-than-century-gothic.html



 --
 Thanks
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] how to print into .ps

[Németh László]

Hi,

Maybe you can change the printer language to Postscript on the Device
page of the Printer settings in the Printing dialog (it works for me
on Linux).

By the way, there is an important difference within PDF printing and
PDF exporting. PDF printing supports EPS embedding (fortunately, like
the old default PostScript printing),
but PDF exports have contained only the bitmap preview of the original
EPS images, yet. Is there any reason to limit EPS embedding to PDF
printing, eg. PDF compatibility or different PDF creation mechanisms?

Best regards,
László


2011/11/22 Petr Mladek pmla...@suse.cz:
 Hi,

 if you select Print to File check box in the Print dialog, it
 generates .pdf file.

 IMHO, if you debug printing bugs, it would be great to see the .ps file
 that is send to the printer. Is there any easy way how to get it?


 Best Regards,
 Petr

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED] Display resolution in PPI with the original size on Picture/Crop (in Writer)

[Németh László]

Hi,

Many thanks for your help,
László

2011/10/29 Andras Timar tima...@gmail.com:
 2011/10/28 Németh László nem...@numbertext.org:
 Hi,

 This patch adds PPI resolution to the default image size data in the
 Picture dialog (only for bitmap images), see the attached screenshot.


 Pushed with some changes in order to make the new string localizable.
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=adb8868edaebb372a54140f84bf85ac9eef37918

 Thanks!

 Andras

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED] hyphenation fixes

[Németh László]

Hi Caolán,

Many thanks for it.

Laci

PS. It seems, Mozilla has integrated the Hyphen library to implement
CSS3 hyphenation in Firefox
(https://developer.mozilla.org/en/CSS/hyphens), so I will check it,
too.


2011/10/24 Caolán McNamara caol...@redhat.com:
 On Mon, 2011-10-17 at 15:18 +0200, Németh László wrote:
 I'm sorry, here are the missing patches. Many thanks for the integration.

 ok, pushed all these now.

 C.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] Display resolution in PPI with the original size on Picture/Crop (in Writer)

[Németh László]

Fernand,

Thanks. LibreOffice applies a limit (paragraph or frame width) to the
loaded image (this doesn't modify the quality of the picture), and it
has a PDF option to resize all pictures (eg. 96 DPI for web/monitors,
300 DPI for printing). Could you specify your request? If I right
understand, it would be fine to add a new general treat as ... ppi
option for the loaded pictures, because this could simplify the image
resizing (eg. an UI equivalent of the following shell script: mkdir
output; for i in *.jpg; do convert -units PixelsPerInch -density 300
$i output/$i; done)? For pictures with high resolution (digital
photos) this would be not enough, regarding the first limitation (but
if you click on the Original size button, LibreOffice will set the
resolution/size specified in the image file). You are right, we need a
more comfortable picture handling in Writer, eg. it would be fine to
use the new visual cropping (Scissors icon) of Draw in Writer, too.

Best regards,
László

2011/10/28 Fernand Vanrie s...@pmgroup.be:
 László and all developers involved,
 Fine, it is a first step in better handling of images. But as I mentioded
 before, having the PPI out of the image file is a wrong concept. The
 needed/wanted PPI must been stored in the document. The image sizes must
 been calculated according to the pixels in the image and the PPI stored (as
 a printer intention) in the Document.

 Greetz

 Fernand

 Hi,

 This patch adds PPI resolution to the default image size data in the
 Picture dialog (only for bitmap images), see the attached screenshot.

 Explanation: LibreOffice supports explicite resolutions of JPEG/PNG
 picture formats to set default image size, but this important data is
 missing from the UI, so we cannot verify the picture quality.

 Best regards,
 László

 PS. There are some old bugs in the default image handling in
 LibreOffice, see the attached test file, but the most important
 picture format (JPEG with equal explicite x-y resolutions) works well
 (except the rounding error in the percent data, see 101% on the
 screenshot). This patch helps to handle these problems, too.


 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice



 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][PATCH] for hyphenation of words with hyphen or with leading and trailing numbers

[Németh László]

Hi,

2011/10/17 Caolán McNamara caol...@redhat.com:
 On Fri, 2011-10-07 at 17:31 +0200, Németh László wrote:
 Hi,

 I have attached two patches for the Hyphen library and the English
 hyphenation patterns, also a test document.

I'm sorry again, later I have found the conflict within the different
hyphenation mechanisms (dictionary based and the default hyphenation
of words with hyphens), also an older bug with the output hyphenation
vector, so I had to improve the patch to solve these problems, too.

 Pushed now, thanks for this. Though IIRC you've got commit access if you
 want to push similar yourself direct ?

Thanks, I would like to do that in the near future.

Regards,
Laci



 C.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][~PATCH] British hyphenation of American English texts

[Németh László]

Hi,

2011/10/17 Caolán McNamara caol...@redhat.com:
 On Fri, 2011-10-07 at 17:41 +0200, Németh László wrote:
 British and American English are different in their hyphenation (eg.
 pleas•ure and plea•sure), but OpenOffice.org and LibreOffice use also
 British hyphenation for American English texts. The attached patch
 change dictionaries.xcu to fix the problem, but it seems, this is not
 enough for the fix.

 pushed this anyway to document the desired outcome.

Thanks for it,
Laci


 C.



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] hyphenation fixes

[Németh László]

Hi,

I have attached new patches for the Hyphen library and Hungarian
hyphenation patterns, and the old one for English dictionaries and the
test file from my previous letter.

I have found and fixed a new hyphenation problem at the hyphen
character. OpenOffice.org/LibreOffice can hyphenate the words with
hyphens and en-dashes without explicite hyphenation patterns. From
OpenOffice.org 3.3, the hyphenator gets the hyphens, too (related to a
spell check fix). This is useful to set bigger hyphenation distances
from the hyphens, but the implicite hyphenation of hyphens and the
hyphenation by Hyphen library have a conflict, and often LibreOffice
missed the hyphenation at hyphens, depending from the position of the
compound word in the line. The new Hyphen uses the following implicite
hyphenation settings to fix this problem for all languages:

1-1/=,1,1
NEXTLEVEL

So the hyphenation is enabled at hyphens by also the Hyphen library,
removing the original hyphen (using only the automatic hyphen added by
LibreOffice). Unfortunatelly, this method is not suitable for
en-dashes (eg. in Hungarian texts), but at least, with the new Hyphen
LibreOffice doesn't hyphenate the en-dash with a plus hyphen (–-).

PS.: The new Hyphen 2.8.3:
https://sourceforge.net/projects/hunspell/files/Hyphen/2.8/

Regards,
Laci
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [~PATCH] British hyphenation of American English texts

[Németh László]

British and American English are different in their hyphenation (eg.
pleas•ure and plea•sure), but OpenOffice.org and LibreOffice use also
British hyphenation for American English texts. The attached patch
change dictionaries.xcu to fix the problem, but it seems, this is not
enough for the fix.

If I right remember, I have reported this problem (maybe newly
introduced in OOo 3.3) for OOo, thinking that this problem is only a
configuration problem. Maybe a quick solution is to separate en_US and
en_GB dictionary extensions.

Best regards,
Laci
From e50dde276cf2c963859c5a00b8cf4ae016eac0fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?L=C3=A1szl=C3=B3=20N=C3=A9meth?= nem...@numbertext.org
Date: Fri, 7 Oct 2011 16:43:54 +0200
Subject: [PATCH] Add American English hyphenation for en_US and en-PH instead of British

---
 dictionaries/en/dictionaries.xcu |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/dictionaries/en/dictionaries.xcu b/dictionaries/en/dictionaries.xcu
index 4746419..81e7142 100644
--- a/dictionaries/en/dictionaries.xcu
+++ b/dictionaries/en/dictionaries.xcu
@@ -65,7 +65,18 @@
 valueDICT_HYPH/value
 /prop
 prop oor:name=Locales oor:type=oor:string-list
-valueen-GB en-US en-PH en-ZA en-NA en-ZW en-AU en-CA en-IE en-IN en-BZ en-BS en-GH en-JM en-NZ en-TT/value
+valueen-GB en-ZA en-NA en-ZW en-AU en-CA en-IE en-IN en-BZ en-BS en-GH en-JM en-NZ en-TT/value
+/prop
+/node
+node oor:name=HyphDic_en-US oor:op=fuse
+prop oor:name=Locations oor:type=oor:string-list
+value%origin%/hyph_en_US.dic/value
+/prop
+prop oor:name=Format oor:type=xs:string
+valueDICT_HYPH/value
+/prop
+prop oor:name=Locales oor:type=oor:string-list
+valueen-US en-PH/value
 /prop
 /node
 node oor:name=ThesDic_en-US oor:op=fuse
-- 
1.7.4.1

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] for hyphenation of words with hyphen or with leading and trailing numbers

[Németh László]

Hi,

I have attached two patches for the Hyphen library and the English
hyphenation patterns, also a test document.
(The first test is not yet resolved, see my next letter.)

The Hyphen patch fixes the bad hyphenation of words with hyphens (a
new bug of OpenOffice.org) and apostrophes for all languages. Old
partial (string replacement at hyphenation) of LibreOffice's English
hyphenation patterns or full solutions (explicite NOHYPHEN attribute)
are unnecessary, removed by the another patch.

Best regards,
Laci
From 722c5dc25ad32a7878f7b1d00f2864789c4081d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?L=C3=A1szl=C3=B3=20N=C3=A9meth?= nem...@numbertext.org
Date: Fri, 7 Oct 2011 16:03:06 +0200
Subject: [PATCH] Fixes of Hyphen 2.8.2 (words with hyphens, numbers and use min. def. hyphenmin)

---
 hyphen/hyphen-2.7.1-2.8.2.patch |  325 +++
 hyphen/makefile.mk  |3 +-
 2 files changed, 327 insertions(+), 1 deletions(-)
 create mode 100644 hyphen/hyphen-2.7.1-2.8.2.patch

diff --git a/hyphen/hyphen-2.7.1-2.8.2.patch b/hyphen/hyphen-2.7.1-2.8.2.patch
new file mode 100644
index 000..912fba7
--- /dev/null
+++ b/hyphen/hyphen-2.7.1-2.8.2.patch
@@ -0,0 +1,325 @@
+--- misc/build/hyphen-2.7.1/hyphen.c.old	2011-10-07 15:51:25.883686906 +0200
 misc/build/hyphen-2.7.1/hyphen.c	2011-10-07 15:51:59.363686900 +0200
+@@ -242,99 +242,45 @@
+ }
+ #endif
+ 
+-HyphenDict *
+-hnj_hyphen_load (const char *fn)
+-{
+-  HyphenDict *dict[2];
+-  HashTab *hashtab;
+-  FILE *f;
+-  char buf[MAX_CHARS];
++void hnj_hyphen_load_line(char * buf, HyphenDict * dict, HashTab * hashtab) {
++  int i, j;
+   char word[MAX_CHARS];
+   char pattern[MAX_CHARS];
+   char * repl;
+   signed char replindex;
+   signed char replcut;
+-  int state_num = 0, last_state;
+-  int i, j, k;
++  int state_num = 0;
++  int last_state;
+   char ch;
+   int found;
+-  HashEntry *e;
+-  int nextlevel = 0;
+-
+-  f = fopen (fn, r);
+-  if (f == NULL)
+-return NULL;
+ 
+-// loading one or two dictionaries (separated by NEXTLEVEL keyword)
+-for (k = 0; k == 0 || (k == 1  nextlevel); k++) { 
+-  hashtab = hnj_hash_new ();
+-#ifdef VERBOSE
+-  global = hashtab;
+-#endif
+-  hnj_hash_insert (hashtab, , 0);
+-  dict[k] = hnj_malloc (sizeof(HyphenDict));
+-  dict[k]-num_states = 1;
+-  dict[k]-states = hnj_malloc (sizeof(HyphenState));
+-  dict[k]-states[0].match = NULL;
+-  dict[k]-states[0].repl = NULL;
+-  dict[k]-states[0].fallback_state = -1;
+-  dict[k]-states[0].num_trans = 0;
+-  dict[k]-states[0].trans = NULL;
+-  dict[k]-nextlevel = NULL;
+-  dict[k]-lhmin = 0;
+-  dict[k]-rhmin = 0;
+-  dict[k]-clhmin = 0;
+-  dict[k]-crhmin = 0;
+-  dict[k]-nohyphen = NULL;
+-  dict[k]-nohyphenl = 0;
+-
+-  /* read in character set info */
+-  if (k == 0) {
+-for (i=0;iMAX_NAME;i++) dict[k]-cset[i]= 0;
+-fgets(dict[k]-cset,  sizeof(dict[k]-cset),f);
+-for (i=0;iMAX_NAME;i++)
+-  if ((dict[k]-cset[i] == '\r') || (dict[k]-cset[i] == '\n'))
+-dict[k]-cset[i] = 0;
+-dict[k]-utf8 = (strcmp(dict[k]-cset, UTF-8) == 0);
+-  } else {
+-strcpy(dict[k]-cset, dict[0]-cset);
+-dict[k]-utf8 = dict[0]-utf8;
+-  }
+-
+-  while (fgets (buf, sizeof(buf), f) != NULL)
+-{
+-  if (buf[0] != '%')
+-	{
+-	  if (strncmp(buf, NEXTLEVEL, 9) == 0) {
+-	nextlevel = 1;
+-	break;
+-	  } else if (strncmp(buf, LEFTHYPHENMIN, 13) == 0) {
+-	dict[k]-lhmin = atoi(buf + 13);
+-	continue;
++	  if (strncmp(buf, LEFTHYPHENMIN, 13) == 0) {
++	dict-lhmin = atoi(buf + 13);
++	return;
+ 	  } else if (strncmp(buf, RIGHTHYPHENMIN, 14) == 0) {
+-	dict[k]-rhmin = atoi(buf + 14);
+-	continue;
++	dict-rhmin = atoi(buf + 14);
++	return;
+ 	  } else if (strncmp(buf, COMPOUNDLEFTHYPHENMIN, 21) == 0) {
+-	dict[k]-clhmin = atoi(buf + 21);
+-	continue;
++	dict-clhmin = atoi(buf + 21);
++	return;
+ 	  } else if (strncmp(buf, COMPOUNDRIGHTHYPHENMIN, 22) == 0) {
+-	dict[k]-crhmin = atoi(buf + 22);
+-	continue;
++	dict-crhmin = atoi(buf + 22);
++	return;
+ 	  } else if (strncmp(buf, NOHYPHEN, 8) == 0) {
+ 	char * space = buf + 8;
+ 	while (*space != '\0'  (*space == ' ' || *space == '\t')) space++;
+-	if (*buf != '\0') dict[k]-nohyphen = hnj_strdup(space);
+-	if (dict[k]-nohyphen) {
+-	char * nhe = dict[k]-nohyphen + strlen(dict[k]-nohyphen) - 1;
++	if (*buf != '\0') dict-nohyphen = hnj_strdup(space);
++	if (dict-nohyphen) {
++	char * nhe = dict-nohyphen + strlen(dict-nohyphen) - 1;
+ 	*nhe = 0;
+-	for (nhe = nhe - 1; nhe  dict[k]-nohyphen; nhe--) {
++	for (nhe = nhe - 1; nhe  dict-nohyphen; nhe--) {
+ 	if (*nhe == ',') {
+-	dict[k]-nohyphenl++;
++	dict-nohyphenl++;
+ 	*nhe = 0;
+ 	}
+ 	}
+ 	}
+-	continue;
++	return;
+ 	  } 
+ 	  j = 0;
+ 	  pattern[j] = '0';
+@@ -379,7 +325,7 @@
+   } 

Re: [Libreoffice] [PUSHED] CONVERT_ADD() fixes

[Németh László]

Hi András,

Many thanks for your help. If you don't bother, I send a new patch (1
line) to fix the sometimes bad capitalization in non-standard
hyphenation (a few years old, recently recognized bug from me):

http://www.numbertext.org/tmp/hyphencap.patch

A test file with some bad Hungarian hyphenation (ÖCs-csük, ÖSz-sze
instead of Öcs-csük, Ösz-sze): http://www.numbertext.org/tmp/ccs.odt

Thanks,
László


2011/7/7 Andras Timar tima...@gmail.com:
 Hi Laci,

 2011/7/7 Németh László nem...@numbertext.org:
 Hi,

 Could you integrate this patch to fix some measurement conversion
 factors of Calc?

 http://www.numbertext.org/tmp/gallon.patch

 I pushed this to master. Thanks for the patch.

 Cheers,
 Andras

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] CONVERT_ADD() fixes

[Németh László]

Hi,

Could you integrate this patch to fix some measurement conversion
factors of Calc?

http://www.numbertext.org/tmp/gallon.patch

Testing:

1 gallon is exactly 3.785411784 liter.
1 imperial gallon is exactly 4.54609 liter.

$ for i in 1 4 8 16 128 256 768 '(1/42)'; do echo 1/(3.785411784/$i)
| bc -liq; done
1/(3.785411784/1)
.26417205235814841537 # 1 liter in gallons
1/(3.785411784/4)
1.05668820943259366151 # ~ in quarts
1/(3.785411784/8)
2.11337641886518732303 # ~ in pints
1/(3.785411784/16)
4.22675283773037464607 # ~ in cups
1/(3.785411784/128)
33.81402270184299716862 # ~ in ounces
1/(3.785411784/256)
67.62804540368599433725 # ~ in tablespoons
1/(3.785411784/768)
202.88413621105798301176 # ~ in teaspoons
1/(3.785411784/(1/42))
.00628981077043210512 # ~ in barrels

$ for i in 1 4; do echo 1/(4.54609/$i) | bc -liq; done
1/(4.54609/1)
.21996924829908778752 # 1 liter in imperial gallons
1/(4.54609/4)
.87987699319635115010 # ~ in imperial quarts

Thanks in advance,
László
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] external LinLibertineG not available

[Németh László]

Hi,

Many thanks for your kind words in the name of Linux
Libertine/Biolinum and Graphite developers, too. There are some quite
exciting developments from these area. Eg. improved and extended font
family of Linux Libertine: new bold variant (the old one is renamed to
semi-bold); Linux Libertine Display, a size variant for greater point
sizes, see http://www.linuxlibertine.org/uploads/media/2011-05-PR-V5.0.0_02.pdf,
also the upcoming Graphite 2 integration for better performance. I
will convert the new Linux Libertine and Biolinum fonts to Graphite
now with combining diacritics (a basic need of several languages and
scientific/linguistic usage), and with some extra functions, too.
There are also a lot of other tasks to improve LibreOffice DTP, and we
have a big loss, Keith Stribley (see
http://ultimategerardm.blogspot.com/2011/02/in-memoriam-keith-stribley.html).
I hope, we will be able to continue his work to develop a professional
layout engine for LibreOffice with excellent (and default)
typographical facilities.

Best regards,
László

2011/6/25 aqualung xfekdcugj...@mailinator.com:
 Apologies for posting to the developers' list but I just wanted to express a
 big thank you to the creator(s) of the wonderful Linux Libertine G and Linux
 Biolinum G!

 These fonts, with their many ligatures and other special characters and
 combinations, bring some of the delight back that the typesetters of old
 must have experienced when choosing from their palette of lead types.

 I am puzzled that this achievement has not been recognized with a major
 typography award yet, or perhaps they are just too modest to post it on
 their website.

 --
 View this message in context: 
 http://nabble.documentfoundation.org/external-LinLibertineG-not-available-tp3104795p3107029.html
 Sent from the Dev mailing list archive at Nabble.com.
 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] external LinLibertineG not available

[Németh László]

Hi,

I'm very sorry the problem, it was not intended. (In fact, I paid also
the next month for the domain, but my hosting provider/registrator
forgot to renewal the domain or inform me about the expiration. I
hope, it will be fixed soon, especially because I plan to release a
new version with a lot of important improvement (eg. combining
diacritics).

Temporarily here is the package:

http://www.math.u-szeged.hu/~bognarv/881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

Thanks for your mail,
László

2011/6/24 Christian Lippka c...@lippka.com:
 I'm doing a windows build, fetching

 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

 failed, looks like domain www.numbertext.org is expired.

 Christian.

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] external LinLibertineG not available

[Németh László]

Hi,

The problem was fixed by my provider.

Regards,
László

2011/6/24 Németh László nemeth.la...@gmail.com:
 Hi,

 I'm very sorry the problem, it was not intended. (In fact, I paid also
 the next month for the domain, but my hosting provider/registrator
 forgot to renewal the domain or inform me about the expiration. I
 hope, it will be fixed soon, especially because I plan to release a
 new version with a lot of important improvement (eg. combining
 diacritics).

 Temporarily here is the package:

 http://www.math.u-szeged.hu/~bognarv/881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

 Thanks for your mail,
 László

 2011/6/24 Christian Lippka c...@lippka.com:
 I'm doing a windows build, fetching

 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

 failed, looks like domain www.numbertext.org is expired.

 Christian.

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice