Closed pr-apes closed 1 year ago
Not sure if I'd like to change the default. This should be configurable.
BTW, could I have write access to this repository? Otherwise, instead of sending PRs, I have to send snippets such as the previous one.
I'd prefer pull requests or patches. This repository is only a mirror of the main speedata Publisher's repository.
Not sure if I'd like to change the default. This should be configurable.
Could we have this as a first step to make it configurable.
I have to study how to add that before.
But having a default other than black would be interesting (to avoid the link frame taken as a printed matter.
BTW, could I have write access to this repository? Otherwise, instead of sending PRs, I have to send snippets such as the previous one.
I'd prefer pull requests or patches. This repository is only a mirror of the main speedata Publisher's repository.
I only want the writing access to avoid the problem of sending patches: they are both more work for you and me.
Just to be clear, I don't want writing access to commit directly to this repository [that would be crazy]
I have just sent #419 [a minor typo]. I think it would be easier that you could review and approve the pull request that you'd have to rewrite it to a new commit.
I have just sent #419 [a minor typo]. I think it would be easier that you could review and approve the pull request that you'd have to rewrite it to a new commit.
I know it is more work for both of us, but I don't really see a viable alternative for now.
See the commit 3f3351d9c06109883159927c2433e2265b04924c for an example that a) allows setting the values while keeping the default and b) the necessary changes to commands.xml
from which the schema and the documentation is generated.
I really want to keep the defaults if possible so that the users are not surprised when updating the software.
See the commit https://github.com/speedata/publisher/commit/3f3351d9c06109883159927c2433e2265b04924c for an example that a) allows setting the values while keeping the default and b) the necessary changes to
commands.xml
from which the schema and the documentation is generated.
Many thanks for the commit and your explanation, @pgundlach.
BTW, I'm fine with the way of specifying colors for hyperlinksbordercolor
.
But if you allow me a comment, I'm afraid that it is unique and diverging from the explanation about color settings.
I really want to keep the defaults if possible so that the users are not surprised when updating the software.
This is perfectly fine and it totally makes sense.
But if you allow me a comment, I'm afraid that it is unique and diverging from the explanation about color settings.
You are right, this should be fixed.
I was afraid that this would be a non-trivial thing to program, but it should be done correctly to comply with the rest of the color definition.
Great!
@pgundlach,
in order to avoid the default black color in links, I think this could be useful:
Rationale: avoiding the default black color helps to realize that the link border is not printable (only an interactive feature).
BTW, could I have write access to this repository? Otherwise, instead of sending PRs, I have to send snippets such as the previous one.
Many thanks for your help.