FIXES: #16836
Normal Res
Hi Res
The svg files are valid markup. If the linter ignores these files - maybe we can re-add svg files back to the linter?
Before I push a new commit - Is there anything you think should change about the presentation?
NOTE: The year and version number are dynamic.
0@@ -1,34 +1,26 @@
1-<?xml version="1.0" standalone="no"?>
2-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
3- "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
4-<svg version="1.0" xmlns="http://www.w3.org/2000/svg" width="1000pt" height="640pt" viewBox="0 0 1000 640" preserveAspectRatio="xMidYMid meet">
5- <!-- kate: space-indent off;
6- Copyright (c) 2015 The Bitcoin Core developers
7- Distributed under the MIT software license, see the accompanying
8- file COPYING or http://www.opensource.org/licenses/mit-license.php.
ok - I will include the copyright header in the background.svg file. I am pretesting my next commit
https://travis-ci.com/RandyMcMillan/bitcoin/builds/135097633
0<!-- kate: space-indent off; ... -->
Is this an artifact from an old linting tool - or does this need to stay?
It tells the Kate text editor to use tabs instead of spaces for indentation.
Unless you are switching the file to use spaces, I would prefer if it stays.
Please add a copyright notice.
I did add the copyright notice to the background.svg file as well! https://github.com/bitcoin/bitcoin/pull/17311/commits/8a68941b70c95ef33e2f65865a96745da5721a44#diff-8552c751b30ae0c0bbb7a7994e13a986R3
98@@ -99,7 +99,7 @@ $(OSX_APP)/Contents/PkgInfo:
99
100 $(OSX_APP)/Contents/Resources/empty.lproj:
101 $(MKDIR_P) $(@D)
102- @touch $@
128@@ -129,9 +129,9 @@ $(OSX_DMG): $(OSX_APP_BUILT) $(OSX_PACKAGING) $(OSX_BACKGROUND_IMAGE)
129 $(PYTHON) $(OSX_DEPLOY_SCRIPT) $(OSX_APP) -add-qt-tr $(OSX_QT_TRANSLATIONS) -translations-dir=$(QT_TRANSLATION_DIR) -dmg -fancy $(OSX_FANCY_PLIST) -verbose 2 -volname $(OSX_VOLNAME)
130
131 $(OSX_BACKGROUND_IMAGE).png: contrib/macdeploy/$(OSX_BACKGROUND_SVG)
132- sed 's/PACKAGE_NAME/$(PACKAGE_NAME)/' < "$<" | $(RSVG_CONVERT) -f png -d 36 -p 36 -o $@
133+ sed -e 's/PACKAGE_NAME/$(PACKAGE_NAME)/' -e 's/PACKAGE_VERSION/$(PACKAGE_VERSION)/' -e 's/PACKAGE_YEAR/$(PACKAGE_YEAR)/' -e 's/COPYRIGHT_YEAR/$(COPYRIGHT_YEAR)/' -e 's/COPYRIGHT_HOLDERS_FINAL/$(COPYRIGHT_HOLDERS_FINAL)/' contrib/macdeploy/$(OSX_BACKGROUND_SVG) < "$<" | $(RSVG_CONVERT) -f png -d 36 -p 36 -o $@
sed -e or multiple arguments portable? (Alternatives are semicolons in a single argument, or multiple sed pipes)
0@@ -1,34 +1,32 @@
1-<?xml version="1.0" standalone="no"?>
2-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
3- "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
4-<svg version="1.0" xmlns="http://www.w3.org/2000/svg" width="1000pt" height="640pt" viewBox="0 0 1000 640" preserveAspectRatio="xMidYMid meet">
5+<?xml version="1.0" encoding="utf-8"?>
6 <!-- kate: space-indent off;
45+</style>
46+<linearGradient id="SVGID_1_" gradientUnits="userSpaceOnUse" x1="-1245.668" y1="163.2625" x2="-1245.168" y2="163.2625" gradientTransform="matrix(1000 0 0 640 1245668 -104328)">
47+ <stop offset="0" style="stop-color:#EFEFEF"/>
48+ <stop offset="0.33" style="stop-color:#EFEFEF"/>
49+ <stop offset="0.8" style="stop-color:#CDCDCD"/>
50+ <stop offset="1" style="stop-color:#CCCCCC"/>
What’s not cross-platform about it? And no, it isn’t GPL… it’s public domain with a catchall PD-equivalent license.
From http://tulrich.com/fonts/
I, the copyright holder of this work, hereby release it into the public domain. This applies worldwide.
In case this is not legally possible,
I grant any entity the right to use this work for any purpose, without any conditions, unless such conditions are required by law.
@luke-jr: Oh. My bad. You’r right, it’s PD.
Cross platform: you need to install the font in order to render the SVG correctly. There are a handful of fonts that are available on almost all platforms.
IMO if we are going to use Tuffy, we should probably make sure its either covered/downloaded by the depends build or detected via configure.
IIRC I chose Tuffy primarily because it looked similar to the prior bitmap image’s font.
I don’t know any free font available on all platforms (and the non-free ones obviously aren’t available on free-only platforms).
Tuffy is the current font. Any addition to the build system IMO should be a separate PR - no need to go through it here.
Tested 8a68941b70c95ef33e2f65865a96745da5721a44 on macOS 10.15.
Uploading 8a68941b70c95ef33e2f65865a96745da5721a44_background.tiff.zip…
I think I found the issue.
In a previous attempt at this fix I concluded that fonts-liberation may be a good alternative if (or when) it comes necessary. Now that I have a better understanding of the issue - we don’t need to consider a new font right now.
Adding this link for future reference: #17143 (comment)
NOTE: fonts-liberation is actually a superior option long term - it should be considered if a branding refresh is ever on the table because we can use it across the board for software deployment as well as web font (it offers an entire array of variations including monospace).
Liberation is OFL, which despite popular misconception is a non-free license.
I don’t see what’s wrong with continuing to use Tuffy…
Hi-Res working. It was a bit of a work around to fix the kerning issue. Doing my pretests before pushing a new commit.
Prelim test passed:
https://travis-ci.org/RandyMcMillan/bitcoin/builds/608624226
make deploy on macOS 10.15:
But the copyright line is missing when building with Gitian (though why?): https://bitcoin.jonasschnelli.ch/build/1292
30- <g transform="translate(0.000000,640.000000) scale(0.100000,-0.100000)"
31- fill="#000000" stroke="none">
32- <path d="M4995 3705 c-24 -23 -25 -29 -25 -165 l0 -140 -306 0 -306 0 -29 -29 c-29 -29 -29 -31 -29 -141 0 -110 0 -112 29 -141 l29 -29 306 0 306 0 0 -140 c0 -136 1 -142 25 -165 16 -17 35 -25 57 -25 29 0 72 32 306 226 180 149 274 233 278 250 13 53 -2 70 -278 299 -235 194 -277 225 -306 225 -22 0 -41 -8 -57 -25z" fixlter="url(#glow)"/>
33- </g>
34+<?xml version="1.0" encoding="utf-8"?>
35+<!-- Copyright (c) 2013-2019 The Bitcoin Core developers -->
I don’t know any free font available on all platforms (and the non-free ones obviously aren’t available on free-only platforms).
Instead of hoping to pick a font that happens to be free and on all platfroms, what about picking a free font that looks best and then tracing the letters into paths, so that it works on all platforms?
I know that this makes it harder to build Bitcoin Knots, because strings can no longer be simply replaced, but at some point we’d have to make trade-offs?
| File | commit cd6cb9745e13a62e130b11f78a13bcc1d424b05e(master) | commit 9e7fe2f5773a13708ec0de722efe0b43a1a489e0(master and this pull) |
|---|---|---|
| bitcoin-0.19.99-aarch64-linux-gnu-debug.tar.gz | b25191cf773b0bf8... |
a2363c59d80d4aa3... |
| bitcoin-0.19.99-aarch64-linux-gnu.tar.gz | 66cddf99c1e08dde... |
27addf669869ef08... |
| bitcoin-0.19.99-arm-linux-gnueabihf-debug.tar.gz | 301fa28e49a64bbb... |
f9703edc81bc61f1... |
| bitcoin-0.19.99-arm-linux-gnueabihf.tar.gz | b52d82ea2fed7f13... |
ae7f2aef3c290826... |
| bitcoin-0.19.99-i686-pc-linux-gnu-debug.tar.gz | bd623b4dc3cf5a9a... |
b2fe8f3976947b82... |
| bitcoin-0.19.99-i686-pc-linux-gnu.tar.gz | 5de2375b033565f1... |
cffe8c9d64e5a3f2... |
| bitcoin-0.19.99-osx-unsigned.dmg | 694ef5744d2f6904... |
df91174c02955b9a... |
| bitcoin-0.19.99-osx64.tar.gz | 0114ae780385b137... |
51d912d768f1b005... |
| bitcoin-0.19.99-riscv64-linux-gnu-debug.tar.gz | 294011ae38c5d280... |
d8fe5794cfa244e3... |
| bitcoin-0.19.99-riscv64-linux-gnu.tar.gz | dbe88f197d552d41... |
bf65a028c4b35b8c... |
| bitcoin-0.19.99-win64-debug.zip | 936007bb2ebddd0d... |
7e9ca6e475a8085c... |
| bitcoin-0.19.99-win64-setup-unsigned.exe | b3c867b01b2d44ec... |
57a649f72a7c7fbe... |
| bitcoin-0.19.99-win64.zip | 1b2d78df9702a910... |
6cb676bb1901ee19... |
| bitcoin-0.19.99-x86_64-linux-gnu-debug.tar.gz | bfb1d4efbb97a704... |
66ff0f451cbceccc... |
| bitcoin-0.19.99-x86_64-linux-gnu.tar.gz | 3511c219e80118c4... |
85d421ac81ef2efb... |
| bitcoin-0.19.99.tar.gz | 65d3c95876c7164a... |
a90c389d2bf2b57f... |
| bitcoin-core-linux-0.20-res.yml | 5bff5ce92c230821... |
654882f47b4f93a3... |
| bitcoin-core-osx-0.20-res.yml | 650bf46df67ba2ff... |
dcc2d6e08aa01482... |
| bitcoin-core-win-0.20-res.yml | 0a1e31be7a54ff9b... |
00ccad7f94509df7... |
| linux-build.log | 8e7bb3e54025c401... |
24f7ebf3e8ff84d4... |
| osx-build.log | 4e705989b74b32a9... |
8768295a6adaab64... |
| win-build.log | 24b7cda24344151a... |
4db17563c61708ea... |
| bitcoin-core-linux-0.20-res.yml.diff | 44253e969ebb269e... |
|
| bitcoin-core-osx-0.20-res.yml.diff | 0a7b46d84b217191... |
|
| bitcoin-core-win-0.20-res.yml.diff | 13d9ece39b905ba0... |
|
| linux-build.log.diff | f6dc2eaf1addd0ff... |
|
| osx-build.log.diff | 10dabac8e9e42fc6... |
|
| win-build.log.diff | 29f7fa6472ae9d17... |
fixes a text scaling issue with rsvg_convert in darwin build
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
Thanks for having a look here, but I’m going to close this. As mentioned, ideally this is something we just wont have to worry about in the future. #16836 also only applies to local builds, which means that there is nearly no-one affected by this. The gitian built images still look fine, and as far as I can tell, are already high-res? i.e this is the appearance of the 0.20.1 release on my machine:
