Reproducible on:
Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL
--
You received this bug notification because you are a
The problem seems to have been resolved on LO 7.3.0.3 on Windows 10. To
test PDF output this time, I used Adobe Acrobat DC 2021.011.20039
64-bit. I haven't tested on Linux, where the problem initially appeared.
Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID:
Reproducible on:
Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL
--
You received this bug notification because you are a
Reproducible on:
Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL
--
You received this bug notification because you are a
Sorry, I take back my word. It's still the same issue in RTL paragraphs
on LO 7.3.0.3. Writing my previous comment, I had only tested LTR
paragraphs, which had other issues. RTL paragraphs still displace the
text one inch to the left and up.
--
You received this bug notification because you are
Reproducible on:
Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL
--
You received this bug notification because you are a
This particular problem seems to have been resolved on LO 7.3.0.3 on
Windows 10. Rotating these and other Arabic-script characters does not
work as expected (sometimes the text won't rotate at all or if it does,
the letters are in reversed order) but these seem to be separate issues.
Version:
Created attachment 178599
Screenshot on 7.3.0.3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1793127
Title:
[upstream] Font metrics mixed up for RTL insets in a LTR context in
Calc
To manage
Tested again on LibreOffice 7.3.0.3 on Windows 10. Now the formula line
looks good but all LTR cells in the main view have font metrics mixed
up, whether I'm currently typing them or not. For some reason, cells
starting with a RTL character that Calc automatically aligns to the
right behave as
Public bug reported:
I did a fresh Ubuntu 21.04 installation from a USB drive on a machine
which already had Windows 10. I selected default settings for dual-boot,
did not connect to Wifi since I didn't have time to wait for downloads,
and checked 3rd party software. Everything went fine until it
Public bug reported:
Steps to reproduce:
1) Create a new collection and type some data in it but don't save it.
2) Click on Dashboard. Now parley says: "Vocabulary is modified. Save
file before exit?"
3) Click Save and type the name of the collection without any file
ending, e.g. "Verb
Created attachment 155033
Screenshot on LO 6.3.2.2
The first line in the main view looks correct; the second line, which
I'm still typing at the moment of this screenshot, is incorrect. The
formula line is incorrect, too.
--
You received this bug notification because you are a member of Ubuntu
I tested this again with LO 6.3.2.2 installed on Ubuntu as a snap. Now
font metrics are still mixed up in the main view while I am typing and
permanently on the formula line. When I finish typing and press Enter,
the main display shows the characters correctly. So part of the problem
is fixed,
Still reproducible on
Version: 6.3.2.2
Build ID: libreoffice-6.3.2.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Thanks for your advice. I did what you suggested and everything worked
as expected. After some experimentation, I think I found the cause of
the problem, too: What I had previously installed on my system was the
full font package called "OldHungarian_0.5.zip" available on Github
under "Releases".
Font substitution for spaces and punctuation worked well when I
submitted bug #1800640 for LO 6.0.6.2. There is even a screenshot
attached to that bug report where you can see it for yourself. The text
in the two screenshots is the same except for the sentence in English
and a couple of words
Public bug reported:
I recently noticed a regression in how LibreOffice Writer handles font
substitutions for basic ASCII punctuation including space (U+0020). For
test purposes, I wrote a document in the Old Hungarian script and used a
font called "OldHungarian" from
** Attachment added: "ODT document used to create the screenshot"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1847126/+attachment/5295179/+files/Old%20Hungarian%20text%20sample.odt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Still reproducible on:
Version: 6.3.2.2
Build ID: libreoffice-6.3.2.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
pdftotext's output is again different from my initial report but it's
still garbled:
أ
ه
Still reproducible on:
Version: 6.3.2.2
Build ID: libreoffice-6.3.2.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Still reproducible on:
Version: 6.3.2.2
Build ID: libreoffice-6.3.2.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Still reproducible on:
Version: 6.3.2.2
Build ID: libreoffice-6.3.2.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Still reproducible on:
Version: 6.3.1.2 (x64)
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
Threads CPU : 4; OS : Windows 6.3; UI Render : par défaut; VCL: win;
Locale : fr-FR (fr_FR); Langue IHM : fr-FR
Calc: threaded
--
You received this bug notification because you are a member of
Still reproducible on:
Version: 6.3.1.2 (x64)
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
Threads CPU : 4; OS : Windows 6.3; UI Render : par défaut; VCL: win;
Locale : fr-FR (fr_FR); Langue IHM : fr-FR
Calc: threaded
--
You received this bug notification because you are a member of
Today I installed the snap in the candidate channel (6.1.3.2, revision
93). The problem appears to be fixed. Thanks for your help in testing!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1804657
I just filed a separate report at
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1804657
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1800640
Title:
Plane 1 (SMP) characters are not
Public bug reported:
I recently noticed that there is a regression that was introduced
somewhere between LibreOffice 6.0.6.2 and 6.1.3.2, which I installed as
a snap (version number 90) on Ubuntu 18.04. Steps to reproduce:
1) Write a paragraph in Old Hungarian (Unicode block U+10C80 to
U+10CFF).
Yes, the justification issue appears to have been fixed in the snap I
just installed (6.1.3.2) but I noticed there is another regression:
double-clicking on text should select the whole word under the cursor.
In 6.0.6.2, this feature works well for both of the languages of this
test case (Gothic
Public bug reported:
In gedit's Perl highlight mode, variables of all kinds ($var, %hash,
@array etc.) are highlighted in dark green. The same usually works for
the last index of an array as well ($#array) but only if the array is
one-dimensional. With multidimensional arrays, the proper syntax
Public bug reported:
Justifying paragraphs with Unicode Plane 1 (SMP) characters does not
work as expected. See the attached screenshot of a document with one
paragraph in Gothic (U+10330–U+1034F) and another one in Old Hungarian
(U+10C80–U+10CFF). Both paragraphs have been justified but visually
** Attachment added: "Document used to create the screenshot"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1800640/+attachment/5207147/+files/Plane%201%20justification.odt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I submitted an upstream report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119961
** Bug watch added: Document Foundation Bugzilla #119961
https://bugs.documentfoundation.org/show_bug.cgi?id=119961
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I filed an upstream report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119960
** Bug watch added: Document Foundation Bugzilla #119960
https://bugs.documentfoundation.org/show_bug.cgi?id=119960
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Public bug reported:
Calc normally aligns text cells to the right or to the left based on the
directionality of the first character of the cell (left-alignment with
English and right-alignment with Arabic). Unfortunately, this assignment
happens only when the user has finished typing and pressed
Public bug reported:
In the attached screenshot, I’ve written an English sentence with an
Arabic word in the middle on the first row of a Calc sheet. On the
second row, I’ve written the same Arabic word (العربية) by itself. The
second row looks as it should but on the first row, some of the
I submitted a separate report for the font metrics problem at
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1793127
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1793126
Title:
Public bug reported:
Calc seems to assign the alignment of any particular text cell based on
the contents of the cell: if the first character is a LTR character, the
cell is aligned to the left, and if the first character is RTL, the cell
is aligned to the right. This is desirable behavior but it
** Attachment added: "Calc scrolling 2.png"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1793124/+attachment/5190162/+files/Calc%20scrolling%202.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
I sometimes receive Calc documents where the content of an individual
cell is split on so many lines that it fills up the whole screen and
more. I can easily see the top part of these cells but scrolling to the
bottom does not seem to work. Whether I try dragging the
I filed an upstream report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119608
** Bug watch added: Document Foundation Bugzilla #119608
https://bugs.documentfoundation.org/show_bug.cgi?id=119608
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
The same problem does occur on LO 6.0.3 on Ubuntu 18.04. After looking
through Arabic-specific issues reported upstream, I did find this:
https://bugs.documentfoundation.org/show_bug.cgi?id=85426 . I think it's
the same issue, although the bug title only mentions "fixing line space"
and a specific
I filed an upstream report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119606
** Bug watch added: Document Foundation Bugzilla #119606
https://bugs.documentfoundation.org/show_bug.cgi?id=119606
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I filed an upstream report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119604
** Bug watch added: Document Foundation Bugzilla #119604
https://bugs.documentfoundation.org/show_bug.cgi?id=119604
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I tested the same example sentence with Ubuntu 18.04 and LibreOffice
6.0.3.2. Here’s the output from pdftotext:
ه
اشترى للا خمسة آفا كتاب وَأنَا اشْ ت َ َريْتُهَا ِ
من ْ ُ
Here four out of the eight words are intact, so it’s an improvement to
5.4.6 but still leaves a lot to hope for. The last
One user on debbugs.gnu.org reported that the problem is more likely
related to the locale / glibc than coreutils, and that it occurs on
Ubuntu 18.04 but not Fedora 28, in case that helps any. He thought it
might have already been fixed in glibc, since Fedora tends to be more up
to date than
Since nobody has reacted to this report for a couple of months, I
decided to file an upstream report at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32472
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I filed an upstream bug report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119347
** Bug watch added: Document Foundation Bugzilla #119347
https://bugs.documentfoundation.org/show_bug.cgi?id=119347
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I filed an upstream bug report at
https://bugs.documentfoundation.org/show_bug.cgi?id=119346
** Bug watch added: Document Foundation Bugzilla #119346
https://bugs.documentfoundation.org/show_bug.cgi?id=119346
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Public bug reported:
I’ve found out that sort doesn’t sort strings for many non-Latin scripts
at all if the locale you’re using is one of en_US.UTF-8, fr_FR.UTF-8 or
fi_FI.UTF-8 (probably others, too, but these are the ones I have
tested). For locales ”C” and ko_KR.UTF-8, things work as expected.
Public bug reported:
Selecting files with long filenames using Shift and arrow keys causes
nautilus in icon view not to advance sequentially or not to advance at
all. Here's a test case:
1) Create a new folder and create empty files with long names in it
using the command:
for i in 1 2 3 4 5 6
I did what you suggested and installed LibreOffice 6.0.3.2 together with
a full system update from Ubuntu 17.10 to 18.04. Now the document seems
to work fine. Thank you for your help!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I did what you suggested and installed LibreOffice 6.0.3.2 together with
a full system update from Ubuntu 17.10 to 18.04. Now the document seems
to work fine. Thank you for your help!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Sorry, for some reason, my browser seems to have submitted the same bug
report twice, as #1774243 and #1774244. All the relevant information,
including all the attachments are posted in this report, so I marked the
other report as a duplicate.
--
You received this bug notification because you
*** This bug is a duplicate of bug 1774244 ***
https://bugs.launchpad.net/bugs/1774244
** This bug has been marked a duplicate of bug 1774244
Rotated Arabic text is displaced in PDF when substitute glyphs are used
--
You received this bug notification because you are a member of Ubuntu
This is the ODT document used to create both the PDF and the screenshot.
** Attachment added: "Displaced rotated Arabic.odt"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1774244/+attachment/5146583/+files/Displaced%20rotated%20Arabic.odt
--
You received this bug notification
Here's a screenshot where everything looks fine, unlike the PDF.
** Attachment added: "Screenshot displaced Arabic.png"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1774244/+attachment/5146582/+files/Screenshot%20displaced%20Arabic.png
--
You received this bug notification
Public bug reported:
In this example, I created a document with a few Arabic-script
characters (U+08A2, U+08A3 & U+08A4), which were quite recently added to
Unicode for various Arabic-script African languages such as Fulfulde.
The font I had used in the rest of the document was DejaVu Sans, so I
Public bug reported:
In this example, I created a document with a few Arabic-script
characters (U+08A2, U+08A3 & U+08A4), which were quite recently added to
Unicode for various Arabic-script African languages such as Fulfulde.
The font I had used in the rest of the document was DejaVu Sans, so I
I filed the bug upstream at
https://bugs.documentfoundation.org/show_bug.cgi?id=117907
** Bug watch added: Document Foundation Bugzilla #117907
https://bugs.documentfoundation.org/show_bug.cgi?id=117907
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I filed the bug upstream at
https://bugs.documentfoundation.org/show_bug.cgi?id=117908
** Bug watch added: Document Foundation Bugzilla #117908
https://bugs.documentfoundation.org/show_bug.cgi?id=117908
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@Olivier, no, the upstream bug you mentioned is different. In the
example I posted, there are no diacritics (problem number 1 in the
upstream report), and visually the text looks fine with no undesirable
kerning or spaces (problem number 3 in the report). It's just selection
which misbehaves; the
After that, LibreOffice automatically restarts and gives me the attached
screen. If I press "Start", the program crashes again and the whole
thing repeats itself.
** Attachment added: "Crashing Arabic document restore dialog.png"
The crash does occur but I don't get anything in /var/crash/. Every time
I open the file, whether through nautilus or from LibreOffice's Open
dialog, LibreOffice immediately closes and gives me the following
screen.
** Attachment added: "Crashing Arabic document error dialog.png"
Here's the PDF for the Arabic example, where you can see additional
lines in the first paragraph (justified) but not in the second one
(right-aligned).
** Attachment added: "arabic-clutter.pdf"
Just noticed that the same thing happens sometimes with Arabic, too. The
attached document looks fine on screen but not when you create a PDF.
** Attachment added: "Example Arabic clutter.odt"
I filed the report upstream at:
https://bugs.freedesktop.org/show_bug.cgi?id=106649
** Bug watch added: freedesktop.org Bugzilla #106649
https://bugs.freedesktop.org/show_bug.cgi?id=106649
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Public bug reported:
The Compose file for the fi_FI.UTF-8 locale at
/usr/share/X11/locale/fi_FI.UTF-8/Compose contains the following lines:
: "Ệ" U1EC6 # LATIN CAPITAL LETTER
E WITH CIRCUMFLEX AND ACUTE
: "Ệ" U1EC6 # LATIN CAPITAL LETTER
E WITH CIRCUMFLEX AND DOT BELOW
Screenshot of selecting the same characters in Calc, which shows the
expected behavior.
** Attachment added: "Screenshot selecting Arabic Calc.png"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772520/+attachment/5142596/+files/Screenshot%20selecting%20Arabic%20Calc.png
--
You
Public bug reported:
In most fonts, many characters in the Arabic script change their width
and height as typing progresses. For example the letter ب (U+0628) is
reduced to about a half or even a third of its width if it's followed by
another character such as ا (U+0627): با. Usually LibreOffice
Here's the output from lsb_release and apt-cache policy:
Description:Ubuntu 17.10
Release:17.10
gkbd-capplet:
Installed: 3.26.0-2
Candidate: 3.26.0-2
Version table:
*** 3.26.0-2 500
500 http://mr.archive.ubuntu.com/ubuntu artful/main amd64 Packages
100
Public bug reported:
gkbd-keyboard-display, which shows the current keyboard layout on Gnome
/ Unity desktop, doesn't handle keyboards with RTL characters well. See
the attached screenshot for the standard Hebrew keyboard, where the key
labeled "Y" should have "ט" on lower left (key pressed
Public bug reported:
I have found that in some cases using Clone Formatting copies only a
part of the attributes of the text. In the example case, open the
attached document, press the Clone tool while the cursor is on the first
paragraph and select the second paragraph. Here cloning works as
Public bug reported:
In this scenario, I have a Calc cell with formatted text (italics,
underlining, boldface, font color etc.). Now if I want to change the
formatting of a part of that same cell afterwards, I would naturally
select the cell, go to the input line, select the part I want to change
Public bug reported:
To reproduce this bug, follow these steps:
1) Create two paragraphs of text, one with font size 14 and the other with size
18.
2) Copy some text from the first paragraph to the end of the second paragraph
using Ctrl-C and Ctrl-V.
3) Now press immediately Ctrl-Z for undo.
The ODT document used to create the screenshot.
** Attachment added: "Rotated line ordering.odt"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772459/+attachment/5142456/+files/Rotated%20line%20ordering.odt
--
You received this bug notification because you are a member of
Public bug reported:
Text rotated through Character > Position appears to rotate each line of
text separately and order them according to the text direction of the
paragraph, i.e. in an English text, placing the first line leftmost and
in an Arabic text, placing the first line rightmost,
Second screenshot showing all the diacritics in full.
** Attachment added: "Writing Arabic vowels 2.png"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772451/+attachment/5142427/+files/Writing%20Arabic%20vowels%202.png
--
You received this bug notification because you are a
Third screenshot showing remnants of diacritics after the text has
already been removed.
** Attachment added: "Writing Arabic vowels 3.png"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772451/+attachment/5142435/+files/Writing%20Arabic%20vowels%203.png
--
You received this
Public bug reported:
Arabic is sometimes written with diacritical vowel marks, which are
placed either above or below each letter of the word. Many multipurpose
fonts, which are not designed specifically for Arabic, place some of
these marks in the empty space between lines, outside of the space
Public bug reported:
Text can normally be rotated either 90 or 270 degrees through the
Character > Position dialog box. This works even in tables, but only if
the table’s text direction is set to Left-to-right. If the table’s text
direction is set to Right-to-left through the Table properties
The ODT document used to create the screenshot.
** Attachment added: "RTL table rotated text.odt"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772445/+attachment/5142410/+files/RTL%20table%20rotated%20text.odt
--
You received this bug notification because you are a member of
This is the document used to create the screenshot and the PDF.
** Attachment added: "Syriac justification bug.odt"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772414/+attachment/5142406/+files/Syriac%20justification%20bug.odt
--
You received this bug notification because
Example PDF document created with Writer.
** Attachment added: "Syriac justification example.pdf"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772414/+attachment/5142405/+files/Syriac%20justification%20example.pdf
--
You received this bug notification because you are a member
Screenshot of the bug.
** Attachment removed: "Syriac justification bug.zip"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772414/+attachment/5142364/+files/Syriac%20justification%20bug.zip
** Attachment added: "Screenshot Syriac justification bug.png"
Public bug reported:
Creating a PDF from a document written in the Arabic script deforms the
textual content of the document, although it looks fine on the screen.
For example, see the attached PDF created with Writer, where the example
sentence "اشترى بلال خمسة آلاف كتاب وَأَنَا اشْتَرَيْتُهَا
Another screenshot showing a crammed-up line at page break (no paragraph
break).
** Attachment added: "Screenshot 80 percent line spacing 2.png"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772430/+attachment/5142396/+files/Screenshot%2080%20percent%20line%20spacing%202.png
--
This is the document which was used to create the screenshots.
** Attachment added: "80 percent line spacing.odt"
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772430/+attachment/5142397/+files/80%20percent%20line%20spacing.odt
--
You received this bug notification because you
Public bug reported:
Using proportional line spacing with less than 100 % makes the first
line of each paragraph and each page considerably lower than all the
other lines.
This problem is an issue particularly with fonts designed for Arabic,
where the default line spacing is very big so as to
Public bug reported:
The attached document makes LibreOffice Writer crash immediately after
opening it, along with the following error message:
*** Error in `/usr/lib/libreoffice/program/soffice.bin': munmap_chunk():
invalid pointer: 0x55794428ad40 ***
I created this ODT file by converting
Public bug reported:
Justifying a paragraph in LibreOffice Writer with text written in the
Syriac script (Unicode block U+0700-U+074F) creates graphic clutter
between every word. See the attached screenshot where the first
paragraph is justified and the second is right-aligned. The second
Oops, the attachment was left out...
** Attachment added: Automatic crash report
http://librarian.launchpad.net/5619497/_usr_bin_swfdec-mozilla-player.1000.crash
--
swfdec0.3 crash
https://launchpad.net/bugs/77720
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Same here. I just opened http://blog.freecontrib.org/ and voilà the
result.
--
swfdec0.3 crash
https://launchpad.net/bugs/77720
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
92 matches
Mail list logo
