Mixing
Alternative to Markdown with Color support
I am writing on a Note App (Android and REST API built with PHP/Slim 3). I am wondering if there is something else than Markdown to save notes to a readable and interchangeable format. The problem with Markdown for me is that there is no solution to style texts (e.g. colored text). It is also hard to extend Markdown with custom attributes.
I am already thinking of creating an own data format (or using XML). But this means a lot of work for parsing it. I like the idea of using a standard format to interchange it between client/server and between other applications. But the featureset of Markdown is very limited (by design for sure).
Do you have any tips on this topic?
java
android markdown markup asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
add a comment |
I am writing on a Note App (Android and REST API built with PHP/Slim 3). I am wondering if there is something else than Markdown to save notes to a readable and interchangeable format. The problem with Markdown for me is that there is no solution to style texts (e.g. colored text). It is also hard to extend Markdown with custom attributes.
I am already thinking of creating an own data format (or using XML). But this means a lot of work for parsing it. I like the idea of using a standard format to interchange it between client/server and between other applications. But the featureset of Markdown is very limited (by design for sure).
Do you have any tips on this topic?
java
android markdown markup asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
add a comment |
I am writing on a Note App (Android and REST API built with PHP/Slim 3). I am wondering if there is something else than Markdown to save notes to a readable and interchangeable format. The problem with Markdown for me is that there is no solution to style texts (e.g. colored text). It is also hard to extend Markdown with custom attributes.
I am already thinking of creating an own data format (or using XML). But this means a lot of work for parsing it. I like the idea of using a standard format to interchange it between client/server and between other applications. But the featureset of Markdown is very limited (by design for sure).
Do you have any tips on this topic?
java
android markdown markup asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
I am writing on a Note App (Android and REST API built with PHP/Slim 3). I am wondering if there is something else than Markdown to save notes to a readable and interchangeable format. The problem with Markdown for me is that there is no solution to style texts (e.g. colored text). It is also hard to extend Markdown with custom attributes.
I am already thinking of creating an own data format (or using XML). But this means a lot of work for parsing it. I like the idea of using a standard format to interchange it between client/server and between other applications. But the featureset of Markdown is very limited (by design for sure).
Do you have any tips on this topic?
java
android markdown markup java
android markdown markup asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
asked Nov 20 '18 at 19:31
NKnuelleNKnuelle
165
165
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
This question verges on overly-broad, i.e. it may lead to an argument over technologies rather than a "this is the solution" situation.
That being said, here's an answer I think won't be controversial: when you say
"readable, interchangeable format... solution to style texts... custom attributes"
I think HTML. I don't recommend trying to roll-your-own format, because 1.) you are correct that it will be difficult and 2.) it will be even more difficult to match the feature sets of existing solutions
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use aswitchor equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.
– MyStackRunnethOver
Nov 20 '18 at 20:51
add a comment |
To sum it up: I like the idea of using HTML instead of Markdown. It is an open standard format and exchangable as well as human-readable.
The problem I see with all of these solutions: How to write a WYSIWYG-Editor with this in mind? I am already working with Markdown using the Markwon library: https://github.com/noties/Markwon
It is no problem to write Markdown in an Android EditText widget and render it. You can easily convert it back to plaintext (you can save it). It is much more complicated to get a WYSIWYG experience. You have to deal with every User input, writing in a second file or string which contains the Markup while the user just sees the rendered result. The user can edit/delete anything anywhere in the EditText and you have to take care that those changes will affect the Markdown String/File too. I didn't find an easy solution for this.
The easiest way would be to somehow parse the content of the EditText back to Markdown. But there is no getSpannables-method or alike for the EditText widget. I am thinking of looping through the EditText and see what character is there and how it's formatted. But I think this will have disadvantages too, because there are other things like bulleted lists and checkboxes..
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53400253%2falternative-to-markdown-with-color-support%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
This question verges on overly-broad, i.e. it may lead to an argument over technologies rather than a "this is the solution" situation.
That being said, here's an answer I think won't be controversial: when you say
"readable, interchangeable format... solution to style texts... custom attributes"
I think HTML. I don't recommend trying to roll-your-own format, because 1.) you are correct that it will be difficult and 2.) it will be even more difficult to match the feature sets of existing solutions
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use aswitchor equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.
– MyStackRunnethOver
Nov 20 '18 at 20:51
add a comment |
This question verges on overly-broad, i.e. it may lead to an argument over technologies rather than a "this is the solution" situation.
That being said, here's an answer I think won't be controversial: when you say
"readable, interchangeable format... solution to style texts... custom attributes"
I think HTML. I don't recommend trying to roll-your-own format, because 1.) you are correct that it will be difficult and 2.) it will be even more difficult to match the feature sets of existing solutions
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use aswitchor equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.
– MyStackRunnethOver
Nov 20 '18 at 20:51
add a comment |
This question verges on overly-broad, i.e. it may lead to an argument over technologies rather than a "this is the solution" situation.
That being said, here's an answer I think won't be controversial: when you say
"readable, interchangeable format... solution to style texts... custom attributes"
I think HTML. I don't recommend trying to roll-your-own format, because 1.) you are correct that it will be difficult and 2.) it will be even more difficult to match the feature sets of existing solutions
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
This question verges on overly-broad, i.e. it may lead to an argument over technologies rather than a "this is the solution" situation.
That being said, here's an answer I think won't be controversial: when you say
"readable, interchangeable format... solution to style texts... custom attributes"
I think HTML. I don't recommend trying to roll-your-own format, because 1.) you are correct that it will be difficult and 2.) it will be even more difficult to match the feature sets of existing solutions
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
answered Nov 20 '18 at 19:40
MyStackRunnethOverMyStackRunnethOver
782618
782618
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use aswitchor equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.
– MyStackRunnethOver
Nov 20 '18 at 20:51
add a comment |
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use aswitchor equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.
– MyStackRunnethOver
Nov 20 '18 at 20:51
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
I know that this question is unprecise but I didn't know how to ask differently. I already thought of HTML. But there seems to be a big disadvantage using HTML in Android (using Webviews), because of poor performance. To avoid this I need to write my own HTML parser to convert the HTML tags to native android widgets - this is also time-consuming.
– NKnuelle
Nov 20 '18 at 19:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use a
switch or equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.– MyStackRunnethOver
Nov 20 '18 at 20:51
It may not be as bad as you think: I would suggest using an existing HTML parser to get tokens or in-code objects representing the data. This can be limited to exactly the tags, attributes, etc. that you need to read and write, i.e. use a
switch or equivalent and error on anything non-expected, while taking the expected things and converting them into your widgets.– MyStackRunnethOver
Nov 20 '18 at 20:51
add a comment |
To sum it up: I like the idea of using HTML instead of Markdown. It is an open standard format and exchangable as well as human-readable.
The problem I see with all of these solutions: How to write a WYSIWYG-Editor with this in mind? I am already working with Markdown using the Markwon library: https://github.com/noties/Markwon
It is no problem to write Markdown in an Android EditText widget and render it. You can easily convert it back to plaintext (you can save it). It is much more complicated to get a WYSIWYG experience. You have to deal with every User input, writing in a second file or string which contains the Markup while the user just sees the rendered result. The user can edit/delete anything anywhere in the EditText and you have to take care that those changes will affect the Markdown String/File too. I didn't find an easy solution for this.
The easiest way would be to somehow parse the content of the EditText back to Markdown. But there is no getSpannables-method or alike for the EditText widget. I am thinking of looping through the EditText and see what character is there and how it's formatted. But I think this will have disadvantages too, because there are other things like bulleted lists and checkboxes..
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
add a comment |
To sum it up: I like the idea of using HTML instead of Markdown. It is an open standard format and exchangable as well as human-readable.
The problem I see with all of these solutions: How to write a WYSIWYG-Editor with this in mind? I am already working with Markdown using the Markwon library: https://github.com/noties/Markwon
It is no problem to write Markdown in an Android EditText widget and render it. You can easily convert it back to plaintext (you can save it). It is much more complicated to get a WYSIWYG experience. You have to deal with every User input, writing in a second file or string which contains the Markup while the user just sees the rendered result. The user can edit/delete anything anywhere in the EditText and you have to take care that those changes will affect the Markdown String/File too. I didn't find an easy solution for this.
The easiest way would be to somehow parse the content of the EditText back to Markdown. But there is no getSpannables-method or alike for the EditText widget. I am thinking of looping through the EditText and see what character is there and how it's formatted. But I think this will have disadvantages too, because there are other things like bulleted lists and checkboxes..
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
add a comment |
To sum it up: I like the idea of using HTML instead of Markdown. It is an open standard format and exchangable as well as human-readable.
The problem I see with all of these solutions: How to write a WYSIWYG-Editor with this in mind? I am already working with Markdown using the Markwon library: https://github.com/noties/Markwon
It is no problem to write Markdown in an Android EditText widget and render it. You can easily convert it back to plaintext (you can save it). It is much more complicated to get a WYSIWYG experience. You have to deal with every User input, writing in a second file or string which contains the Markup while the user just sees the rendered result. The user can edit/delete anything anywhere in the EditText and you have to take care that those changes will affect the Markdown String/File too. I didn't find an easy solution for this.
The easiest way would be to somehow parse the content of the EditText back to Markdown. But there is no getSpannables-method or alike for the EditText widget. I am thinking of looping through the EditText and see what character is there and how it's formatted. But I think this will have disadvantages too, because there are other things like bulleted lists and checkboxes..
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
To sum it up: I like the idea of using HTML instead of Markdown. It is an open standard format and exchangable as well as human-readable.
The problem I see with all of these solutions: How to write a WYSIWYG-Editor with this in mind? I am already working with Markdown using the Markwon library: https://github.com/noties/Markwon
It is no problem to write Markdown in an Android EditText widget and render it. You can easily convert it back to plaintext (you can save it). It is much more complicated to get a WYSIWYG experience. You have to deal with every User input, writing in a second file or string which contains the Markup while the user just sees the rendered result. The user can edit/delete anything anywhere in the EditText and you have to take care that those changes will affect the Markdown String/File too. I didn't find an easy solution for this.
The easiest way would be to somehow parse the content of the EditText back to Markdown. But there is no getSpannables-method or alike for the EditText widget. I am thinking of looping through the EditText and see what character is there and how it's formatted. But I think this will have disadvantages too, because there are other things like bulleted lists and checkboxes..
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
answered Nov 21 '18 at 9:37
NKnuelleNKnuelle
165
165
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53400253%2falternative-to-markdown-with-color-support%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
