-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SVG status #45
Comments
I had guessed the reasoning in favor of it being binary is along the lines of:
But, let's ask :). Thoughts? |
SVG format is in XML. It should definitely be text.
Here is an example from Wikipedia. You can save it and open it in a text editor and see that it's definitely not binary. Below is the image and source. <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="391" height="391" viewBox="-70.5 -70.5 391 391" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<defs>
<pattern id="grid" patternUnits="userSpaceOnUse" width="50" height="50">
<rect x="0" y="0" width="50" height="1" fill="#000" opacity="1.0"/>
<rect x="0" y="0" width="1" height="50" fill="#000" opacity="1.0"/>
</pattern>
<pattern id="dots" patternUnits="userSpaceOnUse" width="50" height="50">
<g fill-opacity="0.40" stroke="#000" stroke-dasharray="0.3,0.3">
<circle cx="0" cy="0" r="4" fill="red"/>
<circle cx="51" cy="0" r="4" fill="blue"/>
<circle cx="51" cy="51" r="4" fill="green"/>
<circle cx="0" cy="51" r="4" fill="yellow"/>
</g>
</pattern>
</defs>
<rect fill="#fff" stroke="#000" x="-70" y="-70" width="390" height="390"/>
<rect fill="url(#dots)" x="0" y="0" width="250" height="250"/>
<rect fill="url(#grid)" stroke-width="2" stroke="#000" x="0" y="0" width="250" height="250"/>
<text x="0" y="0" text-anchor="middle" font-size="16" font-family="Times New Roman,serif">
<tspan x="125" y="-40" font-weight="bold">X</tspan>
<tspan x="0" y="-10">0</tspan>
<tspan x="50" y="-10">50</tspan>
<tspan x="100" y="-10">100</tspan>
<tspan x="150" y="-10">150</tspan>
<tspan x="200" y="-10">200</tspan>
<tspan x="250" y="-10">250</tspan>
</text>
<text x="0" y="0" text-anchor="middle" font-size="16" font-family="Times New Roman,serif">
<tspan x="-50" y="125" font-weight="bold">Y</tspan>
<tspan x="-20" y="0" dy="6">0</tspan>
<tspan x="-20" y="50" dy="6">50</tspan>
<tspan x="-20" y="100" dy="6">100</tspan>
<tspan x="-20" y="150" dy="6">150</tspan>
<tspan x="-20" y="200" dy="6">200</tspan>
<tspan x="-20" y="250" dy="6">250</tspan>
</text>
<g opacity="0.8">
<rect x="25" y="25" width="200" height="200" fill="lime" stroke-width="4" stroke="pink" />
<circle cx="125" cy="125" r="75" fill="orange" />
<polyline points="50,150 50,200 200,200 200,100" stroke="red" stroke-width="4" fill="none" />
<line x1="50" y1="50" x2="200" y2="200" stroke="blue" stroke-width="4" />
</g>
</svg> |
Obvious for me. SVG is |
I realize that SVG is technically an XML file format. My argument for SVG being treated as binary is based on the Git manual. I've copied and pasted the explanation I included in the pull request in which I originally changed SVG to binary type:
|
@compumike08 https://github.com/compumike08 I see your reasoning, but a |
@compumike08 I see your point too ; I know some people who edit SVG files at hand, but I agree that most people just use them as "assets". |
@JacksonBailey There is a difference between Markdown and SVG files. With Markdown, it is not unreasonable that people may need to do a diff on them; they may want to edit the file to add or remove things and then run @Noctiflore I'm okay with adding a warning or other comment to explain this to users, but I definitely think that the binary status should stand for this repository. |
How about explicitly calling out the ambiguity as shown in #50? |
@compumike08, @danimoth : That's ok for me. |
@danimoth @Noctiflore The comment added in #50 looks good to me too. |
@compumike08 Your points are correct but, to me at least, your reasoning is wrong. Just because people don't hand-edit files doesn't mean they should be binary instead of text. As far as I know the only benefit of making the file text or binary (apart from EOL correction) is how it displays its differences in the diff view. Binary files aren't shown by default in this view. My guesses why are:
On those notes, SVG is human readable. So what changed is discernible form the diff. In addition, SVG is not the type of file that has huge changes when a small "real" change occurs. So, I'm still not convinced that binary makes the most sense, even in the use cases you've described (which I accept are likely the default use cases). As an aside, I do agree that the most-likely default use case should drive what a template repository like this does, I just still think text makes more sense for SVG. So for some other hypothetical extension, say foo, that was some sort of compressed file format but rendered as text, I would agree that binary makes more sense even though the character set is text. |
You make some valid points, however there is one other difference between how binary and text files are handled besides how they appear during diff. Binary and text types vary in how line ending conversions are handled. Depending on the project's settings for handling end of line conversions, text files may have their line endings altered when committed and/or checked out of a repository. Binary files do not have the line endings touched. Generally speaking, even though SVG files are technically XML, they don't normally need to have their line endings converted based on the type of system they are being checked out on because line ending types only matter if a file is going to be edited after the initial commit. Also, if the line ending conversion settings for a repository aren't set properly, you can potentially have the situation where an SVG file is initially committed on a Windows machine, and then checked out on a Mac. In the handful of cases where people DO need to edit their SVG files and DO need line ending conversion applied to those files, they can set SVG as text in their repositories. But the majority of people do not need to do that, so why introduce a potential pain point than can be avoided. |
What about the option (semi binary): *.svg -text diff -merge On windows machine checkout didn''t change lf:
But diff is possible:
|
@compumike08 Your solution with So I'm not really seeing how that's a solution to avoid the issue you described. It was the Checkout wise, you'd get the SVG with CRLF if it was committed as that, or when committed as LF, you might get LF during checkout( Checkin(git add/git commit), will not normalize, but as described above, other software aside, you can get conversion on checkout easily. It'd be better to normalize to LF when doing a checkin, so
|
@alexkaratarakis At the moment, |
@Richienb |
From all the community input at the moment, it seems that something like |
@Richienb there seems to be a small mistake in First the attributes for |
@ericcornelissen Thanks for the report! I'm fixing it now. |
@ericcornelissen Fixed in 6764538. |
I've seen some disturbing things about svg files. They were first defined as text in Graphics.gitattributes (0c2e704), which has been merged in Common.gitattributes (99042dc), then changed to binary (6e33907). Furthermore, svg has been deleted from Java.gitattributes (good thing), with a comment saying it should be binary (199fb63).
Afaik, svg is a text (XML) file (unlike other graphics files). Is there a reason for considering them as binary ?
The text was updated successfully, but these errors were encountered: