This is a feed aggregator that collects what LibreOffice and Document Foundation contributors are writing in their respective blogs.
To have your blog added to this aggregator, please mail the website@global.libreoffice.org mailinglist or file a ticket in Redmine.
I worked on an issue that a contributor to the LibreOffice extensions and templates website (https://extensions.libreoffice.org) forwarded to me. I had to investigate the source code for the connection to the uploaded documentation file for an extension and submitted a fix for this issue today the TDF github repository. The fix will be available within the next run of buildout for the LibreOffice extensions and templates website.
(via Sweet5hark)
I arrived home from Hamburg yesterday where I participated in the LibreOffice hackfest over the weekend as a mentor. First, thanks to The Document Foundation — and all the donors for funding Collabora to make this possible.
There were a few topics I mentored:
Patrick was interested fixing tdf#116486, which required some background knowledge on the Writer document model and layout, so we explored the relevant details together towards providing an actual patch for the bug.
Nithin wanted to fix tdf#112384, which turned out to be an ideal task for a hackfest. On one hand, the scope is limited so that you can implement this mini-feature over a weekened. On the other hand, it required touching various parts of Writer (UI, document model, UNO API, ODF filter), so it allowed seeing the process of adding a new feature. The patch is merged to master.
Linus looked for a task that is relatively easy, still useful, we looked at tdf#42949, and he identified and removed a number of unused includes himself. This should especially help with slow incremental builds. Again, the patch is already in master.
Zdeněk (raal) wanted to write a uitest for tdf#106280 so we were figuring out together how to select images from pyuno and how to avoid using graphic URLs in uitests in general.
The full list of achievements is on the wiki, if you were at the hackfest and you did not contribute to that section, please write a line about what did you hack on. :-)
Finally, thanks for the organizers and the sponsors of the hackfest, it was a really great event!
Berlin, 5. april 2018 – TDF (The Document Foundation) objavlja izid LibreOffice 6.0.3, četrte iz družine izdaj LibreOffice 6 z okoli 70 odpravljenimi hrošči. LibreOffice 6.0.3 je na skrajnem robu glede funkcionalnosti in je kot tak namenjen tehnološkim navdušencem, zgodnjim preizkuševalcem in zahtevnejšim uporabnikom, medtem ko je 5.4.6 namenjena osrednjim uporabnikom ter poslovnim okoljem. It is my third post about implementing HSQL migration inside odb documents in connection with a TDF tender. The previous posts were about creating the schema import, and the import of binary data.
Today I will write about the final steps which has to be made in order to
toggle off experimental feature from Firebird and use HSQLDB migration by default. This process also involves the creation of some unit tests, and
modifying some others.
First, I’d like to mention that there were already some unit tests, which tested the HSQLDB driver. These tests can be easily reused, since the test cases use the sdbc interface which makes the underlying driver transparent. It means that these tests – after enabling database migration – will be useful not only for testing the sdbc driver, but also to test the migration.
Besides that, I added two CppUnitTest for testing the migration indirectly. One of them tests the sql parser which should get rid of HSQLDB specific parts of the statement. These test cases get SQL strings as an input, and assures that the output of the parser makes sense in the actual sdbc driver’s context.
There were some special cases to cover up. For example HSQLDB’s VARCHAR doesn’t necessarily need a parameter during the creation of the table. This would cause an error with Firebird, so in that case a default size parameter has to be added.
The other test suite aims the binary import by using an example odb file containing a HSQLDB database. The test asserts that the values in each cell of the example database are the same after the migration.
At this point, I had some trouble with the DATE, TIME and DATETIME values.
HSQLDB interprets an incoming input of one of these types as local time. That means if you insert 06.04.2018 00:00 into the database – either with direct sql or in the graphical table view in LibreOffice – it will check your timezone, and convert the time to GMT (in case of CACHED tables, as it is in case of an embedded HSQLDB document). If I created the database from Budapest with time zone GMT+2, the actual value stored will be the elapsed milliseconds since 1970 until 05.04.2018 22:00. This issue is tracked in Bugzilla here.
There is no problem with that when you read out your date with the same time zone. But If I want to send my odb file to a friend in China, all the values will be changed. An easier way to reproduce this is to run LO as follows:
DATE=$(TZ=Asia/Taipei date +”%F %H:%M”) libreoffice –base
This anomaly comes up when migrating the database too. Firebird (by default) doesn’t care about time zones, it is the user’s responsibility to interpret the values the correct way. It seems to me that this would be the correct behaviour in case of an embedded database, since these files can be …
After 2010, 2012, 2013 and 2015, another LibreOffice HackFest will take place in Hamburg this coming weekend, April 7th and 8th.
Want to meet hackers from one of the largest FLOSS projects, see what’s going in the world of large-scale C++ & document freedom, and try your hand at some easy hacks? We’ve Armin, one of our most experienced CIB developers on-site, to introduce & mentor folks in all things graphics and drawing layer.
Be cordially invited to meet us at the venue in St. Pauli, and just poke me on twitter or IRC for any questions or directions
See you there!
I started my examination of LibreOffice extension projects which remain in review state private and sent some owners an email. Let’s wait for the response and see if the projects could make it to publication. Will continue my work during the next days.
The LibreOffice community during the Hackfest at Betacowork in Brussels, Belgium.
On 7th to 8th April – this weekend- we will be in Hamburg, Germany to attend LibreOffice Hackfest. It’s again the time to meet other contributors to the project to “hack” all together. At the Hackfest will be EasyHacks prepared for anyone wanting to do their first code contributons to the project and we will be around to help every interested newcomer.
If you will be around and would like to have a chat with us drop us an email and we would be happy to see you there.
Check out the wiki page for more details.
The post Meet us this weekend in Hamburg! appeared first on Collabora Productivity.
I worked on an improvement of my script to find LibreOffice extension and template projects that are in the review state private and never made it to the review queue. I’ll run that script soon and evalute the resulting lists. Maybe some of the authors have forgotten about their projects or have other issues with the publication process. Let’s see what happens.
In my last post I wrote about the most recent fight against spammers. We sadly also have to fight vandalism. Luckily The Document Foundation had very seldom problems with human vandals, but this seems to change slowly. Since a few months a person (maybe a group up to five person) try to increase the version number for the next major release to 7.0 without having any support by the marketing folks, the TDF, the ESC or whatever team.
Many involved persons in the wiki team do not understand the obsession to increase a stupid number. As far as I know this person / these persons do not have added any valuable contribution to the project (neither code, translations, marketing, etc.). Moreover we do not understand the sense in increasing the version number without having an important reason or new features in the product, that justifies a version bump.
The problem with these kind of vandalism is that the manual work to revert and delete the stuff can be incredible high. Additional these kind of vandalism sadly cannot be prevented by filters, rules or (IP or username) blocks as this is simply to “random”. For that reason many related pages (e.g. the ReleasePlan) have been protected (move, edit, creation), although we do no like that. The whole project tries to be open as possible and tries not to create unnecessary barriers for new users.
For the case this persons reads this post, feel free to response here (or in the wiki), but do not increase our workload for reverting stuff. This doesn’t help anybody!
Long time no post, but actual events show that there is need for a new post.
In the last few weeks the amount of spam and thus the workload for the active admins (K-J, fitoschido, Eric, myself) got high for deleting spam and blocking these accounts.
As this was too time consuming (~12 pages per day), I had to thing about another solution.
Luckily I have some experience with the extension “AbuseFilters”. The result of our new AbuseFilter 67 are impressive:
The result of two days active filter is great.
| Statistics: | Of the last 636 actions, this filter has matched 25 (3.93%). |
(actions == User creation, page moves, page deletions, edits, changing user rights, etc.)
The logic behind this filter is rather easy:
if these criteria are valid, then the user has to click again on save. If that happens (and the actual spammer show that they do not read or at least do not hit save again) then the user gets automatically blocked.
New valid users do get a warning, both then they try to edit the USer-namespace above (see https://wiki.documentfoundation.org/WikiAction/edit/User:Dennisroczek/10 ) but also as a warning when asking to hit save again.
We – TDF wiki admins – do follow edits (see screenshot above) which got prevented by this filter and check for false positives.
In Calc it is possible to activate "Value Highlighting" mode (Ctrl + F8). When activated, Calc displays cell contents in different colors, depending on type. By default Text cells are formatted in black, formulas in green, number cells in blue, and protected cells are shown with light grey background, no matter how their display is formatted. There was no possibility to change default colors what could be a problem for a color blind person. During my work for Collabora Productivity I introduced new entries to the "Application colors" tab in Calc options to fix this issue:
La última semana el nuevo sistema de ayuda – online y offline – recibió mejoras para agregar multimedia y otros recursos para una experiencia de usuario enriquecida de la Ayuda de LibreOffice. La nueva ayuda ahora puede acceder a vídeos …
自由及開源軟體的世界，向來以包容和開放為人所知：無論年齡、出身地、背景等，任何人皆可參與。在 LibreOffice 社群裡，我們向來對於貢獻自己寶貴知識及想法的資深成員非常重視。
今天我們與談的對象是 Italo Vignoli，他從 LibreOffice 成立的第一天就開始參與，主要負責行銷與社群的公共關係。他將談談當初帶領他走入開源世界的契機，以及行銷 LibreOffice 時所遇到的種種挑戰和可行的機會。
1. 你的背景在自由軟體界中似乎有點特別。你為什麼會在 50 歲的時候，毅然決定開始提倡自由軟體和 OpenOffice.org（LibreOffice 的前身）？
大概在 90 年代後期，我開始在找 Microsoft Office 的異質方案，可是我不太喜歡那些明顯沒有願景的「山寨版」。到了2002年的時候，我偶然發現了 OpenOffice.org，然後為它的潛力深深著迷（雖然當時的 1.0 版還算很「年輕」）。
在那之前，我從沒接觸過開源軟體，但我下定決心要學。從2003年起，我試著開始了解社群，並在2004年初寫了個訊息給義大利語的 NLP（即母語專案，Native Language Project），還有行銷專案的領導者，想說我可以協助提升 OpenOffice.org 在媒體界的知名度。在2004年9月一場在柏林召開的研討會上，我遇見了 OpenOffice.org 社群，深深被這群人的價值理念和對創新的熱情感動，所以我決定要成為社群的一份子。
從那天起，到現在已經超過 13 個年頭，我依然保有同樣的熱忱和動力，投身在這個改變軟體世界的社群中。
2. 你原本是什麼背景？後來又是什麼原因讓你投入開源世界的？
我1954年出生，所以今年是 63 歲。我的好奇心一直很強，這讓我走出了人文領域的背景。
事實上，從我在人文地理學系（human geography）畢業之後，就開始在義大利旅遊俱樂部（Italian Touring Club）擔任製圖部門的主編。同時我也義務擔任米蘭大學（Milan State University）的地理學助理教授，以及在報導歐洲都會地區發展的記者。
在1981年末的時候，我轉任漢威公司（Honeywell），它當時是一間很大的電腦公司，我負責提升大眾對個人電腦印表機的認知（IBM PC 在那一年剛推出）。我很快發現，我對資訊科技有一股熱情，以我的出身背景和不怎麼好的數學能力來說，這實在是始料未及。
在擔任過電腦周邊設備以及 UNIX 電腦的全球行銷總監之後，我了解到，在高科技業界從事溝通工作是我夢寐以求的職務。所以我在1987年離職，投入一家義大利的大型公關公司，在職涯中也和許多不同家的公關公司合作過。在創辦自己的兩間公關公司之前，有段時間我像個自由工作者一樣，幫助過幾間跨國公司在義大利成立或發展他們的業務。
到了2004年，我開始在 OpenOffice.org 擔任志工，提升義大利媒體圈對自由辦公軟體的認識。2010年時，我有幸成為促成文件基金會（TDF）及 LibreOffice 誕生與發展的人員之一，並且擔任執導委員會（Steering Committee）的委員，後來也是文件基金會第一屆董事會（Board of Directors）的成員。
從2013年底開始，我是 TDF 的僱用團隊（paid team）員工之一。我先是協助規劃認證制度的雛形；在2014年底之後，轉為專注在行銷及公關領域上。
4. 你閑暇時間會做些什麼？
我喜歡和我太太一起旅行，走訪那些從沒見過的風土民情；但因為我很愛自由和開源軟體，所以花了很多閑暇時間去參加研討會或地方社群聚會，聊聊開源軟體、開放標準——當然還有 LibreOffice。
5. 你個人怎麼看待 LibreOffice 專案？
LibreOffice 可以說是讓社群的夢想成真：有一個獨立、自給自足的基金會，還能夠推動自由的辦公軟體概念，並且教育使用者開源軟體和開放文件格式的優點。
過去的歷史強迫社群重新思考局勢，後來也證明了這是典範轉移的適當時機：待在保護傘下十年之後，我們把傘顛倒過來，變成了一個大碗，而每位志願者的貢獻都是關鍵食材，共同烹煮出碗中這道佳肴。
2010年9月那時候，我們不知道自己正在寫下開源歷史的新章。時至今日，我們清楚意識到：文件基金會和 LibreOffice 已是開源生態系的關鍵資產，因此承擔著重責大任。
LibreOffice 是開源世界的一艘「破冰船」，它和瀏覽器以及郵件軟體一同，是會最先被安裝到 Windows 和 macOS 個人桌面上的開源軟體。它也是最早被企業和公家機關採納，用來取代特定專有軟體的開源應用。
6. 就你看來，TDF 在2018年及未來將面臨的重大挑戰會是什麼？
隨著2017年初媒體界發表了首篇「LibreOffice 的異質方案」文章，這代表我們已經在自由辦公軟體領域中獲得公認的領導地位。
所以，第一個挑戰就是要跟上利害相關人的期望：記者，他們默默選擇了 LibreOffice 作為市場領導者最主要的異質方案；決策者，他們在決定取代專有辦公軟體時，下注在 LibreOffice 身上；以及我們的數百萬名用戶，他們仰賴 LibreOffice 履行日常職務所需。
第二個挑戰，是要讓氣勢如環無端永續不衰，也就是讓主要的發行版一個接一個推出。LibreOffice 不斷在改進，包括增添新功能、改善現有功能，並清理一些從 OpenOffice.org 延續而來的缺點等等。
最後一點是，我們有責任教育公家機關、企業，甚至個人使用者，關於開放文件格式的互通性優勢。但不幸的是，這並不容易，因為大多數人低估了這個課題的重要性（而且從未接受過互通性相關的教育）。
7. 你估計文件基金會和 LibreOffice 到了2020年會是什麼樣子？甚至說2025年呢？
我們在2010年9月底啟動這個專案時，我們告訴媒體說，我們的夢想，是在2020年達到使用者 2 億的目標。大約在七年之後，我們逐漸上了軌道。 因此，我想不必有太多的臆測，就專心做好日常工作，然後繼續改善軟體和發展社群吧。
8. 你對 TDF 的成果有何看法？ 是否有什麼事情是原本可以實現但後來沒有達成的嗎？
當然，打從第一天開始，我們就可以做更多事情來讓社群茁壯。可是，我們的資源有限，尤其是在社群剛起步的那個階段，我們必須在創立基金會、改善產品、對外溝通提高知名度等三者之間取得平衡。
根據我們在過去幾年在社群發展方面所取得的成果來看，我認為當時做了一個正確的決定：我們設法打造品牌知名度，藉此維持下載量及持續捐款（到目前為止，這是支持社群發展等各種活動的關鍵因素）。
9. 你有貢獻過其他的開源專案嗎？如果有的話，你扮演的是什麼角色、又有什麼樣的期待？
我目前也是開源協會（OSI, Open Source Initiative）董事會的成員，我試著將自身的行銷經驗及溝通經驗帶到那裡，提升大家的關注。
10. 最後壓軸問題，你都用什麼硬體，或怎樣的個人軟體配置？你有任何偏好的工具嗎？
我有很長一段時間是個 Mac 用戶，因為蘋果電腦是絕大多數公關公司的首選系統。我依舊還留有幾臺 Mac，但我現在是快樂的 GNU/Linux 使用者。我使用的是安裝 Ubuntu 16.04 的 Dell XPS 筆電，但未來我會轉向其他家採用 GNU/Linux 的筆記型電腦廠牌，因為 Dell 已經不會在歐洲銷售它們了。我還有一臺 Android 的 Asus Zenfone 4，和一臺也是 Android 的 Samsung Galaxy Tablet 2。
Sourceforge is running a poll to elect its May’s Project of the Month, and Firebird is among the candidates.To vote, you need to have an account (it is free to register) at sourceforge.net and go to this URL, and comment with the following line:VOTE: firebird
在办公室里经常会用到扫描仪。但是，很多扫描仪只能扫描为图片格式，而很多时候我们需要的是PDF格式。如果只有一两个图片，转换为PDF不会很难，但是如果有上千个图片的话，一个一个将其插入到文字处理软件（比如 LibreOffice Writer 等）中然后调整对齐格式等再导出，会非常麻烦。
幸好，我们有 LibreOffice Impress。这个虽然是个幻灯片，但是其中有一个“相册”的功能，可以很轻松地完成这项任务。
要将多个图片快速转换为PDF，请执行以下步骤：
是不是很简单，很强大？
You may have been using scanner very often in your daily work at office. There are chances that your scanner can only scan to image format, but you need to convert it to PDF in order to send it to someone, or just for archive purpose.
If the scanned document has only one page (i.e., one image), it will be easy to convert it to pdf. However, if there are thousands of pages, it would be a nightmare to convert them to pdf by inserting images to Writer or any other text processor one-by-one.
Luckily, we have LibreOffice Impress, which contains a handy tool called “Photo Album” to do this kind of task. To convert many images located in a folder sorted in order, just do the following:
It’s easy and powerful, isn’t it?
Over the past months, we have been able to make some resources available to look into the most urgent Mac-specific bugs in LibreOffice, thanks to people purchasing LibreOffice Vanilla on the Mac App Store.
A few bugs were related to use of various 3rd-party fonts on macOS. The system APIs used by LibreOffice to enumerate installed typefaces and their styles indicate the weight of the font as a floating-point number between -1.0 and 1.0, with zero being “regular” weight. That number needs to be converted to an integer (with just ten separate values) used in LibreOffice. The mapping is heuristic, and it turned out that tweaking the mapping just a little bit made it possible to distinguish between some weights of a typeface that had previously mapped to the same weight in LibreOffice.
Another issue was that for some other 3rd-party fonts, the system API claimed that the weight of the “Regular” style was non-zero and positive (0.23 to be exact), i.e., a bit on the bold side. LibreOffice trusted that, which lead to the bold style always being selected for those typefaces, even when asking for a non-bold, regular (medium) weight. The fix for this was to simply handle these special cases separately. If resources allow and more similar problematic fonts are identified, some more generic fix would be needed.
Another set of bugs were related to notifications for screen parameter changes (like when changing the size of the Dock, or attaching or detaching monitors). On some Macs, the system sent these notifications quite eagerly for no obvious reason. LibreOffice was asking to receive such notifications too early before it was prepared to handle them. This lead to a crash. The fix was to request notifications only once being prepared to receive them.
Also, the handler for this notification did not check whether anything had actually changed that LibreOffice would want to know but just went through all the motions of re-calculating layouts of GUI and sizes of text and whatnot, totally in vain. This took a considerable amount of time when you had a lot of document windows open and several of these notifications were received. The fix here was to add a check if anything actually had changed that would be of interest to LibreOffice, and if not, just don’t proceed to do any re-calculations of layouts etc.
Finally, there was a problem with inserting videos in Impress presentations. When doing that LibreOffice (for some reason) copies the video file first into a temporary copy. That copy was given a name without file name extension. The system APIs used to open and display the video did not like that and displaying even an initial grabbed frame from the video failed. The fix was simply to make sure the copy of the video file had the same file name extension as the original one.
We’ll be addressing more Mac issues as when as we …
It's been some times from my last blog post and in that time I continued with refactoring the code to get rid of use of GraphicObject uniqueID being passed around and stored in the model. The state of the code now is looking fine as we almost don't use the uniqueID anymore, which means that I can start with the next step of Graphic and GraphicObject improvements.
There is a thing I forgot to clarify in the last blog post and this is that the GraphicObject uniqueID is usually passed around in the form of a URL string. The string has the prefix "vnd.sun.star.GraphicObject" and followed by the GraphicObject uniqueID. Using that URL it is possible to re-create a GraphicObject by passing the unique ID as the construction parameter (see constructor with OUString parameter on GraphicObject or UNO serviceGraphicObject::createWithId).
I worked on a notebook of colleague with a broken hard disk during the weekend. I removed the old disk and added a solid state drive to it. I installed also operating system to the new disk and in addition she got some free software on it, particularly the new LibreOffice 6.
| Imprint Privacy Policy | |
|
The Document Foundation is not responsible for the content on planet.documentfoundation.org. Copyright information: Unless otherwise specified in the author's blog, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the "Mozilla Public License v2.0". "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy. |
 |
| this site runs a modified version of planet.opensuse (https://github.com/openSUSE/planet.opensuse.org) © 2010 Pascal Bleser and the openSUSE Community. | |
