[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472562#comment-16472562
 ] 

John Hewson commented on PDFBOX-4219:
-

Hmm, looks like this is to support nested reading of tables, such as the 
HorizontalMetricsTable.read which starts by calling getHorizontalHeader

> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png, 
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png, 
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf, 
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png, 
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png, 
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is 
> somehow related to several threads initializing standard 14 fonts. It happens 
> only about every 25 times in a test program I created. That one renders 2 
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses 
> the glyf table, and both change the stream position. I tried several things 
> in the last months to avoid it, all were unsuccessful and I lost my notes 
> about it last winter due to a static discharge on a usb stick. (Thank you 
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException: 
> java.io.IOException: Unexpected end of TTF stream reached
>   at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
>   at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
>   at 
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
>   at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
>   at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
>   at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
>   at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
>   at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
>   at 
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
>   at 
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
>   at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
>   at 
> org.apache.pdfbox.conten

[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472451#comment-16472451
 ] 

John Hewson commented on PDFBOX-4219:
-

{quote}
My theory is that one thread accesses the naming table and another accesses the 
glyf table, and both change the stream position. 
{quote}

Access to read these tables is via getTable which is synchronized, so that 
shouldn't be happening. But readTable looks very strange to me:

{code}
void readTable(TTFTable table) throws IOException
{
// save current position
long currentPosition = data.getCurrentPosition();
data.seek(table.getOffset());
table.read(this, data);
// restore current position
data.seek(currentPosition);
}
{code}

Why would the current position need saving? No subsequent calls to readTable 
should rely on this!?

> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png, 
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png, 
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf, 
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png, 
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png, 
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is 
> somehow related to several threads initializing standard 14 fonts. It happens 
> only about every 25 times in a test program I created. That one renders 2 
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses 
> the glyf table, and both change the stream position. I tried several things 
> in the last months to avoid it, all were unsuccessful and I lost my notes 
> about it last winter due to a static discharge on a usb stick. (Thank you 
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException: 
> java.io.IOException: Unexpected end of TTF stream reached
>   at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
>   at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
>   at 
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
>   at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
>   at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.

[jira] [Comment Edited] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472366#comment-16472366
 ] 

John Hewson edited comment on PDFBOX-4219 at 5/11/18 5:58 PM:
--

I can't reproduce this on my Mac which uses {{Times-Roman}} as the fallback 
font instead.


was (Author: jahewson):
I can't reproduce this on my Mac which uses {{Times-Roman}} as the substitute 
font instead.

> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png, 
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png, 
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf, 
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png, 
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png, 
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is 
> somehow related to several threads initializing standard 14 fonts. It happens 
> only about every 25 times in a test program I created. That one renders 2 
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses 
> the glyf table, and both change the stream position. I tried several things 
> in the last months to avoid it, all were unsuccessful and I lost my notes 
> about it last winter due to a static discharge on a usb stick. (Thank you 
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException: 
> java.io.IOException: Unexpected end of TTF stream reached
>   at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
>   at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
>   at 
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
>   at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
>   at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
>   at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
>   at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
>   at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
>   at 
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
>   at 
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
> 

[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472366#comment-16472366
 ] 

John Hewson commented on PDFBOX-4219:
-

I can't reproduce this on my Mac which uses {{Times-Roman}} as the substitute 
font instead.

> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png, 
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png, 
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf, 
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png, 
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png, 
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is 
> somehow related to several threads initializing standard 14 fonts. It happens 
> only about every 25 times in a test program I created. That one renders 2 
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses 
> the glyf table, and both change the stream position. I tried several things 
> in the last months to avoid it, all were unsuccessful and I lost my notes 
> about it last winter due to a static discharge on a usb stick. (Thank you 
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException: 
> java.io.IOException: Unexpected end of TTF stream reached
>   at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
>   at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
>   at 
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
>   at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
>   at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
>   at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
>   at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
>   at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
>   at 
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
>   at 
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
>   at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
>   at 
> org.apache.pdfbox.contentstream

[jira] [Issue Comment Deleted] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts

[John Hewson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-4219:

Comment: was deleted

(was: Do you have the Galliard font on your system? I get:

{code}
WARNING: Using fallback font Times-Bold for Galliard-Bold
WARNING: Using fallback font Times-Roman for Galliard-Roman
WARNING: Using fallback font Times-Italic for Galliard-Italic
{code})

> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png, 
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png, 
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf, 
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png, 
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png, 
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is 
> somehow related to several threads initializing standard 14 fonts. It happens 
> only about every 25 times in a test program I created. That one renders 2 
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses 
> the glyf table, and both change the stream position. I tried several things 
> in the last months to avoid it, all were unsuccessful and I lost my notes 
> about it last winter due to a static discharge on a usb stick. (Thank you 
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException: 
> java.io.IOException: Unexpected end of TTF stream reached
>   at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
>   at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
>   at 
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
>   at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
>   at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
>   at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
>   at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
>   at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
>   at 
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
>   at 
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
>   at org.apache.pdfbox

[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472305#comment-16472305
 ] 

John Hewson commented on PDFBOX-4219:
-

Do you have the Galliard font on your system? I get:

{code}
WARNING: Using fallback font Times-Bold for Galliard-Bold
WARNING: Using fallback font Times-Roman for Galliard-Roman
WARNING: Using fallback font Times-Italic for Galliard-Italic
{code}

> Multithreading problem when rendering several documents with Standard 14 fonts
> --
>
> Key: PDFBOX-4219
> URL: https://issues.apache.org/jira/browse/PDFBOX-4219
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Rendering
>Affects Versions: 2.0.9, 3.0.0 PDFBox
> Environment: Windows 7
> jdk1.8.0_172
>Reporter: Tilman Hausherr
>Priority: Major
>  Labels: multi-threading, multithreading
> Attachments: 014261-p3-ccitt.pdf, 014261-p3-ccitt.pdf-1-bad1.png, 
> 014261-p3-ccitt.pdf-1-bad2.png, 014261-p3-ccitt.pdf-1-bad3.png, 
> 014261-p3-ccitt.pdf-1.png, 166292-fi-ligature.pdf, 
> 166292-fi-ligature.pdf-1-bad1.png, 166292-fi-ligature.pdf-1-bad2.png, 
> 166292-fi-ligature.pdf-1-bad3.png, 166292-fi-ligature.pdf-1.png, 
> MulithreadTest.java
>
>
> I get rendering errors and sometimes exceptions in my regression tests. It is 
> somehow related to several threads initializing standard 14 fonts. It happens 
> only about every 25 times in a test program I created. That one renders 2 
> files in 4 threads and compares the result with the existing result.
> My theory is that one thread accesses the naming table and another accesses 
> the glyf table, and both change the stream position. I tried several things 
> in the last months to avoid it, all were unsuccessful and I lost my notes 
> about it last winter due to a static discharge on a usb stick. (Thank you 
> KINGSTON!)
> Here's the output when it doesn't go well:
> {noformat}
> 11.05.2018 10:54:26.322 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.323 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-BoldMT for Galliard-Bold
> 11.05.2018 10:54:26.386 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.421 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPSMT for Galliard-Roman
> 11.05.2018 10:54:26.697 WARN  [pool-1-thread-2] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> 11.05.2018 10:54:26.818 WARN  [pool-1-thread-4] 
> org.apache.pdfbox.pdmodel.font.PDType1Font:296 - Using fallback font 
> TimesNewRomanPS-ItalicMT for Galliard-Italic
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\166292-fi-ligature.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> C:\Users\XXX\Documents\Java\PDFBox 
> reactor\pdfbox\src\test\resources\input\rendering\014261-p3-ccitt.pdf
> oh oh
> done
> {noformat}
> Sometimes in the past I got exceptions:
> {noformat}
> Exception in thread "Thread-2" java.lang.RuntimeException: 
> java.io.IOException: Unexpected end of TTF stream reached
>   at pdfboxpageimageextraction.MulithreadTest.run(MulithreadTest.java:87)
> Caused by: java.io.IOException: Unexpected end of TTF stream reached
>   at org.apache.fontbox.ttf.TTFDataStream.read(TTFDataStream.java:274)
>   at 
> org.apache.fontbox.ttf.TTFDataStream.readString(TTFDataStream.java:91)
>   at org.apache.fontbox.ttf.NamingTable.read(NamingTable.java:113)
>   at org.apache.fontbox.ttf.TrueTypeFont.readTable(TrueTypeFont.java:373)
>   at org.apache.fontbox.ttf.TrueTypeFont.getTable(TrueTypeFont.java:163)
>   at org.apache.fontbox.ttf.TrueTypeFont.getNaming(TrueTypeFont.java:179)
>   at org.apache.fontbox.ttf.TrueTypeFont.getName(TrueTypeFont.java:471)
>   at 
> org.apache.pdfbox.pdmodel.font.PDType1Font.(PDType1Font.java:296)
>   at 
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
>   at org.apache.pd

[jira] [Comment Edited] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472256#comment-16472256
 ] 

John Hewson edited comment on PDFBOX-4220 at 5/11/18 4:56 PM:
--

[~tilman] Thread safety is only part of the problem, the overall problem is 
actually that fonts are shared objects. In other words the following situations 
cause problems: 1) reuse of a font within just one document (e.g. imagine using 
Arial Unicode MS to write some Arabic with those features enabled, then turning 
them off and writing some English - the subsetter now has an inconsistent view 
of the font). 2) Reuse of a font between documents (e.g. if I'm writing with 
the same TTF font file to two PDF files even with just one thread, fonts are 
shared between them). 3) Reuse of a font across threads - this is just a more 
general version of (2).

The fix will be to move the enabled/disabled feature state out of the font. 
This actually works out nicely because features don't belong at the font-level 
but at the text-level. One expects to have an API such as showText(string, 
List) which allows features to be changed many times while working 
with a single font (an example would be the "dlig" feature which enables 
discretionary stylistic ligatures to add some visual decoration, perhaps for a 
title or heading).


was (Author: jahewson):
[~tilman] Thread safety is only part of the problem, the overall problem is 
actually that fonts are shared objects. In other words the following situations 
cause problems: 1) reuse of a font within just one document (e.g. imagine using 
Arial Unicode MS to write some Arabic with those features enabled, then turning 
them off and writing some English - the subsetter now has an inconsistent view 
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF 
files using just one thread, then fonts will be shared between them). 3) Reuse 
of a font across threads - this is just a more general version of (2).

The fix will be to move the enabled/disabled feature state out of the font. 
This actually works out nicely because features don't belong at the font-level 
but at the text-level. One expects to have an API such as showText(string, 
List) which allows features to be changed many times while working 
with a single font (an example would be the "dlig" feature which enables 
discretionary stylistic ligatures to add some visual decoration, perhaps for a 
title or heading).

> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for 
> PDFBOX-4189 I've encountered some significant issues related to this feature. 
> Given that this was shipped in 2.0.9, we're likely going to face some hard 
> choices.
> Most of the handling of vertical text in this patch is fine. It generally 
> does a good job of handling the intricacies of both PDF and OpenType and 
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are 
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in 
> FontBox must be thread safe - they are cached and shared globally between all 
> PDDocument instances. For this reason a FontBoxFont must not contain any 
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
>  {{enableGsubFeature(String)}}
>  {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
>  {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will 
> clobber the corresponding state for all other threads. This problem can even 
> occur if the user is manipulating more than one document within a single 
> thread. *There's no way around this and no way to fix these methods* - 
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited 
> to just FontBox'

[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472265#comment-16472265
 ] 

John Hewson commented on PDFBOX-4189:
-

See PDFBOX-4220 for work on those problems.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472260#comment-16472260
 ] 

John Hewson edited comment on PDFBOX-4220 at 5/11/18 4:51 PM:
--

Comment from PDFBOX-4106:

{quote}
Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into 
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only 
non-obvious thing that I want to mention is that it's important to be able to 
selectively enable/disable vrt2. The reason is that the substitutions performed 
by vrt2 are not always more desirable than vert, and it is common to want to 
use only vert substitutions with a font that supports both.
{quote}


was (Author: jahewson):
Comment from PDFBOX-4106:

{quote}
amake Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into 
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only 
non-obvious thing that I want to mention is that it's important to be able to 
selectively enable/disable vrt2. The reason is that the substitutions performed 
by vrt2 are not always more desirable than vert, and it is common to want to 
use only vert substitutions with a font that supports both.
{quote}

> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for 
> PDFBOX-4189 I've encountered some significant issues related to this feature. 
> Given that this was shipped in 2.0.9, we're likely going to face some hard 
> choices.
> Most of the handling of vertical text in this patch is fine. It generally 
> does a good job of handling the intricacies of both PDF and OpenType and 
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are 
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in 
> FontBox must be thread safe - they are cached and shared globally between all 
> PDDocument instances. For this reason a FontBoxFont must not contain any 
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
>  {{enableGsubFeature(String)}}
>  {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
>  {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will 
> clobber the corresponding state for all other threads. This problem can even 
> occur if the user is manipulating more than one document within a single 
> thread. *There's no way around this and no way to fix these methods* - 
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited 
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
> obscure methods which have only been around for a few weeks. It's unlikely 
> that _any_ users would be affected by their removal. Obviously the missing 
> functionality will be implemented in the appropriate location*, so vertical 
> text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
> stands we have just shipped a breaking functionality change to 2.0 and broken 
> existing functionality in an irreparable manner, and that seems worse. 
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472260#comment-16472260
 ] 

John Hewson commented on PDFBOX-4220:
-

Comment from PDFBOX-4106:

{quote}
amake Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into 
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only 
non-obvious thing that I want to mention is that it's important to be able to 
selectively enable/disable vrt2. The reason is that the substitutions performed 
by vrt2 are not always more desirable than vert, and it is common to want to 
use only vert substitutions with a font that supports both.
{quote}

> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for 
> PDFBOX-4189 I've encountered some significant issues related to this feature. 
> Given that this was shipped in 2.0.9, we're likely going to face some hard 
> choices.
> Most of the handling of vertical text in this patch is fine. It generally 
> does a good job of handling the intricacies of both PDF and OpenType and 
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are 
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in 
> FontBox must be thread safe - they are cached and shared globally between all 
> PDDocument instances. For this reason a FontBoxFont must not contain any 
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
>  {{enableGsubFeature(String)}}
>  {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
>  {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will 
> clobber the corresponding state for all other threads. This problem can even 
> occur if the user is manipulating more than one document within a single 
> thread. *There's no way around this and no way to fix these methods* - 
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited 
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
> obscure methods which have only been around for a few weeks. It's unlikely 
> that _any_ users would be affected by their removal. Obviously the missing 
> functionality will be implemented in the appropriate location*, so vertical 
> text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
> stands we have just shipped a breaking functionality change to 2.0 and broken 
> existing functionality in an irreparable manner, and that seems worse. 
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472256#comment-16472256
 ] 

John Hewson commented on PDFBOX-4220:
-

[~tilman] Thread safety is only part of the problem, the overall problem is 
actually that fonts are shared objects. In other words the following situations 
cause problems: 1) reuse of a font within just one document (e.g. imagine using 
Arial Unicode MS to write some Arabic with those features enabled, then turning 
them off and writing some English - the subsetter now has an inconsistent view 
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF 
files using just one thread, then fonts will be shared between them). 3) Reuse 
of a font across threads - this is just a more general version of (2).

The fix will be to move the enabled/disabled feature state out of the font. 
This actually works out nicely because features don't belong at the font-level 
but at the text-level. One expects to have an API such as showText(string, 
List) which allows features to be changed many times while working 
with a single font (an example would be the "dlig" feature which enables 
discretionary stylistic ligatures to add some visual decoration, perhaps for a 
title or heading).

> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>    Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for 
> PDFBOX-4189 I've encountered some significant issues related to this feature. 
> Given that this was shipped in 2.0.9, we're likely going to face some hard 
> choices.
> Most of the handling of vertical text in this patch is fine. It generally 
> does a good job of handling the intricacies of both PDF and OpenType and 
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are 
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in 
> FontBox must be thread safe - they are cached and shared globally between all 
> PDDocument instances. For this reason a FontBoxFont must not contain any 
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
>  {{enableGsubFeature(String)}}
>  {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
>  {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will 
> clobber the corresponding state for all other threads. This problem can even 
> occur if the user is manipulating more than one document within a single 
> thread. *There's no way around this and no way to fix these methods* - 
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited 
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
> obscure methods which have only been around for a few weeks. It's unlikely 
> that _any_ users would be affected by their removal. Obviously the missing 
> functionality will be implemented in the appropriate location*, so vertical 
> text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
> stands we have just shipped a breaking functionality change to 2.0 and broken 
> existing functionality in an irreparable manner, and that seems worse. 
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472255#comment-16472255
 ] 

John Hewson commented on PDFBOX-4220:
-

Just to re-cap:

{quote}
Tilman Hausherr added a comment
So the problem is that a TrueTypeFont object could be reused by several 
threads, and the gsub feature vrt2 may be enabled in one and disabled in 
another?
{quote}

> FontBox sets GSUB features globally across shared fonts
> ---
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Affects Versions: 2.0.9, 3.0.0 PDFBox
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for 
> PDFBOX-4189 I've encountered some significant issues related to this feature. 
> Given that this was shipped in 2.0.9, we're likely going to face some hard 
> choices.
> Most of the handling of vertical text in this patch is fine. It generally 
> does a good job of handling the intricacies of both PDF and OpenType and 
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are 
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in 
> FontBox must be thread safe - they are cached and shared globally between all 
> PDDocument instances. For this reason a FontBoxFont must not contain any 
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
>  {{enableGsubFeature(String)}}
>  {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
>  {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will 
> clobber the corresponding state for all other threads. This problem can even 
> occur if the user is manipulating more than one document within a single 
> thread. *There's no way around this and no way to fix these methods* - 
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited 
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
> obscure methods which have only been around for a few weeks. It's unlikely 
> that _any_ users would be affected by their removal. Obviously the missing 
> functionality will be implemented in the appropriate location*, so vertical 
> text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
> stands we have just shipped a breaking functionality change to 2.0 and broken 
> existing functionality in an irreparable manner, and that seems worse. 
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Closed] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson closed PDFBOX-4106.
---
Resolution: Fixed

I've migrated the new bug to PDFBOX-4220.

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 3.0.0 PDFBox, 2.0.9
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts

[John Hewson (JIRA)]

John Hewson created PDFBOX-4220:
---

 Summary: FontBox sets GSUB features globally across shared fonts
 Key: PDFBOX-4220
 URL: https://issues.apache.org/jira/browse/PDFBOX-4220
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox, Parsing, Writing
Affects Versions: 2.0.9, 3.0.0 PDFBox
Reporter: John Hewson
Assignee: John Hewson


Migrating the following issue from PDFBOX-4106:

{quote}
(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document within a single 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location*, so vertical 
text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
which is the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality change to 2.0 and broken 
existing functionality in an irreparable manner, and that seems worse. Thoughts?

\* And I have some ideas how to achieve this and am happy to do it
{quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472237#comment-16472237
 ] 

John Hewson commented on PDFBOX-4106:
-

[~amake], that's ok, don't worry about it. We should have been more 
conservative about what gets pushed to the stable branch. Thank you for all 
your hard work.

[~lehmi] Will do.

[~tilman] Thread safety is only part of the problem, the overall problem is 
actually that fonts are shared objects. In other words the following situations 
cause problems: 1) reuse of a font within just one document (e.g. imagine using 
Arial Unicode MS to write some Arabic with those features enabled, then turning 
them off and writing some English - the subsetter now has an inconsistent view 
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF 
files using just one thread, then fonts will be shared between them). 3) Reuse 
of a font across threads - this is just a more general version of (2).

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-4106:

Issue Type: New Feature  (was: Bug)

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471291#comment-16471291
 ] 

John Hewson edited comment on PDFBOX-4106 at 5/11/18 12:02 AM:
---

(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document within a single 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location*, so vertical 
text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
which is the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality change to 2.0 and broken 
existing functionality in an irreparable manner, and that seems worse. Thoughts?

* = And I have some ideas how to achieve this and am happy to do it


was (Author: jahewson):
(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document within a single 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location, so vertical text 
will still work in 2.0 and the existing PDType0Font.loadVertical API - which is 
the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality c

[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471291#comment-16471291
 ] 

John Hewson edited comment on PDFBOX-4106 at 5/11/18 12:02 AM:
---

(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document within a single 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location*, so vertical 
text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
which is the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality change to 2.0 and broken 
existing functionality in an irreparable manner, and that seems worse. Thoughts?

\* And I have some ideas how to achieve this and am happy to do it


was (Author: jahewson):
(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document within a single 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location*, so vertical 
text will still work in 2.0 and the existing PDType0Font.loadVertical API - 
which is the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality c

[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471291#comment-16471291
 ] 

John Hewson edited comment on PDFBOX-4106 at 5/11/18 12:00 AM:
---

(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document within a single 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location, so vertical text 
will still work in 2.0 and the existing PDType0Font.loadVertical API - which is 
the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality change to 2.0 and broken 
existing functionality in an irreparable manner, and that seems worse. Thoughts?


was (Author: jahewson):
(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document with even just one 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location, so vertical text 
will still work in 2.0 and the existing PDTyoe0Font.loadVertical API - which is 
the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality change to 2.0 and broken 
existing fun

[jira] [Comment Edited] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471296#comment-16471296
 ] 

John Hewson edited comment on PDFBOX-4189 at 5/10/18 11:56 PM:
---

I'm trying to get ToUnicodeMap generation working properly with GSUB but have 
hit problems introduced by PDFBOX-4106. We'll have to resolve that before I can 
proceed here.


was (Author: jahewson):
I'm trying to ToUnicodeMap generation working properly but have hit problems 
introduced by PDFBOX-4106. We'll have to resolve that before I can proceed here.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471296#comment-16471296
 ] 

John Hewson commented on PDFBOX-4189:
-

I'm trying to ToUnicodeMap generation working properly but have hit problems 
introduced by PDFBOX-4106. We'll have to resolve that before I can proceed here.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Reopened] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson reopened PDFBOX-4106:
-

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-4106:

Issue Type: Bug  (was: New Feature)

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: Bug
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4106) Vertical text creation

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471291#comment-16471291
 ] 

John Hewson commented on PDFBOX-4106:
-

(!) So we have a problem. While looking at building a proper ToUnicodeMap for 
PDFBOX-4189 I've encountered some significant issues related to this feature. 
Given that this was shipped in 2.0.9, we're likely going to face some hard 
choices.

Most of the handling of vertical text in this patch is fine. It generally does 
a good job of handling the intricacies of both PDF and OpenType and juggling 
the sometimes competing concerns.

The issue is that the new APIs added to FontBox's TrueTypeFont are incompatible 
with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox must be 
thread safe - they are cached and shared globally between all PDDocument 
instances. For this reason a FontBoxFont must not contain any document-specific 
state.

The following fields added to TrueTypeFont contain document-specific state:

{{List enabledGsubFeatures}}

The following methods added to TrueTypeFont write document-specific state:

{{enableVerticalSubstitutions()}}
 {{enableGsubFeature(String)}}
 {{disableGsubFeature(String)}}

The following methods added to TrueTypeFont read document-specific state:

{{getUnicodeCmapLookup()}}
 {{getUnicodeCmapLookup(boolean)}}

None of the additions are thread safe, anyone who calls these methods will 
clobber the corresponding state for all other threads. This problem can even 
occur if the user is manipulating more than one document with even just one 
thread. *There's no way around this and no way to fix these methods* - 
document-specific state can't live in shared global fonts :(

(flag) Tough choices: Given that these are all just auxiliary methods limited 
to just FontBox's TrueTypeFont class, we _could_ remove them. These are very 
obscure methods which have only been around for a few weeks. It's unlikely that 
_any_ users would be affected by their removal. Obviously the missing 
functionality will be implemented in the appropriate location, so vertical text 
will still work in 2.0 and the existing PDTyoe0Font.loadVertical API - which is 
the only thing that matters - will remain unchanged! :)

Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it 
stands we have just shipped a breaking functionality change to 2.0 and broken 
existing functionality in an irreparable manner, and that seems worse. Thoughts?

> Vertical text creation
> --
>
> Key: PDFBOX-4106
> URL: https://issues.apache.org/jira/browse/PDFBOX-4106
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, Parsing, Writing
>Reporter: Aaron Madlon-Kay
>Assignee: Tilman Hausherr
>Priority: Major
>  Labels: embed, gsub, parsing, vertical
> Fix For: 2.0.9, 3.0.0 PDFBox
>
> Attachments: 
> 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-for-c.patch, 
> 0002-Optimize-Unicode-script-storage-and-lookup.patch, 
> 0003-Parse-GSUB-table.patch, 
> 0004-Abstract-cmap-lookup-into-an-interface.patch, 
> 0005-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0006-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0007-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0008-Implement-vertical-metrics-support-when-embedding-subsetting.patch, 
> FIX-0001-PDFBOX-4106-Remove-early-outs-leading-to-spurious-wa.patch, 
> FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTable-public-m.patch, 
> FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.patch, 
> FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, 
> FIX-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, 
> FIX-0006-PDFBOX-4106-Fix-non-embedded-vertical-font-rendering.patch, 
> FIX-0007-PDFBOX-4106-Fix-incorrect-parsing-of-W2-first-format.patch, 
> FIX-0008-PDFBOX-4106-Rename-misleading-field.patch, 
> FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBearing.patch, 
> FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/&

[jira] [Comment Edited] (PDFBOX-4068) Create ContentStream for XObject forms and tiling patterns

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470682#comment-16470682
 ] 

John Hewson edited comment on PDFBOX-4068 at 5/10/18 4:38 PM:
--

Ok, the problems I [mentioned above|#comment-16469705] are now fixed :)


was (Author: jahewson):
Ok, the problems I [mentioned 
above|https://issues.apache.org/jira/browse/PDFBOX-4068?focusedCommentId=16469705]
 are now fixed :)

> Create ContentStream for XObject forms and tiling patterns
> --
>
> Key: PDFBOX-4068
> URL: https://issues.apache.org/jira/browse/PDFBOX-4068
> Project: PDFBox
>  Issue Type: Task
>  Components: PDModel
>Reporter: Tilman Hausherr
>Priority: Major
>
> We have a {{PDAppearanceContentStream}} for appearances but nothing for 
> XObject forms and tiling patterns.
> What we need should extend {{PDAbstractContentStream}} and should have a 
> constructor like
> {code:java}
> public PDFormContentStream(PDFormXObject form) throws IOException
> {code}
> Alternatively, why not replace {{PDAppearanceContentStream}} ? Its parameter 
> {{PDAppearanceStream}} is extended from {{PDFormXObject}} so we could just 
> use the base class.
> We need this both for 2.0 and 3.* - we have users who have a really hard time 
> fiddling with low level operators instead of using the methods.
> In 2.0 we could replace the parameter of {{PDPageContentStream}} that is 
> currently {{PDAppearanceStream}}. This would be a non breaking change.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4068) Create ContentStream for XObject forms and tiling patterns

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470682#comment-16470682
 ] 

John Hewson edited comment on PDFBOX-4068 at 5/10/18 4:37 PM:
--

Ok, the problems I [mentioned 
above|https://issues.apache.org/jira/browse/PDFBOX-4068?focusedCommentId=16469705]
 are now fixed :)


was (Author: jahewson):
Ok, the problems I [mentioned above|#comment-16469705] are now fixed :)

> Create ContentStream for XObject forms and tiling patterns
> --
>
> Key: PDFBOX-4068
> URL: https://issues.apache.org/jira/browse/PDFBOX-4068
> Project: PDFBox
>  Issue Type: Task
>  Components: PDModel
>Reporter: Tilman Hausherr
>Priority: Major
>
> We have a {{PDAppearanceContentStream}} for appearances but nothing for 
> XObject forms and tiling patterns.
> What we need should extend {{PDAbstractContentStream}} and should have a 
> constructor like
> {code:java}
> public PDFormContentStream(PDFormXObject form) throws IOException
> {code}
> Alternatively, why not replace {{PDAppearanceContentStream}} ? Its parameter 
> {{PDAppearanceStream}} is extended from {{PDFormXObject}} so we could just 
> use the base class.
> We need this both for 2.0 and 3.* - we have users who have a really hard time 
> fiddling with low level operators instead of using the methods.
> In 2.0 we could replace the parameter of {{PDPageContentStream}} that is 
> currently {{PDAppearanceStream}}. This would be a non breaking change.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4068) Create ContentStream for XObject forms and tiling patterns

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470682#comment-16470682
 ] 

John Hewson commented on PDFBOX-4068:
-

Ok, the problems I [mentioned above|#comment-16469705] are now fixed :)

> Create ContentStream for XObject forms and tiling patterns
> --
>
> Key: PDFBOX-4068
> URL: https://issues.apache.org/jira/browse/PDFBOX-4068
> Project: PDFBox
>  Issue Type: Task
>  Components: PDModel
>Reporter: Tilman Hausherr
>Priority: Major
>
> We have a {{PDAppearanceContentStream}} for appearances but nothing for 
> XObject forms and tiling patterns.
> What we need should extend {{PDAbstractContentStream}} and should have a 
> constructor like
> {code:java}
> public PDFormContentStream(PDFormXObject form) throws IOException
> {code}
> Alternatively, why not replace {{PDAppearanceContentStream}} ? Its parameter 
> {{PDAppearanceStream}} is extended from {{PDFormXObject}} so we could just 
> use the base class.
> We need this both for 2.0 and 3.* - we have users who have a really hard time 
> fiddling with low level operators instead of using the methods.
> In 2.0 we could replace the parameter of {{PDPageContentStream}} that is 
> currently {{PDAppearanceStream}}. This would be a non breaking change.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469993#comment-16469993
 ] 

John Hewson commented on PDFBOX-4189:
-

As part of PDFBOX-4068, I've consolidated all text handling in 
PDAbstractContentStream. So the relevant code from PDPageContentStream can now 
be found there.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4068) Create ContentStream for XObject forms and tiling patterns

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469705#comment-16469705
 ] 

John Hewson commented on PDFBOX-4068:
-

Hi guys, I've been taking a look at the code from PDFBOX-4189 and there are a 
few problems related to this change which I've uncovered. There's some 
copy-paste duplicated code in both PDAbstractContentStream and 
PDPageContentStream which has led to PDPageContentStream having its own local 
copies of the font stack (!). Also as PDPageContentStream was copied to create 
PDAbstractContentStream but made non-final, all the methods now need to be 
final. Finally, unless we want users to subclass PDAbstractContentStream (and 
given that PDPageContentStream was previously final, I presume we don't) then 
all the PDAbstractContentStream subclasses need to be in the same package.

> Create ContentStream for XObject forms and tiling patterns
> --
>
> Key: PDFBOX-4068
> URL: https://issues.apache.org/jira/browse/PDFBOX-4068
> Project: PDFBox
>  Issue Type: Task
>  Components: PDModel
>Reporter: Tilman Hausherr
>Priority: Major
>
> We have a {{PDAppearanceContentStream}} for appearances but nothing for 
> XObject forms and tiling patterns.
> What we need should extend {{PDAbstractContentStream}} and should have a 
> constructor like
> {code:java}
> public PDFormContentStream(PDFormXObject form) throws IOException
> {code}
> Alternatively, why not replace {{PDAppearanceContentStream}} ? Its parameter 
> {{PDAppearanceStream}} is extended from {{PDFormXObject}} so we could just 
> use the base class.
> We need this both for 2.0 and 3.* - we have users who have a really hard time 
> fiddling with low level operators instead of using the methods.
> In 2.0 we could replace the parameter of {{PDPageContentStream}} that is 
> currently {{PDAppearanceStream}}. This would be a non breaking change.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469657#comment-16469657
 ] 

John Hewson commented on PDFBOX-4189:
-

AWT is a moving target, while the API hasn't changed in years, the internal 
implementation changes from one JDK release to the next, even making large 
changes such as replacing ICU with HarfBuzz under the hood. So while some old 
awt.Font bugs have been fixed, there are likely new ones which we'd rather not 
expose ourselves to.

I'd suggest that we adopt an API which provides something which behaves like a 
GlyphVector, as it's a well-designed API. But I don't think we should actually 
use AWT within PDFBox.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467728#comment-16467728
 ] 

John Hewson edited comment on PDFBOX-4189 at 5/8/18 5:51 PM:
-

{quote}
Maruan Sahyoun added a comment - 29/Apr/18 08:36
Tilman Hausherr Palash Ray could we get a method which returns the 
glyphs/ids/code to use together with the metrics information for a string? 
{quote}

That's exactly what a GlyphVector is. Might be what we need here...


was (Author: jahewson):
{quote}
Maruan Sahyoun added a comment - 29/Apr/18 08:36
Tilman Hausherr Palash Ray could we get a method which returns the 
glyphs/ids/code to use together with the metrics information for a string? 
{quote}

That's exactly what a GlyphVector is.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467728#comment-16467728
 ] 

John Hewson commented on PDFBOX-4189:
-

{quote}
Maruan Sahyoun added a comment - 29/Apr/18 08:36
Tilman Hausherr Palash Ray could we get a method which returns the 
glyphs/ids/code to use together with the metrics information for a string? 
{quote}

That's exactly what a GlyphVector is.

> Enable PDF creation with Indian languages, by reading and utilizing the GSUB 
> table
> --
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf, 
> BengaliPdfGenerationHelloWorld.java, bengali-example.pdf, 
> bengali-example2.pdf, bengali-example3.pdf, committed.patch, screenshot.png
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438914#comment-16438914
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/16/18 1:45 AM:
--

{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code we have for forms, for example). So in layout 
we're really only going to be concerned with GPOS and GSUB features. That way 
the only options that one might want to pass to layout would be the list of 
which [feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

Maybe layout() should be called shapeText() to emphasize this distinction?


was (Author: jahewson):
{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code we have for forms, for example). So in layout 
we're really only going to be concerned with GPOS and GSUB features. That way 
the only options that one might want to pass to layout would be this list of 
which [feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

Maybe layout() should be called shapeText() to emphasize this distinction?

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438914#comment-16438914
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/16/18 1:44 AM:
--

{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code we have for forms, for example). So in layout 
we're really only going to be concerned with GPOS and GSUB features. That way 
the only options that one might want to pass to layout would be this list of 
which [feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

Maybe layout() should be called shapeText() to emphasize this distinction?


was (Author: jahewson):
{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code form forms, for example). So in layout we're 
really only going to be concerned with GPOS and GSUB features. That way the 
only options that one might want to pass to layout would be this list of which 
[feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

Maybe layout() should be called shapeText() to emphasize this distinction?

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438914#comment-16438914
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/16/18 1:41 AM:
--

{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code form forms, for example). So in layout we're 
really only going to be concerned with GPOS and GSUB features. That way the 
only options that one might want to pass to layout would be this list of which 
[feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

Maybe layout() should be called shapeText() to emphasize this distinction?


was (Author: jahewson):
{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code form forms, for example). So in layout we're 
really only going to be concerned with GPOS and GSUB features. That way the 
only options that one might want to pass to layout would be this list of which 
[feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438914#comment-16438914
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/16/18 1:40 AM:
--

{quote}
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: 
https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt{quote}

It's probably worth noting that BASE, JSTF and BiDi are concerned with 
_paragraph-level_ layout, which happens at a higher level than the proposed 
layout() - which would be concerned with only a single script in a single 
direction (i.e. only OpenType _shaping_). BASE and BiDi are related to changes 
between different scripts, while JSTF is to aid in making good line break 
choices. So all of that functionality will happen somewhere else (this fits 
very closely with the layout code form forms, for example). So in layout we're 
really only going to be concerned with GPOS and GSUB features. That way the 
only options that one might want to pass to layout would be this list of which 
[feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.


was (Author: jahewson):
For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt

bq. here

BASE, JSTF and BiDi are concerned with _paragraph-level_ layout, which happens 
at a higher level than the proposed layout() - which would be concerned with 
only a single script in a single direction (i.e. only OpenType _shaping_). BASE 
and BiDi are related to changes between different scripts, while JSTF is to aid 
in making good line break choices. So all of that functionality will happen 
somewhere else (this fits very closely with the layout code form forms, for 
example). So in layout we're really only going to be concerned with GPOS and 
GSUB features. That way the only options that one might want to pass to layout 
would be this list of which [feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438914#comment-16438914
 ] 

John Hewson commented on PDFBOX-4189:
-

For correct text positioning using mixed language information from the 
following tables might be useful:
- GPOS: to adjust the glyph position
- BASE: baseline offsets on a script-by-script basis.
- JSTF: justification information, including whitespace and Kashida adjustments.
- BIDI Mirroring: https://www.unicode.org/Public/10.0.0/ucd/BidiMirroring.txt

bq. here

BASE, JSTF and BiDi are concerned with _paragraph-level_ layout, which happens 
at a higher level than the proposed layout() - which would be concerned with 
only a single script in a single direction (i.e. only OpenType _shaping_). BASE 
and BiDi are related to changes between different scripts, while JSTF is to aid 
in making good line break choices. So all of that functionality will happen 
somewhere else (this fits very closely with the layout code form forms, for 
example). So in layout we're really only going to be concerned with GPOS and 
GSUB features. That way the only options that one might want to pass to layout 
would be this list of which [feature 
flags|https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist] to 
apply.

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 1:04 AM:
--

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(no entry in the camp table). This should be easy to add to TTFSubsetter as it 
already tracks glyph ids internally, we just need the ability to pass them in 
too, e.g. addGlyphId(integer). Then PDPageContentStream#showText will be 
responsible for passing the glyph ids. But now we need showText to know about 
those glyph ids, which leads me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{final 
PDFGlyphVector layout(String text)}} which is called from 
PDPageContentStream#showText instead of encode(text). I also think it would be 
fine to use instanceof to detect this case, because only PDType0Font need have 
this capability. I'm assuming PDFGlyphVector is our own very simple version of 
the JDK's GlyphVector, which is effectively just a vector of (gid, dx, dy) 
tuples. Then all that PDPageContentStream#showText needs to know how to do is 
to draw a PDFGlyphVector on the page, by converting it into the equivalent text 
drawing operations (Tj and the like). Because this patch is just for GSUB, all 
of those positioning values can just be zero, and we need not implemented any 
actual glyph positioning in showText() yet :). Thus GlyphVector will serve 
simply as an array of GIDs.

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes. P.S. Make sure any new 
APIs are {{final}}. All of the suggestions above consist of adding only 
non-breaking APIs, which is nice.

Thanks!


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstract

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:57 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(no entry in the camp table). This should be easy to add to TTFSubsetter as it 
already tracks glyph ids internally, we just need the ability to pass them in 
too, e.g. addGlyphId(integer). Then PDPageContentStream#showText will be 
responsible for passing the glyph ids. But now we need showText to know about 
those glyph ids, which leads me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{final 
PDFGlyphVector layout(String text)}} which is called from 
PDPageContentStream#showText instead of encode(text). I also think it would be 
fine to use instanceof to detect this case, because only PDType0Font need have 
this capability. I'm assuming PDFGlyphVector is our own very simple version of 
the JDK's GlyphVector, which is effectively just a vector of (gid, dx, dy) 
tuples. Then all that PDPageContentStream#showText needs to know how to do is 
to draw a PDFGlyphVector on the page, by converting it into the equivalent text 
drawing operations (Tj and the like). Because this patch is just for GSUB, all 
of those positioning values can just be zero, and we need not implemented any 
actual glyph positioning in showText() yet :). Thus GlyphVector will serve 
simply as an array of GIDs.

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes. P.S. Make sure any new 
APIs are {{final}}.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenTyp

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:52 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(no entry in the camp table). This should be easy to add to TTFSubsetter as it 
already tracks glyph ids internally, we just need the ability to pass them in 
too, e.g. addGlyphId(integer). Then PDPageContentStream#showText will be 
responsible for passing the glyph ids. But now we need showText to know about 
those glyph ids, which leads me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{PDFGlyphVector 
layout(String text)}} which is called from PDPageContentStream#showText instead 
of encode(text). I also think it would be fine to use instanceof to detect this 
case, because only PDType0Font need have this capability. I'm assuming 
PDFGlyphVector is our own very simple version of the JDK's GlyphVector, which 
is effectively just a vector of (gid, dx, dy) tuples. Then all that 
PDPageContentStream#showText needs to know how to do is to draw a 
PDFGlyphVector on the page, by converting it into the equivalent text drawing 
operations (Tj and the like).

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText perform

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:51 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(no entry in the camp table). This should be easy to add to TTFSubsetter as it 
already tracks glyph ids internally, we just need the ability to pass them in 
too, e.g. addGlyphId(integer). Then PDPageContentStream#showText will be 
responsible for passing the glyph ids. But now we need showText to know about 
those glyph ids, which leads me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{PDFGlyphVector 
layout(String text)}} which is called from PDPageContentStream#showText. I also 
think it would be fine to use instanceof to detect this case, because only 
PDType0Font need have this capability. I'm assuming PDFGlyphVector is our own 
very simple version of the JDK's GlyphVector, which is effectively just a 
vector of (gid, dx, dy) tuples. Then all that PDPageContentStream#showText 
needs to know how to do is to draw a PDFGlyphVector on the page, by converting 
it into the equivalent text drawing operations (Tj and the like).

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning a

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:49 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(no entry in the camp table). This should be easy to add to TTFSubsetter as it 
already tracks glyph ids internally, we just need the ability to pass them in 
too. Then PDPageContentStream#showText will be responsible for passing the 
glyph ids. But now we need showText to know about those glyph ids, which leads 
me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{PDFGlyphVector 
layout(String text)}} which is called from PDPageContentStream#showText. I also 
think it would be fine to use instanceof to detect this case, because only 
PDType0Font need have this capability. I'm assuming PDFGlyphVector is our own 
very simple version of the JDK's GlyphVector, which is effectively just a 
vector of (gid, dx, dy) tuples. Then all that PDPageContentStream#showText 
needs to know how to do is to draw a PDFGlyphVector on the page, by converting 
it into the equivalent text drawing operations (Tj and the like).

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:48 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (but we can 
relax this a bit, as I explain below).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(and so have no entry in the camp table). This should be easy to add to 
TTFSubsetter as it already tracks glyph ids internally, we just need the 
ability to pass them in too. Then PDPageContentStream#showText will be 
responsible for passing the glyph ids. But now we need showText to know about 
those glyph ids, which leads me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{PDFGlyphVector 
layout(String text)}} which is called from PDPageContentStream#showText. I also 
think it would be fine to use instanceof to detect this case, because only 
PDType0Font need have this capability. I'm assuming PDFGlyphVector is our own 
very simple version of the JDK's GlyphVector, which is effectively just a 
vector of (gid, dx, dy) tuples. Then all that PDPageContentStream#showText 
needs to know how to do is to draw a PDFGlyphVector on the page, by converting 
it into the equivalent text drawing operations (Tj and the like).

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting,

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:47 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*OpenType*: In general, OpenType layouts consist of glyph _substitutions_ (via 
GSUB) and _positionings_ (via GPOS). Obviously it's not possible to handle 
positionings in PDFont#encode(), so that helps explain why showText() is the 
right place for OpenType, as showText performs both positioning and encoding. 
We also need to keep track of glyphs for subsetting, which is not possible in 
encode().

*Subsetting*: We currently track which glyphs need to be included in a subset 
by using their Unicode code point, but with GSUB enabled we will have to keep 
track of some substituted glyphs via their glyph id (GID), because the glyphs 
which result from a substitution don't necessarily have their own code points 
(and so have no entry in the camp table). This should be easy to add to 
TTFSubsetter as it already tracks glyph ids internally, we just need the 
ability to pass them in too. Then PDPageContentStream#showText will be 
responsible for passing the glyph ids. But now we need showText to know about 
those glyph ids, which leads me to

*Glyph IDs:* The JDK represents text which has been through OpenType layout as 
a 
[GlyphVector|https://docs.oracle.com/javase/7/docs/api/java/awt/font/GlyphVector.html]
 which encapsulates substitutions via GID and positioning via a transform 
associated with each glyph. PDFBox might want to do something similar, I think 
it would even be ok to add this to PDType0Font (because I'm suggesting a 
specific OpenType API so it doesn't interfere with our PDType0Font's 
non-OpenType assumption) in the form of a method such as: {{PDFGlyphVector 
layout(String text)}} which is called from PDPageContentStream#showText. I also 
think it would be fine to use instanceof to detect this case, because only 
PDType0Font need have this capability. I'm assuming PDFGlyphVector is our own 
very simple version of the JDK's GlyphVector, which is effectively just a 
vector of (gid, dx, dy) tuples. Then all that PDPageContentStream#showText 
needs to know how to do is to draw a PDFGlyphVector on the page, by converting 
it into the equivalent text drawing operations (Tj and the like).

Phew! That was a lot of information. Just to be clear, the current patch is not 
compatible with subsetting without making some changes.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*Technical Background*: In general, OpenType layouts consist of glyph 
_substitutions_ (via GSUB) and _positionings_ (via GPOS). Obviously it's not 
possible to handle positionings in PDFont#encode(), so that helps explain why 
showText() is the right place for OpenType, as showText performs both 
positioning and encoding.

> Enable rendering of 

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:17 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*Technical Background*: In general, OpenType layouts consist of 
glyph_substitutions_ (via GSUB) and _positionings_ (via GPOS). Obviously it's 
not possible to handle positionings in PDFont#encode(), so that helps explain 
why showText() is the right place for OpenType, as showText performs both 
positioning and encoding.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

In general, OpenType layouts consist of glyph_substitutions_ (via GSUB) and 
_positionings_ (via GPOS). Obviously it's not possible to handle positionings 
in PDFont#encode(), so that helps explain why showText() is the right place for 
OpenType, as showText performs both positioning and encoding.

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:17 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*Technical Background*: In general, OpenType layouts consist of glyph 
_substitutions_ (via GSUB) and _positionings_ (via GPOS). Obviously it's not 
possible to handle positionings in PDFont#encode(), so that helps explain why 
showText() is the right place for OpenType, as showText performs both 
positioning and encoding.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

*Technical Background*: In general, OpenType layouts consist of 
glyph_substitutions_ (via GSUB) and _positionings_ (via GPOS). Obviously it's 
not possible to handle positionings in PDFont#encode(), so that helps explain 
why showText() is the right place for OpenType, as showText performs both 
positioning and encoding.

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:16 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

In general, OpenType layouts consist of glyph_substitutions_ (via GSUB) and 
_positionings_ (via GPOS). Obviously it's not possible to handle positionings 
in PDFont#encode(), so that helps explain why showText() is the right place for 
OpenType, as showText performs both positioning and encoding.


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson edited comment on PDFBOX-4189 at 4/15/18 12:11 AM:
---

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType.

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)


was (Author: jahewson):
Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (by design).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438540#comment-16438540
 ] 

John Hewson commented on PDFBOX-4189:
-

Hi guys, this is a really welcome contribution, thank you. With regards to 
PDFont#encode(String text) being non-final I can add some insight as I was the 
original designer of our current PDFont#encode mechanism.

Basically, the PDFont classes are designed to represent fonts identically to 
how they are represented when embedded in PDF files. So there's no support for 
OpenType, by design. A Type0 font knows nothing about OpenType (by design).

So how can we use OpenType in PDFBox? The answer is that we do it one layer of 
abstraction up, during text _layout_ instead of text _encoding_*_._* So you 
want to put your glyph substitution code inside PDPageContentStream#showText, 
actually you want 
[PDPageContentStream#showTextInternal|https://github.com/apache/pdfbox/blob/7e721643c0b1fca9fdc349f78431f36e68abc097/pdfbox/src/main/java/org/apache/pdfbox/contentstream/PDAbstractContentStream.java#L256].

That way PDFont#encode(String text) can stay non-final :)

> Enable rendering of Indian languages, by reading and utilizing the GSUB table
> -
>
> Key: PDFBOX-4189
> URL: https://issues.apache.org/jira/browse/PDFBOX-4189
> Project: PDFBox
>  Issue Type: New Feature
>  Components: FontBox, PDModel
>Reporter: Palash Ray
>Priority: Major
> Attachments: Bengali-text-after.pdf, Bengali-text-before.pdf
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Implemented proper rendering of Indian languages, which need extensive Glyph 
> substitution. The GSUB table has been read and used effectively to replace 
> some compound words with their respective Glyphs. All tests are passing. I 
> have tested this for the Bengali font. Please review these changes and let me 
> know if it makes sense to incorporate these.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716866#comment-15716866
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 11:47 PM:
---

Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she thought it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Ouch. Needless to say high-minded symbolism didn't even enter the equation. And 
unlike me my wife actually likes dogs.


was (Author: jahewson):
Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Ouch. Needless to say high-minded symbolism didn't even enter the equation. And 
unlike me my wife actually likes dogs.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716866#comment-15716866
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 11:45 PM:
---

Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Ouch. Needless to say high-minded symbolism didn't even enter the equation. And 
unlike me my wife actually likes dogs.


was (Author: jahewson):
Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Needless to say high-minded symbolism didn't even enter the equation. And 
unlike me my wife actually likes dogs.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716866#comment-15716866
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 11:42 PM:
---

Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Needless to say high-minded symbolism didn't even enter the equation. And 
unlike me my wife actually likes dogs.


was (Author: jahewson):
Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Needless to say high-minded symbolism didn't even enter the equation.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716866#comment-15716866
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 11:41 PM:
---

Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it communicated about the PDFBox project. She 
replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Needless to say high-minded symbolism didn't even enter the equation.


was (Author: jahewson):
Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it said about the PDFBox project. She replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Needless to say high-minded symbolism didn't even enter the equation.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716866#comment-15716866
 ] 

John Hewson commented on PDFBOX-3557:
-

Ok, so I tested out the dog logo on my wife. I showed her it announcing in a 
pleased manner that someone had designed us a new logo. Here's what she said:

{quote}
What is it?
It’s a dog eating a pitchfork.
No it’s two dogs making a baby dog.
Oh it’s “PDF”.
But why is there the letter “i”?
Oh it’s the dog’s eye.
Ok.
{quote}

Then I asked her what she though it said about the PDFBox project. She replied:

{quote}
Infantile.
Slapdash.
Focused on form over function.
{quote}

Needless to say high-minded symbolism didn't even enter the equation.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:50 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple. Perfect.

If I had to choose one object to represent PDFBox, it would be a toolbox, not a 
dog.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple. Perfect.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:50 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple. Perfect. If I had to choose 
one object to represent PDFBox, it would be a toolbox, not a dog.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple. Perfect.

If I had to choose one object to represent PDFBox, it would be a toolbox, not a 
dog.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:48 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple. Perfect.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:43 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery. It's some 
kind of elaborate intellectual fantasy.

Look at Apple. What's their logo? It's an Apple.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.

Look at Apple. What's their logo? It's an Apple.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:39 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.

Look at Apple. What's there logo? It's an Apple.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:39 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.

Look at Apple. What's their logo? It's an Apple.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.

Look at Apple. What's there logo? It's an Apple.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:38 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's just a bunch of made up stuff. None of those things are communicated. 
Unless you've already read the clever explanation of the logo, you're not going 
to come to those conclusions on your own, e.g. to me dogs are smelly and 
annoying, not intelligent and obedient. I have no need for dogs when writing 
software. It communicates absolutely none of those things it claims to, unless 
a) you just read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:36 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

Also my experience with clever designs is that 40% of people will fail to 
realise that it's even a dog, let alone come to some conclusion about the 
personality of PDFBox which is projected by the choice of imagery.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:30 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop. Not only does it not 
communicate what PDFBox is about, but it also doesn't even communicate the 
obvious things.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:30 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop. Not only does it not 
communicate what PDFBox is about, but it also doesn't even communicate the 
obvious things.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:28 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all. It could be a coffee shop.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:27 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying. It 
communicates absolutely none of those things it claims to.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:27 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to, unless a) you just 
read the explanation, b) you like dogs.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying, not 
intelligent and obedient. I have no need for dogs when writing software. It 
communicates absolutely none of those things it claims to.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:24 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying. It 
communicates absolutely none of those things it claims to.

Take away the clever explanation and you're left with something that makes no 
obvious sense at all.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying. It 
communicates absolutely none of those things it claims to.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 10:21 PM:
---

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions on your own, e.g. to me dogs are smelly and annoying. It 
communicates absolutely none of those things it claims to.


was (Author: jahewson):
> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions are your own, e.g. to me dogs are smelly and annoying. It 
communicates absolutely none of those things it claims to.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716710#comment-15716710
 ] 

John Hewson commented on PDFBOX-3557:
-

> Because we have Box in the name? Because we want to say that we are a toolbox?

Yes. It's that simple. It's who we are. Doing anything else is contradictory.

> If we do so we can go with the designs which were done 2 years ago.

> One of those is a cardboard box, which is the wrong kind of box. The other is 
> a toolbox, but again it looks like a logo designed for business stationary, 
> not something that will work well on the web, in smaller sizes, or favicon, 
> doesn't mention Apache, and doesn't have any color.


> The idea - at least that's how I understand the description done by the 
> designer - is to communicate what PDFBox is about other than the obvious 
> things.

It's not true though. None of those things are communicated. Unless you've 
already read the clever explanation of the logo, you're not going to come to 
those conclusions are your own, e.g. to me dogs are smelly and annoying. It 
communicates absolutely none of those things it claims to.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:15 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name - specifically meaning *toolbox*. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:17 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name, specifically meaning "toolbox". We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name, specifically meaning _toolbox_. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:16 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name, specifically meaning _toolbox_. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name - specifically meaning _toolbox_. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:16 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name - specifically meaning _toolbox_. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name - specifically meaning _toolbox_. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:15 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name - specifically meaning _toolbox_. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name - specifically meaning *toolbox*. We 
should be embracing the fact that we are PDFBox and communicate it as simply 
and obviously as possible, not trying to hide or minimise that, because we're 
already fighting an uphill struggle for new people to remember our name rather 
than all the other PDFWhatever products out there. We also have a secondary 
goal of trying to communicate modernity, as PDFBox 2.0 has rejuvenated the 
project - but I'm not really seeing anything about this logo which wouldn't 
have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:10 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not a modern tech-savvy audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:09 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (Unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:09 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects (Unless PDFBox is smelly and wants to be taken on walks?). For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects. (Unless PDFBox is smelly and wants to be taken on walks?) For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:07 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects. (Unless PDFBox is smelly and wants to be taken on walks?) For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that, because we're already fighting an uphill struggle for 
new people to remember our name rather than all the other PDFWhatever products 
out there. We also have a secondary goal of trying to communicate modernity, as 
PDFBox 2.0 has rejuvenated the project - but I'm not really seeing anything 
about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects. (Unless PDFBox is smelly and wants to be taken on walks?) For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that. We also have a secondary goal of trying to 
communicate modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not 
really seeing anything about this logo which wouldn't have looked the same in 
1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:03 PM:
--

The dog is a cute and visually clever design but I'm with Tilman, I don't see 
how a dog communicates anything meaningful about PDFBox, and certainly not 
anything which sets us apart from the dozens of other PDF products or even open 
source projects. (Unless PDFBox is smelly and wants to be taken on walks?) For 
better or worse, our two distinctive characteristics are 1. we are an Apache 
project, 2. we have "Box" in our name. We should be embracing the fact that we 
are PDFBox and communicate it as simply and obviously as possible, not trying 
to hide or minimise that. We also have a secondary goal of trying to 
communicate modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not 
really seeing anything about this logo which wouldn't have looked the same in 
1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. (Unless PDFBox is smelly and wants to be taken on walks?) For better 
or worse, our two distinctive characteristics are 1. we are an Apache project, 
2. we have "Box" in our name. We should be embracing the fact that we are 
PDFBox and communicate it as simply and obviously as possible, not trying to 
hide or minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not really 
seeing anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:00 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not really 
seeing anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - I'm not really seeing 
anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:00 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. (Unless PDFBox is smelly and wants to be taken on walks?) For better 
or worse, our two distinctive characteristics are 1) we are an Apache project, 
2) we have "Box" in our name. We should be embracing the fact that we are 
PDFBox and communicate it as simply and obviously as possible, not trying to 
hide or minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not really 
seeing anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not really 
seeing anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 7:59 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - I'm not really seeing 
anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 8:00 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. (Unless PDFBox is smelly and wants to be taken on walks?) For better 
or worse, our two distinctive characteristics are 1. we are an Apache project, 
2. we have "Box" in our name. We should be embracing the fact that we are 
PDFBox and communicate it as simply and obviously as possible, not trying to 
hide or minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not really 
seeing anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. (Unless PDFBox is smelly and wants to be taken on walks?) For better 
or worse, our two distinctive characteristics are 1) we are an Apache project, 
2) we have "Box" in our name. We should be embracing the fact that we are 
PDFBox and communicate it as simply and obviously as possible, not trying to 
hide or minimise that. We also have a secondary goal of trying to communicate 
modernity, as PDFBox 2.0 has rejuvenated the project - but I'm not really 
seeing anything about this logo which wouldn't have looked the same in 1998.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 7:57 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not for a modern tech audience.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not modern tech software.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 7:56 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not modern tech software.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not software.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson edited comment on PDFBOX-3557 at 12/2/16 7:54 PM:
--

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

Overall, this feels like a logo suitable for business stationary, but not the 
web, and not software.


was (Author: jahewson):
The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3557) Create new logo for PDFBox

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716100#comment-15716100
 ] 

John Hewson commented on PDFBOX-3557:
-

The dog is a cute design but I'm with Tilman, I don't see how a dog 
communicates anything meaningful about PDFBox, and certainly not anything which 
sets us apart from the dozens of other PDF products or even open source 
projects. Unless PDFBox is smelly and wants to be taken on walks? For better or 
worse, our two distinctive characteristics are 1) we are an Apache project, 2) 
we have "Box" in our name. We should be embracing the fact that we are PDFBox 
and communicate it as simply and obviously as possible, not trying to hide or 
minimise that.

The slab serif is really surprising, it doesn't fit in with the look and feel 
of any technology or software products I've seen in the last few years. Totally 
out of place.

It's also important to note that we _must_ include the words "Apache PDFBox" 
because that is now our registered trademark, so we should really only focus on 
that version of the logo - which is far too wide to be usable in this case, how 
would it even fit on our website? I'm also not seeing how well this logo works 
as icons, favicons, etc, which is essential for us.

> Create new logo for PDFBox
> --
>
> Key: PDFBOX-3557
> URL: https://issues.apache.org/jira/browse/PDFBOX-3557
> Project: PDFBox
>  Issue Type: Task
>  Components: Documentation
>Reporter: Maruan Sahyoun
> Attachments: pdfbox_logo_001.pdf, pdfbox_logo_002.svg, 
> pdfbox_logo_003.pdf, pdfbox_logo_dobrigkeit_01.pdf
>
>
> A while ago there was some discussion about a new logo for the PDFBox 
> website. As the registration of the PDFBox trademark completed we discussed 
> to move that forward.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3569) Performance regression in PDColorSpace#toRGBImageAWT

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671337#comment-15671337
 ] 

John Hewson commented on PDFBOX-3569:
-

Surely this problem will apply to any ICCBased color space too, not just 
DeviceCMYK?

> Performance regression in PDColorSpace#toRGBImageAWT
> 
>
> Key: PDFBOX-3569
> URL: https://issues.apache.org/jira/browse/PDFBOX-3569
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.3, 2.1.0
>Reporter: Andreas Lehmkühler
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.4, 2.1.0
>
> Attachments: PDFBOX-1058.pdf-3.png, PDFBOX-1058.pdf-3.png, 
> PDFBOX-1058.pdf-3.png-diff.png, PDFBOX-2700-JCS_YCCK.pdf-1.png, 
> PDFBOX-2700-JCS_YCCK.pdf-1.png, PDFBOX-2700-JCS_YCCK.pdf-1.png-diff.png, 
> PDFBOX-3569-patch_v2.txt
>
>
> I've a private pdf containing 1900 tiny inline images (CMYK, 8bit) which 
> renders way too slow. Again the CMYK2RGB conversion is the culprit here, BUT 
> the known issue with the KCMS/LCMS change isn't the main problem here.
> I ran some tests on linux (PDFToImage time -imageType png -resolution 150)
> 1.6.0_37: 355s
> 1.7.0_25: 289s
> 1.7.0_75: 298s
> 1.8.0_101: cancelled after 15 min



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3571) sRGB Color Space Profile is subject to 3rd party copyright

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671275#comment-15671275
 ] 

John Hewson commented on PDFBOX-3571:
-

That would work.

> sRGB Color Space Profile is subject to 3rd party copyright
> --
>
> Key: PDFBOX-3571
> URL: https://issues.apache.org/jira/browse/PDFBOX-3571
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: gil cattaneo
>
> Hi
> The file /examples/src/main/resources/org/apache/pdfbox/resources/pdfa/sRGB 
> Color Space Profile.icm
> The license: 
> /examples/src/main/resources/org/apache/pdfbox/resources/pdfa/sRGB Color 
> Space Profile.icm.LICENSE.txt
> contains the following:
>  "...permission to use, copy and distribute this file for any purpose is
>  hereby granted without fee, provided that the file is not changed
>  including the HP copyright notice tag, ... "
> The license says: "provided that the file is not changed"
> It does not respect the criteria "The license must meet the Open Source 
> Definition."
> The OSD [1] says:
> "3. Derived Works
> The license must allow modifications"
> [1] http://www.opensource.org/osd.html
> http://www.apache.org/legal/resolved.html#no-modification



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671239#comment-15671239
 ] 

John Hewson edited comment on PDFBOX-3576 at 11/16/16 6:44 PM:
---

If you have any general improvements to TextStripper we'd be happy to include 
them in PDFBox, providing they don't cause regressions. You can attach an SVN 
patch to this issue via More > Attach files. That way we maintain it :)

Is any of your code not generally applicable to PDFBox users? If not, then 
these modifications to PDFBox belong in PDFBox itself.


was (Author: jahewson):
If you have any general improvements to TextStripper we'd be happy to include 
them in PDFBox, providing they don't cause regressions. You can attach an SVN 
patch to this issue via More > Attach files. That way we maintain it :)

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition to be immutable, but can getters be added to provide read-only 
> access to the class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671255#comment-15671255
 ] 

John Hewson commented on PDFBOX-3576:
-

I'm vary wary of extending the ability to subclass TextStripper. These things 
always come back to bite us, and the people who's subclasses no longer work.

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition to be immutable, but can getters be added to provide read-only 
> access to the class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671244#comment-15671244
 ] 

John Hewson edited comment on PDFBOX-3576 at 11/16/16 6:40 PM:
---

We could, but I'd rather support use of TextPosition and TextStripper in a 
vanilla manner first - then accommodate subclassing only if strictly necessary.

How many times has "let me arbitrarily subclass this thing" actually meant "I 
need one small feature added to PDFBox". I've lost count.


was (Author: jahewson):
We could, but I'd rather support use of TextPosition and TextStripper in a 
vanilla manner first - then accommodate subclassing only if strictly necessary.

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition to be immutable, but can getters be added to provide read-only 
> access to the class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671244#comment-15671244
 ] 

John Hewson commented on PDFBOX-3576:
-

We could, but I'd rather support use of TextPosition and TextStripper in a 
vanilla manner first - then accommodate subclassing only if strictly necessary.

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition to be immutable, but can getters be added to provide read-only 
> access to the class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671239#comment-15671239
 ] 

John Hewson commented on PDFBOX-3576:
-

If you have any general improvements to TextStripper we'd be happy to include 
them in PDFBox, providing they don't cause regressions. You can attach an SVN 
patch to this issue via More > Attach files. That way we maintain it :)

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition to be immutable, but can getters be added to provide read-only 
> access to the class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671222#comment-15671222
 ] 

John Hewson commented on PDFBOX-3576:
-

We did discuss replacing the TextStripper in its entirety and switching to a 
visual glyph-bounds approach. And visual glyph bounds code has been progressing 
recently.

It's not a forgone conclusion, but it doesn't seem like TextPosition has much 
life left in it.

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition to be immutable, but can getters be added to provide read-only 
> access to the class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671174#comment-15671174
 ] 

John Hewson edited comment on PDFBOX-3576 at 11/16/16 6:10 PM:
---

TextPosition is rapidly approaching its end-of-life, so I doubt that this will 
happen.


was (Author: jahewson):
TextPosition is rapidly approach its end-of-life, so I doubt that this will 
happen.

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition, but can getters be added to provide read-only access to the 
> class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3576) Add getter methods to TextPosition

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671174#comment-15671174
 ] 

John Hewson commented on PDFBOX-3576:
-

TextPosition is rapidly approach its end-of-life, so I doubt that this will 
happen.

> Add getter methods to TextPosition
> --
>
> Key: PDFBOX-3576
> URL: https://issues.apache.org/jira/browse/PDFBOX-3576
> Project: PDFBox
>  Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Kurt Devlin
>
> I've inherited code in my department that created a local copy of 
> TextPosition and broke it's immutability. I'm trying to refactor this code 
> and use the core Apache implementation and I understand the need for 
> TextPosition, but can getters be added to provide read-only access to the 
> class's fields?
> We have custom code that does comparison of endX/endY values to determine if 
> there are overlapping characters and other features. In our application, we 
> also have a swap feature where we need to create/clone new TextPosition 
> instances with minor differences between an existing TextPosition instance. 
> Since there are a lot of fields that are required by the constructor of the 
> new instances, but can't be read from an existing instance, we need a way to 
> access these fields.
> There probably should also be an override for equals() and hashCode().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-3571) sRGB Color Space Profile is subject to 3rd party copyright

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668798#comment-15668798
 ] 

John Hewson edited comment on PDFBOX-3571 at 11/15/16 11:59 PM:


Apache 2.0. We made those PDF files. I personally made the "Hello World" custom 
render PDF.


was (Author: jahewson):
Apache 2.0. We made those PDF files.

> sRGB Color Space Profile is subject to 3rd party copyright
> --
>
> Key: PDFBOX-3571
> URL: https://issues.apache.org/jira/browse/PDFBOX-3571
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: gil cattaneo
>
> Hi
> The file /examples/src/main/resources/org/apache/pdfbox/resources/pdfa/sRGB 
> Color Space Profile.icm
> The license: 
> /examples/src/main/resources/org/apache/pdfbox/resources/pdfa/sRGB Color 
> Space Profile.icm.LICENSE.txt
> contains the following:
>  "...permission to use, copy and distribute this file for any purpose is
>  hereby granted without fee, provided that the file is not changed
>  including the HP copyright notice tag, ... "
> The license says: "provided that the file is not changed"
> It does not respect the criteria "The license must meet the Open Source 
> Definition."
> The OSD [1] says:
> "3. Derived Works
> The license must allow modifications"
> [1] http://www.opensource.org/osd.html
> http://www.apache.org/legal/resolved.html#no-modification



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-3571) sRGB Color Space Profile is subject to 3rd party copyright

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668798#comment-15668798
 ] 

John Hewson commented on PDFBOX-3571:
-

Apache 2.0. We made those PDF files.

> sRGB Color Space Profile is subject to 3rd party copyright
> --
>
> Key: PDFBOX-3571
> URL: https://issues.apache.org/jira/browse/PDFBOX-3571
> Project: PDFBox
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: gil cattaneo
>
> Hi
> The file /examples/src/main/resources/org/apache/pdfbox/resources/pdfa/sRGB 
> Color Space Profile.icm
> The license: 
> /examples/src/main/resources/org/apache/pdfbox/resources/pdfa/sRGB Color 
> Space Profile.icm.LICENSE.txt
> contains the following:
>  "...permission to use, copy and distribute this file for any purpose is
>  hereby granted without fee, provided that the file is not changed
>  including the HP copyright notice tag, ... "
> The license says: "provided that the file is not changed"
> It does not respect the criteria "The license must meet the Open Source 
> Definition."
> The OSD [1] says:
> "3. Derived Works
> The license must allow modifications"
> [1] http://www.opensource.org/osd.html
> http://www.apache.org/legal/resolved.html#no-modification



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org