Useless entities of the svg element in svg fonts. #2456

Open
Pecita opened this Issue Aug 18, 2015 · 33 comments

Comments

Projects
None yet
5 participants
@Pecita

Pecita commented Aug 18, 2015

Dear developers,

I got a trouble in manipulating svg fonts build by FontForge 2014. It worked well in FF 2012.
Useless xmlns entities in the svg element cause dysfunctions in the programming: please remove them.

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> cause xsl transforms errors.
<svg version="1.1"> would be OK.

You have a case in http://pecita.eu/bugCFF/bugSVG.tar.bz2. You need to install php5.cli & php5.xsl to use it.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 19, 2015

By cons must add the font-face-src element as a required child of the font-face element in this context, like this:
<font-face font-family="Pecita" [...] unicode-range="U+0008-FFFD"> <font-face-src> <font-face-name name="Pecita"/> </font-face-src> </font-face>"
(use https://validator.w3.org/ to validate or examine the dtd http://www.w3.org/Graphics/SVG/1.1/DTD/svg-font.mod)

Pecita commented Aug 19, 2015

By cons must add the font-face-src element as a required child of the font-face element in this context, like this:
<font-face font-family="Pecita" [...] unicode-range="U+0008-FFFD"> <font-face-src> <font-face-name name="Pecita"/> </font-face-src> </font-face>"
(use https://validator.w3.org/ to validate or examine the dtd http://www.w3.org/Graphics/SVG/1.1/DTD/svg-font.mod)

@jtanx

This comment has been minimized.

Show comment
Hide comment
@jtanx

jtanx Aug 19, 2015

Contributor

Having the xlmns declarations seems pretty standard, and at the very least is valid SVG, so IMO, I don't particularly see the need to remove them.

Contributor

jtanx commented Aug 19, 2015

Having the xlmns declarations seems pretty standard, and at the very least is valid SVG, so IMO, I don't particularly see the need to remove them.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 19, 2015

It is a regression.
I do not know if it is pretty standard but if the PHP class transformToXML denies there is a big doubt. What is certain is that it is unnecessary and it depreciates the software.
SVG fonts suffer many attacks. However, they have the great quality of being XML and thus to be transformable. If this will not to be the case...

Pecita commented Aug 19, 2015

It is a regression.
I do not know if it is pretty standard but if the PHP class transformToXML denies there is a big doubt. What is certain is that it is unnecessary and it depreciates the software.
SVG fonts suffer many attacks. However, they have the great quality of being XML and thus to be transformable. If this will not to be the case...

@mskala

This comment has been minimized.

Show comment
Hide comment
@mskala

mskala Aug 19, 2015

Member

I don't think it's reasonable to ask for namespace declarations to be removed from XML files. They are part of the standard, they are an important part of the standard, and parsers ought to handle them.

Member

mskala commented Aug 19, 2015

I don't think it's reasonable to ask for namespace declarations to be removed from XML files. They are part of the standard, they are an important part of the standard, and parsers ought to handle them.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 22, 2015

Fontforge 2012 is a perfect software to build a basic typeface for the web. This is certainly its main use. On this level I am sure that the 2015 version will bring improvements.
Fontforge 2012 is also a perfect software to build, with the help of custom programming interfaces, complex fonts. I am afraid, and in this case it is even a decision fully aware, that this possibility will disappear in FontForge 2015. Although this use is marginal, it exists and should be respected.

Pecita commented Aug 22, 2015

Fontforge 2012 is a perfect software to build a basic typeface for the web. This is certainly its main use. On this level I am sure that the 2015 version will bring improvements.
Fontforge 2012 is also a perfect software to build, with the help of custom programming interfaces, complex fonts. I am afraid, and in this case it is even a decision fully aware, that this possibility will disappear in FontForge 2015. Although this use is marginal, it exists and should be respected.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 26, 2015

The bug can be bypassed by specifying the useless namespace in the xsl:
<xsl:stylesheet id="pecita" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" exclude-result-prefixes="xlink svg"> <xsl:output method="xml"/> [...] xsl:template match="svg:font"> [...]
Of course the source xml should belong nonamespace to avoid inference with transformation.
The svg namespace is a parasite and the xlink namespace is completely off topic.
I'm sad that the SVG fonts are XML, so transformable, is not understood as an essential facility.

  • Please remove the namespace in the svg element to keep behavior.
  • Please add the font-face-src element as a child of the font-face element to conform dtd.

Pecita commented Aug 26, 2015

The bug can be bypassed by specifying the useless namespace in the xsl:
<xsl:stylesheet id="pecita" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" exclude-result-prefixes="xlink svg"> <xsl:output method="xml"/> [...] xsl:template match="svg:font"> [...]
Of course the source xml should belong nonamespace to avoid inference with transformation.
The svg namespace is a parasite and the xlink namespace is completely off topic.
I'm sad that the SVG fonts are XML, so transformable, is not understood as an essential facility.

  • Please remove the namespace in the svg element to keep behavior.
  • Please add the font-face-src element as a child of the font-face element to conform dtd.
@mskala

This comment has been minimized.

Show comment
Hide comment
@mskala

mskala Apr 6, 2016

Member

I don't know what that means.

Member

mskala commented Apr 6, 2016

I don't know what that means.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Apr 6, 2016

It seems that I received an old email 30mn ago as if it was a new: Sorry
Matthew.

2016-04-06 13:20 GMT+02:00 Matthew Skala notifications@github.com:

I don't know what that means.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2456 (comment)

Pecita commented Apr 6, 2016

It seems that I received an old email 30mn ago as if it was a new: Sorry
Matthew.

2016-04-06 13:20 GMT+02:00 Matthew Skala notifications@github.com:

I don't know what that means.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2456 (comment)

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

Can we do something to end this bug before the Debian release?

Pecita commented Aug 7, 2016

Can we do something to end this bug before the Debian release?

@mskala

This comment has been minimized.

Show comment
Hide comment
@mskala

mskala Aug 7, 2016

Member

This bug report is too unclear for any meaningful action, so probably not.

If you want more to be done, it would help a lot if we could sort out whether or not FontForge's current behaviour is within the SVG specification. That's not clear from the current report. If you have an example of an SVG file produced by FontForge that you think isn't valid SVG, then it would be very helpful to attach the complete file, and instructions for recreating it. If such a file passes the validator at https://validator.w3.org/ , then it'll also need a very clear explanation (using more informative terms than "useless" and "dysfunctional") of why you think it's incorrect despite being valid.

Member

mskala commented Aug 7, 2016

This bug report is too unclear for any meaningful action, so probably not.

If you want more to be done, it would help a lot if we could sort out whether or not FontForge's current behaviour is within the SVG specification. That's not clear from the current report. If you have an example of an SVG file produced by FontForge that you think isn't valid SVG, then it would be very helpful to attach the complete file, and instructions for recreating it. If such a file passes the validator at https://validator.w3.org/ , then it'll also need a very clear explanation (using more informative terms than "useless" and "dysfunctional") of why you think it's incorrect despite being valid.

@mskala

This comment has been minimized.

Show comment
Hide comment
@mskala

mskala Aug 7, 2016

Member

Further to that - the validator on the original example font reports an error "end tag for "font-face" which is not finished" twice. Is that the main issue here? It seems to have nothing to do with namespaces.

Member

mskala commented Aug 7, 2016

Further to that - the validator on the original example font reports an error "end tag for "font-face" which is not finished" twice. Is that the main issue here? It seems to have nothing to do with namespaces.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

Dear Matthew,

Your change is very intelligent and fully complies with the standards.
However...

Does a link could be present in an svg font? -> no, the link namespace is fully useless.
Does any standard XSLT fail after adding a name space? -> yes, the XML is dysfunctional (except with an heavy bypass).
Does an SVG font should be nonamespace? -> there is no specification but a general practice: yes a SVG font should be nonamespace.
Does the validator complain? -> yes because the lack of font-face-src element.

Is it a regression from the 2012 version -> yes.

All of this is perfectly clear in the report of this issue.

Pecita commented Aug 7, 2016

Dear Matthew,

Your change is very intelligent and fully complies with the standards.
However...

Does a link could be present in an svg font? -> no, the link namespace is fully useless.
Does any standard XSLT fail after adding a name space? -> yes, the XML is dysfunctional (except with an heavy bypass).
Does an SVG font should be nonamespace? -> there is no specification but a general practice: yes a SVG font should be nonamespace.
Does the validator complain? -> yes because the lack of font-face-src element.

Is it a regression from the 2012 version -> yes.

All of this is perfectly clear in the report of this issue.

@mskala

This comment has been minimized.

Show comment
Hide comment
@mskala

mskala Aug 7, 2016

Member

I don't think I have made any change related to this issue.

Member

mskala commented Aug 7, 2016

I don't think I have made any change related to this issue.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

So do we can to trace the originator?

Pecita commented Aug 7, 2016

So do we can to trace the originator?

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

I found :
[https://github.com/fontforge/fontforge/commit/229fa95247adf4c7a4c18dc1e22ac2c5cae7b49]
To jtanx: what is the reason for this change?

Pecita commented Aug 7, 2016

I found :
[https://github.com/fontforge/fontforge/commit/229fa95247adf4c7a4c18dc1e22ac2c5cae7b49]
To jtanx: what is the reason for this change?

@jtanx

This comment has been minimized.

Show comment
Hide comment
@jtanx

jtanx Aug 7, 2016

Contributor

As per the git comment. Fixes #626. What software are you using for which it is failing? Have you tried updating that software?

Contributor

jtanx commented Aug 7, 2016

As per the git comment. Fixes #626. What software are you using for which it is failing? Have you tried updating that software?

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

Thank for your quick reply, Jeremie. I'm not aware with GIT.

What software are you using for which it is failing?

XML! (I'am XML 1.1 certified programmer!)

The XML exists to be transformed (to XML or HTML or text) using XSLT.
XML document containing more than one or more namespace can be transformed using a heavy XSLT syntax. XML document without namespace can be transformed without complication.
An XML document that contain more than one namespace must have all the namespaces specified. An XML document with only one namespace can be either with the namespace specified either nonamespace. This second option allow to use a light syntax in XSLT. In absence of specification I think that it is the reason for witch there is no namespace specified in a svg font.
SVG font (without namespace) are useful to generate SVG image, HTML page, for validation tools, etc.

#626...

When fontforge generates SVG font, it creates tag instead of . That's technically correct, but cause problems with some programs & browsers. At least, on fontello i had to patch generated files after bugreports.

I think that I have two arguments against #626:

  1. XSLT is part of the XML standard, not fontello!
  2. The practice (choice to nonamespace) make the law.

Pecita commented Aug 7, 2016

Thank for your quick reply, Jeremie. I'm not aware with GIT.

What software are you using for which it is failing?

XML! (I'am XML 1.1 certified programmer!)

The XML exists to be transformed (to XML or HTML or text) using XSLT.
XML document containing more than one or more namespace can be transformed using a heavy XSLT syntax. XML document without namespace can be transformed without complication.
An XML document that contain more than one namespace must have all the namespaces specified. An XML document with only one namespace can be either with the namespace specified either nonamespace. This second option allow to use a light syntax in XSLT. In absence of specification I think that it is the reason for witch there is no namespace specified in a svg font.
SVG font (without namespace) are useful to generate SVG image, HTML page, for validation tools, etc.

#626...

When fontforge generates SVG font, it creates tag instead of . That's technically correct, but cause problems with some programs & browsers. At least, on fontello i had to patch generated files after bugreports.

I think that I have two arguments against #626:

  1. XSLT is part of the XML standard, not fontello!
  2. The practice (choice to nonamespace) make the law.
@mskala

This comment has been minimized.

Show comment
Hide comment
@mskala

mskala Aug 7, 2016

Member

I find it hard to believe that XSLT really cannot process valid SVG. Do you have a citation to the relevant part of the XSLT standard where it says this?

Member

mskala commented Aug 7, 2016

I find it hard to believe that XSLT really cannot process valid SVG. Do you have a citation to the relevant part of the XSLT standard where it says this?

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

XSLT really cannot process valid SVG

My English is bad but I never meant it. I find unfair your behavior, Matthew. My only concern is to preserve the quality of fontforge.
For the rest:
#2456 (comment)
https://www.w3.org/TR/xslt#section-Creating-the-Result-Tree
https://developer.mozilla.org/fr/docs/Transformations_XML_avec_XSLT

Pecita commented Aug 7, 2016

XSLT really cannot process valid SVG

My English is bad but I never meant it. I find unfair your behavior, Matthew. My only concern is to preserve the quality of fontforge.
For the rest:
#2456 (comment)
https://www.w3.org/TR/xslt#section-Creating-the-Result-Tree
https://developer.mozilla.org/fr/docs/Transformations_XML_avec_XSLT

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 7, 2016

  1. https://www.w3.org/TR/SVG/fonts.html spec has xmlns in all examples
  2. fontello/fontello#53 chrome had problems with loading fonts without xmlns

All font internals are big combination of kludges. That's a life. And i prefer to have working fonts with kludges, instead of "ideal but not working".

puzrin commented Aug 7, 2016

  1. https://www.w3.org/TR/SVG/fonts.html spec has xmlns in all examples
  2. fontello/fontello#53 chrome had problems with loading fonts without xmlns

All font internals are big combination of kludges. That's a life. And i prefer to have working fonts with kludges, instead of "ideal but not working".

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 7, 2016

Probably, FF adds more attributes than needed. Here is very popular FontAwesome SVG font https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/fonts/fontawesome-webfont.svg

If problem is with xmlns:link i have nothing against remove it. But minimal <svg xmlns="http://www.w3.org/2000/svg"> is mandatory IMHO. The same was suggested in fontello bugreport.

puzrin commented Aug 7, 2016

Probably, FF adds more attributes than needed. Here is very popular FontAwesome SVG font https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/fonts/fontawesome-webfont.svg

If problem is with xmlns:link i have nothing against remove it. But minimal <svg xmlns="http://www.w3.org/2000/svg"> is mandatory IMHO. The same was suggested in fontello bugreport.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

Hi Vitaly!
I'm really glad to hear you!

fontello/fontello#53 chrome had problems with loading fonts without xmlns

Forgot this argument: Chrome no longer support any SVG fonts.

All font internals are big combination of kludges. That's a life. And i prefer to have working fonts with kludges, instead of "ideal but not working".

Your other arguments make senses but I think that the continuity of the classic FF behavior is much better because it favors the basic tool XSLT. It's somewhere the last thing that stay to SVG fonts :-(

Pecita commented Aug 7, 2016

Hi Vitaly!
I'm really glad to hear you!

fontello/fontello#53 chrome had problems with loading fonts without xmlns

Forgot this argument: Chrome no longer support any SVG fonts.

All font internals are big combination of kludges. That's a life. And i prefer to have working fonts with kludges, instead of "ideal but not working".

Your other arguments make senses but I think that the continuity of the classic FF behavior is much better because it favors the basic tool XSLT. It's somewhere the last thing that stay to SVG fonts :-(

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 7, 2016

Let's do not propagate your own situation with php to all FF community. SVG format suppoort was bad for a long time. For example FF could generate SVG that it could not read after. IMHO making SVG content close to other font editors is a good step forward.

puzrin commented Aug 7, 2016

Let's do not propagate your own situation with php to all FF community. SVG format suppoort was bad for a long time. For example FF could generate SVG that it could not read after. IMHO making SVG content close to other font editors is a good step forward.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 7, 2016

Let's do not propagate your own situation with php to all FF community.

PHP has little to do with it! It's just the interface used to enable the XSL stylesheet in the test case. I can do it in Perl or Java if you prefer!

IMHO making SVG content close to other font editors is a good step forward.

That all tools developed on a XML transformation of a FF SVG font no longer work is not a good step forward but a regression.

Pecita commented Aug 7, 2016

Let's do not propagate your own situation with php to all FF community.

PHP has little to do with it! It's just the interface used to enable the XSL stylesheet in the test case. I can do it in Perl or Java if you prefer!

IMHO making SVG content close to other font editors is a good step forward.

That all tools developed on a XML transformation of a FF SVG font no longer work is not a good step forward but a regression.

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 8, 2016

That depends on personal preference. IMHO, prior to speak about regression, your tools should be ok with w3c font examples. It's a bit strange for me to seriously consider XSL transformations as main FF goal. Probably, it's better to patch SVG prior to process.

Also, as i said before, i'd suggest to simplify header to this format: <svg xmlns="http://www.w3.org/2000/svg">

puzrin commented Aug 8, 2016

That depends on personal preference. IMHO, prior to speak about regression, your tools should be ok with w3c font examples. It's a bit strange for me to seriously consider XSL transformations as main FF goal. Probably, it's better to patch SVG prior to process.

Also, as i said before, i'd suggest to simplify header to this format: <svg xmlns="http://www.w3.org/2000/svg">

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 8, 2016

your tools should be ok with w3c font examples.

My tools are OK with FF SVG fonts that are technically corrects.

it's better to patch SVG prior to process

(I understand XSLT instead of SVG)
Can be done (Assuming the link namespace will be removed) but it's a useless hard work.

It's a bit strange for me to seriously consider XSL transformations as main FF goal.

(I understand "FF SVG font" instead of FF)
What other use does it rest to SVG font other that XML transformation? (As you surely, I regret that very much.)
However where SVG fonts work, FF SVG fonts work, for example old webkit browser versions.

Pecita commented Aug 8, 2016

your tools should be ok with w3c font examples.

My tools are OK with FF SVG fonts that are technically corrects.

it's better to patch SVG prior to process

(I understand XSLT instead of SVG)
Can be done (Assuming the link namespace will be removed) but it's a useless hard work.

It's a bit strange for me to seriously consider XSL transformations as main FF goal.

(I understand "FF SVG font" instead of FF)
What other use does it rest to SVG font other that XML transformation? (As you surely, I regret that very much.)
However where SVG fonts work, FF SVG fonts work, for example old webkit browser versions.

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 8, 2016

My tools are OK with FF SVG fonts that are technically corrects.

Nothing will change if you repeat it multiple time. If you speak about standards - do correct refs first. IMHO correct refs in this case could be w3c svg font spec examples (not your code and not old FF with really buggy SVG support).

What other use does it rest to SVG font other that XML transformation?

I'd suppose, that the first use of font is to display it :). As far as i know, people can also open those fonts in browsers & font editors + view manually. Personally, i use those in fontello to import glyphs.

puzrin commented Aug 8, 2016

My tools are OK with FF SVG fonts that are technically corrects.

Nothing will change if you repeat it multiple time. If you speak about standards - do correct refs first. IMHO correct refs in this case could be w3c svg font spec examples (not your code and not old FF with really buggy SVG support).

What other use does it rest to SVG font other that XML transformation?

I'd suppose, that the first use of font is to display it :). As far as i know, people can also open those fonts in browsers & font editors + view manually. Personally, i use those in fontello to import glyphs.

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 8, 2016

As far as i know, people can also open those fonts in browsers

No Chrome, no Firefox, no Opera, no IE...

Personally, i use those in fontello to import glyphs.

It is extremely vague. Can you as I did give a test case. Is it after fontello/fontello#346 ?

Pecita commented Aug 8, 2016

As far as i know, people can also open those fonts in browsers

No Chrome, no Firefox, no Opera, no IE...

Personally, i use those in fontello to import glyphs.

It is extremely vague. Can you as I did give a test case. Is it after fontello/fontello#346 ?

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 8, 2016

Can you as I did give a test case.

No, because fontello has no problems with svg fonts import. Case with Crome was given before fontello/fontello#53. And since we have no resource to check EVERY program with SVG, it's more easy to format it as other font editors do (~ as in examples of w3c spec).

puzrin commented Aug 8, 2016

Can you as I did give a test case.

No, because fontello has no problems with svg fonts import. Case with Crome was given before fontello/fontello#53. And since we have no resource to check EVERY program with SVG, it's more easy to format it as other font editors do (~ as in examples of w3c spec).

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 8, 2016

In conclusion there is no reason to change the format of the FF SVG Font, that create problems without solving.

Pecita commented Aug 8, 2016

In conclusion there is no reason to change the format of the FF SVG Font, that create problems without solving.

@puzrin

This comment has been minimized.

Show comment
Hide comment
@puzrin

puzrin Aug 8, 2016

I see nothing constructive in ignoring samples about crome and w3c spec in favour of personal case. Also i don't see anything normal in desire to deviate format from other software of similar type, without wide testing.

puzrin commented Aug 8, 2016

I see nothing constructive in ignoring samples about crome and w3c spec in favour of personal case. Also i don't see anything normal in desire to deviate format from other software of similar type, without wide testing.

@davelab6

This comment has been minimized.

Show comment
Hide comment
@davelab6

davelab6 Aug 8, 2016

Member

@Pecita I don't understand;

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> should not cause xsl transforms errors.

You have a case in http://pecita.eu/bugCFF/bugSVG.tar.bz2. You need to install php5.cli & php5.xsl to use it.

Could you tell me exactly what to do with these files?

Member

davelab6 commented Aug 8, 2016

@Pecita I don't understand;

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> should not cause xsl transforms errors.

You have a case in http://pecita.eu/bugCFF/bugSVG.tar.bz2. You need to install php5.cli & php5.xsl to use it.

Could you tell me exactly what to do with these files?

@davelab6 davelab6 self-assigned this Aug 8, 2016

@Pecita

This comment has been minimized.

Show comment
Hide comment
@Pecita

Pecita Aug 8, 2016

@Pecita I don't understand;

[...] should not cause xsl transforms errors.

Yes it does! With the best will, I do not understand you do not understand!
Maybe work on the test case can help?

Could you tell me exactly what to do with these files?

  1. install php5.cli & php5.xsl (Debian)
  2. extract the files and go to the target directory using a terminal
  3. chmod +x 2012.php & 2014.php
  4. ls
  5. del *.xml (the target files) for clarity
  6. diff 2012.php 2014.php (the source and target files differs)
  7. diff 2012.svg 2014.svg (the namespaces are added in 2014.svg)
  8. php -f 2012.php (2012.xml is created as expected)
  9. php -f 2014.php (2014.xml is created but almost empty)

You can now correct the stylesheet trisvg.xsl folowing #2456 (comment)
It will work for 2014.svg but no more for 2012.svg

It's because the XSLT must match the structure of the XML. Adding namespaces need a specific XSLT echoing the useless namespaces, adding an appropriate attribute exclude-result-prefixes, adding a "svg:" prefix to each element name... no sense!

Pecita commented Aug 8, 2016

@Pecita I don't understand;

[...] should not cause xsl transforms errors.

Yes it does! With the best will, I do not understand you do not understand!
Maybe work on the test case can help?

Could you tell me exactly what to do with these files?

  1. install php5.cli & php5.xsl (Debian)
  2. extract the files and go to the target directory using a terminal
  3. chmod +x 2012.php & 2014.php
  4. ls
  5. del *.xml (the target files) for clarity
  6. diff 2012.php 2014.php (the source and target files differs)
  7. diff 2012.svg 2014.svg (the namespaces are added in 2014.svg)
  8. php -f 2012.php (2012.xml is created as expected)
  9. php -f 2014.php (2014.xml is created but almost empty)

You can now correct the stylesheet trisvg.xsl folowing #2456 (comment)
It will work for 2014.svg but no more for 2012.svg

It's because the XSLT must match the structure of the XML. Adding namespaces need a specific XSLT echoing the useless namespaces, adding an appropriate attribute exclude-result-prefixes, adding a "svg:" prefix to each element name... no sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment