You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by je...@apache.org on 2007/11/15 14:28:58 UTC
svn commit: r595297 -
/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
Author: jeremias
Date: Thu Nov 15 05:28:58 2007
New Revision: 595297
URL: http://svn.apache.org/viewvc?rev=595297&view=rev
Log:
Bugzilla #43143:
Had to remove the Expert(Subset) Encoding detection as this caused problems with a barcode font that used dfCharset=2 but was not using ExpertSubset encoding. To detect Expert(Subset)Encoding, the AFM needs to be parsed. And since we don't support that encoding, yet, the fallback to WinAnsiEncoding should work well enough.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java?rev=595297&r1=595296&r2=595297&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java Thu Nov 15 05:28:58 2007
@@ -28,6 +28,7 @@
import org.apache.commons.io.IOUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+
import org.apache.fop.fonts.Glyphs;
/**
@@ -297,22 +298,24 @@
* @return The name of the charset.
*/
public String getCharSetName() {
+ //TODO Had to remove the detection for Expert(Subset) encoding. The PFM is not suitable
+ //for detecting these character sets. We have to parse the AFM for that.
switch (dfCharSet) {
case 0:
return "WinAnsi"; // AKA ISOAdobe
- case 1:
- return "Expert";
case 2:
if ("Symbol".equals(getPostscriptName())) {
return "Symbol";
- } else {
- return "ExpertSubset";
}
+ break;
case 128:
return "Shift-JIS (Japanese)";
default:
- return "Unknown (" + dfCharSet + ", 0x" + Integer.toHexString(dfCharSet) + ")";
+ log.warn("Unknown charset detected (" + dfCharSet
+ + ", 0x" + Integer.toHexString(dfCharSet)
+ + "). Trying fallback to WinAnsi.");
}
+ return "WinAnsi";
}
/**
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: svn commit: r595297 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
But Adrian, CFF has nothing to do with Type 1 PFM files. There's no
indication that this table applies to PFM as well. CFF is a different
font format.
Jeremias Maerki
On 17.11.2007 13:37:59 Adrian Cumiskey wrote:
> Hi Jeremias,
>
> I followed the charset definitions on table 22, page 23 of
> http://www.adobe.com/devnet/font/pdfs/5176.CFF.pdf.
>
> Adrian.
>
> On 17/11/2007, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> >
> > Well, as far as I know relying on dfCharset is not safe. The barcode
> > font that caused the problem didn't use Expert(Subset) encoding. It had
> > a custom encoding ("FontSpecific").
> >
> > Do you have a pointer to a specification that shows that dfCharset=2
> > means ExpertSubset encoding? AFAICS, the only realiable method to detect
> > the encoding of a font is inspecting the AFM or the PFB file which we
> > don't support, yet. The AFM often contains the name of the encoding. In
> > the case of "FontSpecific" encodings, the PFA or PFB file has to be
> > parsed to extract the custom encoding.
> >
> > Jeremias Maerki
> >
> >
> >
> > On 16.11.2007 18:45:34 Adrian Cumiskey wrote:
> > > Hi Jeremias,
> > >
> > > As far as I know any parsed PFM file (Type 1 font) with a dfCharset=2 is
> > using ExpertSubset encoding
> > > and similarly dfCharset=1 is Expert encoding).
> > >
> > > The problem before was that FOP was only able to detect Expert and
> > ExpertSubset encoding types but
> > > was not able to provide the glyph mappings. I have now spent some time
> > providing support for these
> > > and from the testing I have done it seems to work fine, so unless there
> > are any objections I will
> > > add the detection back in and commit my changes after the weekend.
> > >
> > > Adrian.
> > >
> > > jeremias@apache.org wrote:
> > > > Author: jeremias
> > > > Date: Thu Nov 15 05:28:58 2007
> > > > New Revision: 595297
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=595297&view=rev
> > > > Log:
> > > > Bugzilla #43143:
> > > > Had to remove the Expert(Subset) Encoding detection as this caused
> > problems with a barcode font that used dfCharset=2 but was not using
> > ExpertSubset encoding. To detect Expert(Subset)Encoding, the AFM needs to be
> > parsed. And since we don't support that encoding, yet, the fallback to
> > WinAnsiEncoding should work well enough.
> > > >
> > > > Modified:
> > > >
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
> > <snip/>
> >
> >
Re: svn commit: r595297 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Jeremias,
I followed the charset definitions on table 22, page 23 of
http://www.adobe.com/devnet/font/pdfs/5176.CFF.pdf.
Adrian.
On 17/11/2007, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
>
> Well, as far as I know relying on dfCharset is not safe. The barcode
> font that caused the problem didn't use Expert(Subset) encoding. It had
> a custom encoding ("FontSpecific").
>
> Do you have a pointer to a specification that shows that dfCharset=2
> means ExpertSubset encoding? AFAICS, the only realiable method to detect
> the encoding of a font is inspecting the AFM or the PFB file which we
> don't support, yet. The AFM often contains the name of the encoding. In
> the case of "FontSpecific" encodings, the PFA or PFB file has to be
> parsed to extract the custom encoding.
>
> Jeremias Maerki
>
>
>
> On 16.11.2007 18:45:34 Adrian Cumiskey wrote:
> > Hi Jeremias,
> >
> > As far as I know any parsed PFM file (Type 1 font) with a dfCharset=2 is
> using ExpertSubset encoding
> > and similarly dfCharset=1 is Expert encoding).
> >
> > The problem before was that FOP was only able to detect Expert and
> ExpertSubset encoding types but
> > was not able to provide the glyph mappings. I have now spent some time
> providing support for these
> > and from the testing I have done it seems to work fine, so unless there
> are any objections I will
> > add the detection back in and commit my changes after the weekend.
> >
> > Adrian.
> >
> > jeremias@apache.org wrote:
> > > Author: jeremias
> > > Date: Thu Nov 15 05:28:58 2007
> > > New Revision: 595297
> > >
> > > URL: http://svn.apache.org/viewvc?rev=595297&view=rev
> > > Log:
> > > Bugzilla #43143:
> > > Had to remove the Expert(Subset) Encoding detection as this caused
> problems with a barcode font that used dfCharset=2 but was not using
> ExpertSubset encoding. To detect Expert(Subset)Encoding, the AFM needs to be
> parsed. And since we don't support that encoding, yet, the fallback to
> WinAnsiEncoding should work well enough.
> > >
> > > Modified:
> > >
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
> <snip/>
>
>
Re: svn commit: r595297 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Well, as far as I know relying on dfCharset is not safe. The barcode
font that caused the problem didn't use Expert(Subset) encoding. It had
a custom encoding ("FontSpecific").
Do you have a pointer to a specification that shows that dfCharset=2
means ExpertSubset encoding? AFAICS, the only realiable method to detect
the encoding of a font is inspecting the AFM or the PFB file which we
don't support, yet. The AFM often contains the name of the encoding. In
the case of "FontSpecific" encodings, the PFA or PFB file has to be
parsed to extract the custom encoding.
Jeremias Maerki
On 16.11.2007 18:45:34 Adrian Cumiskey wrote:
> Hi Jeremias,
>
> As far as I know any parsed PFM file (Type 1 font) with a dfCharset=2 is using ExpertSubset encoding
> and similarly dfCharset=1 is Expert encoding).
>
> The problem before was that FOP was only able to detect Expert and ExpertSubset encoding types but
> was not able to provide the glyph mappings. I have now spent some time providing support for these
> and from the testing I have done it seems to work fine, so unless there are any objections I will
> add the detection back in and commit my changes after the weekend.
>
> Adrian.
>
> jeremias@apache.org wrote:
> > Author: jeremias
> > Date: Thu Nov 15 05:28:58 2007
> > New Revision: 595297
> >
> > URL: http://svn.apache.org/viewvc?rev=595297&view=rev
> > Log:
> > Bugzilla #43143:
> > Had to remove the Expert(Subset) Encoding detection as this caused problems with a barcode font that used dfCharset=2 but was not using ExpertSubset encoding. To detect Expert(Subset)Encoding, the AFM needs to be parsed. And since we don't support that encoding, yet, the fallback to WinAnsiEncoding should work well enough.
> >
> > Modified:
> > xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
<snip/>
Re: svn commit: r595297 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Jeremias,
As far as I know any parsed PFM file (Type 1 font) with a dfCharset=2 is using ExpertSubset encoding
and similarly dfCharset=1 is Expert encoding).
The problem before was that FOP was only able to detect Expert and ExpertSubset encoding types but
was not able to provide the glyph mappings. I have now spent some time providing support for these
and from the testing I have done it seems to work fine, so unless there are any objections I will
add the detection back in and commit my changes after the weekend.
Adrian.
jeremias@apache.org wrote:
> Author: jeremias
> Date: Thu Nov 15 05:28:58 2007
> New Revision: 595297
>
> URL: http://svn.apache.org/viewvc?rev=595297&view=rev
> Log:
> Bugzilla #43143:
> Had to remove the Expert(Subset) Encoding detection as this caused problems with a barcode font that used dfCharset=2 but was not using ExpertSubset encoding. To detect Expert(Subset)Encoding, the AFM needs to be parsed. And since we don't support that encoding, yet, the fallback to WinAnsiEncoding should work well enough.
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
>
> Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java
> URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java?rev=595297&r1=595296&r2=595297&view=diff
> ==============================================================================
> --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java (original)
> +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/PFMFile.java Thu Nov 15 05:28:58 2007
> @@ -28,6 +28,7 @@
> import org.apache.commons.io.IOUtils;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> +
> import org.apache.fop.fonts.Glyphs;
>
> /**
> @@ -297,22 +298,24 @@
> * @return The name of the charset.
> */
> public String getCharSetName() {
> + //TODO Had to remove the detection for Expert(Subset) encoding. The PFM is not suitable
> + //for detecting these character sets. We have to parse the AFM for that.
> switch (dfCharSet) {
> case 0:
> return "WinAnsi"; // AKA ISOAdobe
> - case 1:
> - return "Expert";
> case 2:
> if ("Symbol".equals(getPostscriptName())) {
> return "Symbol";
> - } else {
> - return "ExpertSubset";
> }
> + break;
> case 128:
> return "Shift-JIS (Japanese)";
> default:
> - return "Unknown (" + dfCharSet + ", 0x" + Integer.toHexString(dfCharSet) + ")";
> + log.warn("Unknown charset detected (" + dfCharSet
> + + ", 0x" + Integer.toHexString(dfCharSet)
> + + "). Trying fallback to WinAnsi.");
> }
> + return "WinAnsi";
> }
>
> /**
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
>
>