[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
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.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
>
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
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.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.
[jira] [Comment Edited] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
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)
> at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
>
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
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.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:506)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine
[jira] [Issue Comment Deleted] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
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.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org.apache.pdfbox.contentstr
[jira] [Commented] (PDFBOX-4219) Multithreading problem when rendering several documents with Standard 14 fonts
[
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.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
> at
> org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:60)
> at
> org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:853)
> at
> org
[jira] [Comment Edited] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
[
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'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 m
[jira] [Commented] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[ 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
[
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
[
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
[
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
[
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
[
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 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
[
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
[
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
[
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 change to 2.0 and broken
existing functionality in an irreparable manner, and that seems worse.
[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation
[
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 change to 2.0 and broken
existing functionality in an irreparable manner, and that seems worse.
[jira] [Comment Edited] (PDFBOX-4106) Vertical text creation
[
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 functionality in an irreparable manner, and that seems worse. Thoughts?
> Vertical text creation
> --
>
>
[jira] [Comment Edited] (PDFBOX-4189) Enable PDF creation with Indian languages, by reading and utilizing the GSUB table
[ 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
[ 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
[
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
[
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
[
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'/'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 t
[jira] [Comment Edited] (PDFBOX-4068) Create ContentStream for XObject forms and tiling patterns
[
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
[
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
[
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
[ 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
[
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
[ 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
[
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
[
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
[
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
[
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
[
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
[
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
[ 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
[
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/PDAbstractContentStream.java#L256].
That way PDFont#encode(Stri
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[
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 :)
*OpenType*: In general, OpenType layouts consist of glyph _sub
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[
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 performs both positioning and encoding.
We also need to keep tra
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[
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 and encoding.
We also need to keep track of glyphs for subsetti
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[
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 track of glyphs for subsetting, which is not possible
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[
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, which is not possible in
encode().
*Subsetting*: We current
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[
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 Indian languages, by reading and utilizing the GSUB table
> --
[jira] [Comment Edited] (PDFBOX-4189) Enable rendering of Indian languages, by reading and utilizing the GSUB table
[ 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
[ 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
[ 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
[ 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
[ 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
[
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
[
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
[
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
[
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
[
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
