[Issue 73565] InStr function does not work properly with accentuated letters case
https://bz.apache.org/ooo/show_bug.cgi?id=73565 bmarcelly changed: What|Removed |Added CC||marce...@club-internet.fr --- Comment #9 from bmarcelly --- Easy workaround : convert to lower case before using InStr. Dim sInput As String Dim iPos as Integer sInput = "OpenOffice est GÉNIAL" iPos = Instr(LCase(sInput),"génial") print iPos -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 126533] Slide Presentation on 5th slide get an SEH Exception Access Violation
https://bz.apache.org/ooo/show_bug.cgi?id=126533 mroe changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from mroe --- As of comment 1. *** This issue has been marked as a duplicate of issue 125567 *** -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125567] In slideshow mode, fatal error: SEH Exception ACCESS VIOLATION
https://bz.apache.org/ooo/show_bug.cgi?id=125567 mroe changed: What|Removed |Added CC||sw...@embarqmail.com --- Comment #25 from mroe --- *** Issue 126533 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125003] Integrate GoogleTest unit test framework for general usage in the build environment
https://bz.apache.org/ooo/show_bug.cgi?id=125003 --- Comment #63 from SVN Robot --- "damjan" committed SVN revision 1704103 into trunk: #i125003# migrate main/sw from cppunit to Google Test. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125003] Integrate GoogleTest unit test framework for general usage in the build environment
https://bz.apache.org/ooo/show_bug.cgi?id=125003 --- Comment #64 from SVN Robot --- "damjan" committed SVN revision 1704112 into trunk: #i125003# migrate main/sal/qa/systools from cppunit to Google Test. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125003] Integrate GoogleTest unit test framework for general usage in the build environment
https://bz.apache.org/ooo/show_bug.cgi?id=125003 --- Comment #65 from SVN Robot --- "damjan" committed SVN revision 1704121 into trunk: #i125003# migrate main/sal/qa/osl/security from cppunit to Google Test. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125003] Integrate GoogleTest unit test framework for general usage in the build environment
https://bz.apache.org/ooo/show_bug.cgi?id=125003 --- Comment #66 from SVN Robot --- "damjan" committed SVN revision 1704132 into trunk: #i125003# migrate main/cppuhelper/qa/propertysetmixin from cppunit to Google ... -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125003] Integrate GoogleTest unit test framework for general usage in the build environment
https://bz.apache.org/ooo/show_bug.cgi?id=125003 --- Comment #67 from SVN Robot --- "damjan" committed SVN revision 1704155 into trunk: #i125003# migrate main/configmgr/qa/unit from cppunit to Google Test. All tes... -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125003] Integrate GoogleTest unit test framework for general usage in the build environment
https://bz.apache.org/ooo/show_bug.cgi?id=125003 --- Comment #68 from SVN Robot --- "damjan" committed SVN revision 1704156 into trunk: #i125003# migrate main/stoc/test/uriproc from cppunit to Google Test -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126529] Bullet should be apart of AccessibleText
https://bz.apache.org/ooo/show_bug.cgi?id=126529 --- Comment #1 from SVN Robot --- "damjan" committed SVN revision 1704176 into trunk: #i126529# Bullet should be apart of AccessibleText -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126529] Bullet should be apart of AccessibleText
https://bz.apache.org/ooo/show_bug.cgi?id=126529 dam...@apache.org changed: What|Removed |Added CC||dam...@apache.org Target Milestone|--- |4.1.2 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from dam...@apache.org --- Patch committed, resolving fixed. Thank you very much for your contribution! -- You are receiving this mail because: You are the assignee for the issue.
[Issue 66261] sheet tab font too small
https://bz.apache.org/ooo/show_bug.cgi?id=66261 sroig2...@my.fit.edu changed: What|Removed |Added CC||sroig2...@my.fit.edu --- Comment #15 from sroig2...@my.fit.edu --- The small text size is also an issue on Mac OSX 10.10.5. The text is very small and from a distance unreadable. Also the top of the text is being cut off. For user's with poor eyesight this unnecessarily reduces quality and should be considered a bug. -- You are receiving this mail because: You are on the CC list for the issue. You are the assignee for the issue.
[Issue 126531] different behaviour for "CharColor" and "CharBackColor" properties in java
https://bz.apache.org/ooo/show_bug.cgi?id=126531 --- Comment #3 from John R. D'Orazio --- I can also add that "int" is the correct type in Java for the "long" type in UNO, I found a page about type mapping for Java: https://wiki.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126531] different behaviour for "CharColor" and "CharBackColor" properties in java
https://bz.apache.org/ooo/show_bug.cgi?id=126531 --- Comment #4 from John R. D'Orazio --- I can also add that I have tried to set the "CharBackTransparent" property both to true and to false before setting the "CharBackColor" property, but it had no effect. In any case I have to clear the alpha bit. (So what exactly does the "CharBackTransparent" property do? Is it supposed to enable transparency for background colors? Doesn't seem to be working if it is...) -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126529] Bullet should be apart of AccessibleText
https://bz.apache.org/ooo/show_bug.cgi?id=126529 Marcus changed: What|Removed |Added Target Milestone|4.1.2 |4.2.0 --- Comment #3 from Marcus --- Patch was committed to trunk, so changed target version. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125012] PDF Export Issues
https://bz.apache.org/ooo/show_bug.cgi?id=125012 Nandhini changed: What|Removed |Added CC||njaganathanp2...@my.fit.edu --- Comment #9 from Nandhini --- Created attachment 84924 --> https://bz.apache.org/ooo/attachment.cgi?id=84924&action=edit PDFs showing the bug in Ooo v4.1.0 & v4.1.1 against MS Word & OOo's Print option I was able to successfully replicate this bug in both 4.1.0 and 4.1.1 versions on MAC OS X Yosemite v10.10.5. Tests: With the font face Time New Roman, I tried typing text that includes em, en, and hypen. Then, I tried the 'Export As PDF' option. It worked. I repeated the same procedure for different font face, New Waltograph. This time the exported PDF file had a different symbols instead of em & en. For the font face, atlantix pro ssi & DK Crayon Crumble, the exported PDF had empty space instead of em & en. Last 3 font faces (New Waltograph, atlantix pro ssi & DK Crayon Crumble) are all installed by user. So finally, I exhaustively tried all font faces that came with OOo. It worked fine for all except the font face HeadLineA. I tried 'Ctrl+P' and then Save As PDF instead of 'Export as PDF' for the 3 font faces (New Waltograph, atlantix pro ssi & DK Crayon Crumble). It worked. I tried this with MS WORD. It worked when I saved as PDF. Summary: Export As PDF messes up em & en for user installed font faces. Conclusions: I didn't experience any messes that caused variation in em & en lengths as experienced by other users. Instead, both em & en vanished leaving empty space. All user installed font faces had this bug. Only one of the existing font face (HEadLineA) had this bug. Only Export As PDF combined with user-installed font face had this bug. Save As PDF worked fine. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 4638] ligature support
https://bz.apache.org/ooo/show_bug.cgi?id=4638 --- Comment #30 from JC Ahangama --- There are three objections to my suggestion that Write should follow the OT Standard when treating Standard ligatures. The first objection is that the request is too trivial to bother about. The next two objections are specifically directed against my solution for Indic scripts. My solution eliminates complexities of Unicode Indic leveling the languages with Western European languages tremendously helping to reduce illiteracy in India. My solution does not violate any technical or linguistic standard but upholds them. I have demonstrated that Indic can be romanized without loss or distortion. This fact is proven by simply displaying romanized Singhala in the native script by using an orthographic smart font. You test by phonetically typing the text. The objections are as below. Objection 1 -- Trivial issue It is indeed trivial for those who see no difference between implementation of Standard ligatures and no ligatures at all. This is the case with users of the Latin script except some who think there are language level ligatures. What they do not realize is that Write actually interferes with the display of ligatures prematurely or unnecessarily. There is no requirement in the Standard to prevent display of Standard ligatures provided by a font. They should show by default. In the case of Desktop Publishing software, you provide options to the author for selecting non-standard ligature types. Objection 2 -- The language of the text cannot be discerned from codes Although it sounds technical, no engineer would say it because they know immediately that there is no definitive way to identify languages just from the underlying code set because many languages share the same script, notoriously, Latin. The way to identify the language in the case of web pages is simple. The language tag will tell. (e.g. lang="en-US"). In other cases, you compare frequencies of character codes to known code frequency charts of languages and increase the confidence level by identifying frequently occurring words. (Google won't confuse Singhala and Indonesian / Icelandic if they do this). Objection 3 -- Rendering large number of ligatures is math intensive and could cause the computer to crash Again, this is not a statement by an engineer. A font responds to a keystroke by supplying the drawing coordinates and glyph drawing instructions. If the glyph returned is a base character, add the Advance Width of the already painted glyph to its origin of coordinates to get the origin for the new glyph. If the new glyph is a ligature, the existing origin is the origin of the new glyph as well. You might wonder if a font full of ligatures would paint the text faster everything else being equal. (Mixed Singhala text with my font is already 98% ligatures and shows no difference in performance. Mozilla in 2008 reported that the difference is 2% without saying which way). = My plea is simply to get rid of code that handles OT features that I suspect relies on the OS, and to reserve them for an advanced version of Write, may be WriteAndMore made for desktop publishing. Trusting Uniscribe in Windows adds a level of unknown which, in this case, is faulty. -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 126542] New: UI glitches while trying to add or remove colour from the option menu's colour section
https://bz.apache.org/ooo/show_bug.cgi?id=126542 Issue ID: 126542 Issue Type: DEFECT Summary: UI glitches while trying to add or remove colour from the option menu's colour section Product: Calc Version: 4.1.1 Hardware: PC OS: Windows 10 Status: UNCONFIRMED Severity: major Priority: P5 Component: ui Assignee: issues@openoffice.apache.org Reporter: brentliu...@gmail.com Created attachment 84925 --> https://bz.apache.org/ooo/attachment.cgi?id=84925&action=edit It shifted! I was trying to delete the default colour set and add in my own set of colours where I noticed this issue. Removing 1 or 2 colours seems to be working alright. But continuously deleting colours by clicking, and using Keyboard to press Y for confirming caused the UI of the colour swatch to shift to the top left. In the end most of the colours wasn't visible anymore. And, another issue I'm having is that each colour has to have a game. I wish to just add colours without any names. Is that possible? I took a screenshot where you can see it shifted position quite a bit just by deleting about 20 to 30 colours -- You are receiving this mail because: You are the assignee for the issue.
[Issue 125012] PDF Export Issues
https://bz.apache.org/ooo/show_bug.cgi?id=125012 --- Comment #10 from Nandhini --- Continued... The reported bug of unable to print files generated by 'Export as PDF' was also replicated. I tried printing the exported PDFs. My observations are, 1. When I tried printing files with contents only in known font faces, it worked. 2. User installed font-faces resulted in the "There are no pages selected to print" message. As stated in the report, I wanted to try the 4.0.1 version. But, unfortunately that wasn't available. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126543] New: Calc frequently becomes nonresponsive after rapid sequential paste (ctrl+v) operations
https://bz.apache.org/ooo/show_bug.cgi?id=126543
Issue ID: 126543
Issue Type: DEFECT
Summary: Calc frequently becomes nonresponsive after rapid
sequential paste (ctrl+v) operations
Product: Calc
Version: 4.1.1
Hardware: PC
OS: Windows 7
Status: UNCONFIRMED
Severity: major
Priority: P5
Component: editing
Assignee: issues@openoffice.apache.org
Reporter: deejar...@post.com
Calc frequently becomes nonresponsive after rapid sequential paste (ctrl+v)
operations of the same data into different cells. Task manager can not restore
control of the window. I have only been able to restore control by initiating a
shut down, and then canceling the save and the shut down. The offending cell is
left with a sizable frame in it, like a text box. after deleting this box,
normal operation is restored. The only other option seems to be to shut down
the application and loose the data added since the last autosave.
It doesn't happen every time, but seems to be related to the speed of
successive paste operations. The most recent failure I experienced, was after
two successive pastes of a short string ("Alan")copied from a cell two rows
above, pasted approximately 1 sec apart into two successive cells in the same
column. Prior to the paste the receiving cells were formatted default, and
there was no formatting included in the pasted data.
The previous occurrences have been similar, but usually after a few more paste
operations.
Not sure if it could have any bearing, but the spreadsheet contains one column
with mixed language text, English, Korean and Chinese with default formatting.
The column that was copied and pasted when the hangup occurred was all English
(Arial 10).
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126544] New: calc hangs with spinning icon when restoring after being minimized
https://bz.apache.org/ooo/show_bug.cgi?id=126544 Issue ID: 126544 Issue Type: DEFECT Summary: calc hangs with spinning icon when restoring after being minimized Product: Calc Version: 4.1.1 Hardware: Mac OS: Mac OSX, 10.9 Status: UNCONFIRMED Severity: normal Priority: P5 Component: ui Assignee: issues@openoffice.apache.org Reporter: madcow...@gmail.com I keep a calc spreadsheet open pretty much all the time. Lately (in the last release or two) when restoring from being minimized, calc hangs with a spinning icon. OS X reports the app as unresponsive. The spreadsheet is kind of large, but the symptom continues even after significantly reducing the size (I've reduced the size by about 90%, i.e. to 10% of its former size, and the issue has not gone away). After killing the app (force quit), I can restart it and it recovers, but there's clearly some kind of bug here. The specific spreadsheet I'm using has kind of sensitive information. If this has not been otherwise reported I'd be happy to try to reproduce this with a spreadsheet I'd be willing to attach to this bugzilla. I'm using version 4.1.1 on a Mac running OS X 10.9.5 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126544] calc hangs with spinning icon when restoring after being minimized
https://bz.apache.org/ooo/show_bug.cgi?id=126544 --- Comment #1 from Rick --- Forgot to mention - this doesn't always happen but seems to happen fairly often if the app has been minimized for a while (like a day or two). -- You are receiving this mail because: You are the assignee for the issue.
