[Bug 60462] indexedColors not extracted when stored in styles.xml

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60462

bknip...@abinitio.com changed:

   What|Removed |Added

 CC||bknip...@abinitio.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 60462] New: indexedColors not extracted when stored in styles.xml

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60462

Bug ID: 60462
   Summary: indexedColors not extracted when stored in styles.xml
   Product: POI
   Version: 3.15-FINAL
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XSSF
  Assignee: dev@poi.apache.org
  Reporter: bknip...@abinitio.com
  Target Milestone: ---

Created attachment 34513
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34513=edit
example workbook

The attached spreadsheet originally created with an earlier Excel, but recently
modified, has a fill foreground set for A1 on 'mixed' sheet.

from sheet1.xml:



from styles.xml

Here is xf #2:






Here is fill #43:






and here are the first 8 indexedColors:













The correct color here is 00FF00FF (magenta), and that is what any version of
excel shows when reading this wb. However, using getFillForegroundColor() on
XSSFCellFill returns '' because it simply looks it up in the
indexedColors enum. But that enum only describes the default indexedColors. If
indexedColors is stored in the wb, those should be used during extraction

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 60460] Null pointer exception in ExternSheetNameResolver.prependSheetName method

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60460

--- Comment #3 from Ricky  ---
Move this bug from HSSF to SS common component.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 60460] Null pointer exception in ExternSheetNameResolver.prependSheetName method

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60460

Ricky  changed:

   What|Removed |Added

  Component|HSSF|SS Common

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 60459] Null pointer exception in ExternSheetNameResolver.prependSheetName method

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60459

Ricky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Ricky  ---
Refresh page causing duplicate defects.

*** This bug has been marked as a duplicate of bug 60460 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 58237] Unable to add image to a word document header using XWPF

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58237

--- Comment #14 from Mark Murphy  ---
I believe the issue is in XWPFRun.addPicture(...)

This block of code:

CTBlipFillProperties blipFill = pic.addNewBlipFill();
CTBlip blip = blipFill.addNewBlip();
blip.setEmbed(parent.getDocument().getRelationId(picData));
blipFill.addNewStretch().addNewFillRect();

retrieves the main document rather than the document part containing the image,
and attempts to retrieve the relation id from that. This works when the image
is in the main document, but not when the image is in another part such as a
header or footer. In fact, the missing element in the header and footer is the
relation ID. I believe I can write some unit tests to prove this out.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 58237] Unable to add image to a word document header using XWPF

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58237

nicola.iso...@gmail.com changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #13 from nicola.iso...@gmail.com ---
Hopefuly I'm adding the necessary infos.

Here's the class I used to generate the docx: http://pastebin.com/UT4RS8ah

Here's a link to the generated .docx:
https://drive.google.com/file/d/0B2TPcgQDtWuiM0VJZEs5ZVFFdlE/view?usp=sharing

I don't know how to write a Unit Test for this problem but I hope the files I
provided together with the infos from the stackoverflow thread can help track
down the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

JDK 9 b148 including a refresh of the module system is available on java.net

[Rory O'Donnell]

Hi Dominik,


JDK 9 build b148  includes an important 
Refresh of the module system [1] , summary of changes are listed here 
.


*This refresh includes a disruptive change that is important to understand.

*For those that have been trying out modules with regular JDK 9 builds 
then be aware that `requires public` changes to `requires transitive`. 
In addition, the binary representation of the module declaration 
(module-info.class) has changed so that you need to recompile any 
modules that were compiled with previous JDK 9 builds.


As things stand today in JDK 9 then you use setAccessible to break into 
non-public elements of any type in exported packages. However, it cannot 
be used to break into any type in non-exported package. The current 
specified behavior was a compromise for the initial integration of the 
module system. It is of course not very satisfactory, hence the 
#AwkwardStrongEncapsulation issue [2] on the JSR 376 issues list. With 
the updated proposal in the JSR, this refresh changes setAccessible 
further so that it cannot be used to break into non-public types, or 
non-public elements of public types, in exported packages. Code that 
uses setAccessible to hack into the private constructor of 
java.lang.invoke.MethodHandles.Lookup will be disappointed for example.


This change will expose hacks in many existing libraries and tools. As a 
workaround then a new command line option `--add-opens` can be used to 
open specific packages for "deep reflection". For example, a really 
popular build tool fails with this refresh because it uses setAccessible 
+ core reflection to hack into a private field of an unmodifiable 
collection so that it can mutate it, facepalm! This code will continue 
to work as before when run with `--add-opens 
java.base/java.util=ALL-UNNAMED` to open the package java.util in module 
java.base to "all unnamed modules" (think class path).


*Any help reporting issues to popular tools and libraries would be 
appreciated. *


A debugging aid that is useful to identify issues is to run with 
-Dsun.reflect.debugModuleAccessChecks=true to get a stack trace when 
setAccessible fails, this is particularly useful when code swallows 
exceptions without any logging.



Rgds,Rory


[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005276.html 

[2] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[Bug 60184] Saved file that uses a XSSFFont without a specifically set FontFamily won't open in Excel

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60184

--- Comment #6 from Marek Branicky  ---
Guys is this fixed in version POI 3.15 or do you plan to fix it in near future?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org