I'm considering commissioning high quality artworks of a few scenes in horny stories I've written. I'm wondering, if I did this, could I then dump the surrounding story's text into the description? Is this allowed, and is there a character limit for post descriptions? If the limit is too restrictive, I would need to just put a link to the FurAffinity post with the PDF, I suppose.
Topic: Do post descriptions have a character limit?
Posted under General
Looks like there's a 50,000 character limit on descriptions (type something into the description box, and it'll show the current / limit allowed).
Just make sure to put it into a collapsed [section] if it's more than a few paragraphs long.
did you know we also have story_in_description tag
fliphook said:
did you know we also have story_in_description tag
Did you know we also have story_in_comments tag?
The 50,000 character limit for the descriptions could be essentially bypassed by posting the stories into multiple comments.
thegreatwolfgang said:
The 50,000 character limit for the descriptions could be essentially bypassed by posting the stories into multiple comments.
Wouldn't that be considered an abuse of site tools? The description character limit is likely there for a reason, and bypassing it by continuing the description in comments would not only be getting around a site limit, but also be pretty annoying to scroll past extra comments to get to the real ones.
thegreatwolfgang said:
Did you know we also have story_in_comments tag?The 50,000 character limit for the descriptions could be essentially bypassed by posting the stories into multiple comments.
Probably a bad idea, not just because of what Watsit mentioned but also because you can't guarantee continuity (someone could post while you're readying the next one).
watsit said:
Wouldn't that be considered an abuse of site tools? The description character limit is likely there for a reason, and bypassing it by continuing the description in comments would not only be getting around a site limit, but also be pretty annoying to scroll past extra comments to get to the real ones.
I don't remember if we had a case of someone doing this yet, but I would advise people against it.
e621 is primarily an aggregator of images and videos, not stories.
Thankfully, my story chapters are less than 50 thousand characters. That's actually a pretty good limit, because they can get to be tens of thousands of characters. But in some cases I'll post multiple images per chapter, so it'll probably be approx 10k characters per post? Still, I'll keep in mind to collapse it, since e621 is not story-focused.
watsit said:
Wouldn't that be considered an abuse of site tools? The description character limit is likely there for a reason, and bypassing it by continuing the description in comments would not only be getting around a site limit, but also be pretty annoying to scroll past extra comments to get to the real ones.
cinder said:
I don't remember if we had a case of someone doing this yet, but I would advise people against it.
e621 is primarily an aggregator of images and videos, not stories.
It has only been done once as far as I can tell (on post #2754092), though they only used the comments instead of both the description and comments.
I wouldn't go as far as reporting it as Abuse of Site Tools as long as they did it within reason and is not outright disruptive.
Then again, if a story is going to be that long, we also have story_at_source which could point users to a more text-friendly site like FurAffinity, SoFurry, or Archive of Our Own.
also, as a note, most of DText formatting stuff is available when writing post descriptions, but not [color], for some reason. you likely weren't intending to use it, but just in case you were thinking about it.
dba_afish said:
also, as a note, most of DText formatting stuff is available when writing post descriptions, but not [color], for some reason. you likely weren't intending to use it, but just in case you were thinking about it.
I vaguely remember mentioning this when I did a minor overhaul of dtext previews, I believe I was told to leave it as is so it seems intentional.... for some reason
They also dont allow thumb #, but everything else should work fine
dba_afish said:
also, as a note, most of DText formatting stuff is available when writing post descriptions, but not [color], for some reason. you likely weren't intending to use it, but just in case you were thinking about it.
Probably because colour is a Priv+ user-only privilege.
thegreatwolfgang said:
Probably because colour is a Priv+ user-only privilege.
it's available on other non-comment DText stuff regardless of user level, like wiki pages and user abouts both allow them. descriptions not allowing it feels like an outlier.
thegreatwolfgang said:
Probably because colour is a Priv+ user-only privilege.
It's available in many places to non privileged users, it's only explicitly disabled in a few placss
I have a list here
Which going by that color was supposed to be always allowed on posts, but I forgot to enable it when rendering the description
If you asked me I'd personally allow color everywhere and add a user setting to disable color, but I got shot down for that multiple times
The trouble with color is that its readability is entirely dependent on themes. It's the sort of thing that's fun to have but which creates accessibility nightmares if you open it up to just anybody to mess about with. There are hypothetically ways around it (I remember some streaming site giving chat members a hue slider to choose the color of their name, and the brightness of each hue was automatically adjusted to maintain readability against the theme's background), but it's not worth the effort to code.
donovan_dmc said:
If you asked me I'd personally allow color everywhere and add a user setting to disable color, but I got shot down for that multiple times
Can't say I like that idea. You know people would end up just using non-standard colors for all their comments, as a way to stand out or draw attention to themselves, which as Errorist says can make it hard to read depending on the selected theme, or be distracting. Disabling color altogether seems like a heavy-handed fix, as it would still be nice to see an occasional splash of colored text when done with legitimate purpose, but that's really only possible if it's a feature given to users that show themselves to behave more responsibly.
watsit said:
Can't say I like that idea. You know people would end up just using non-standard colors for all their comments, as a way to stand out or draw attention to themselves, which as Errorist says can make it hard to read depending on the selected theme, or be distracting. Disabling color altogether seems like a heavy-handed fix, as it would still be nice to see an occasional splash of colored text when done with legitimate purpose, but that's really only possible if it's a feature given to users that show themselves to behave more responsibly.
Considering the list of users that can actually use colors is 142 (including the "fake" users), with likely 40+ of those being completely inactive users, seeing an "occasional" splash of colored text is more like a "once in a blue moon" splash of colored text
Also if it were available to everyone, why would there not be rules against overusing it or trying to make barely visible text
It would also almost certainly have accessibility changes were it more widely available
watsit said:
Can't say I like that idea. You know people would end up just using non-standard colors for all their comments, as a way to stand out or draw attention to themselves, which as Errorist says can make it hard to read depending on the selected theme, or be distracting. Disabling color altogether seems like a heavy-handed fix, as it would still be nice to see an occasional splash of colored text when done with legitimate purpose, but that's really only possible if it's a feature given to users that show themselves to behave more responsibly.
I mean, there are already ways to put hidden text in your messages anyway. more invisible than coloured text even, seeing as [#page_anchors] are pretty much # in the actual final styled DText, only showing up when you quote the message or view the HTML.
dba_afish said:
I mean, there are already ways to put hidden text in your messages anyway. more invisible than coloured text even, seeing as [#page_anchors] are pretty much # in the actual final styled DText, only showing up when you quote the message or view the HTML.
Not really about hidden text, but people trying to make their comments stand out by constantly using colors, that makes it hard to read for some people depending on the selected theme. Using colors unnecessarily that works fine for some people and is a problem for others as a way to be different is a different matter compared to purposely hiding text that no one can see, the former being something people in general have shown a habit of doing on sites when given the option.
watsit said:
Not really about hidden text, but people trying to make their comments stand out by constantly using colors, that makes it hard to read for some people depending on the selected theme. Using colors unnecessarily that works fine for some people and is a problem for others as a way to be different is a different matter compared to purposely hiding text that no one can see, the former being something people in general have shown a habit of doing on sites when given the option.
well there could be ways to work around that being an issue. all coloured text has the class .dtext-color if we just made sure it had a text shadow that contrasts with the background it should always be legible regardless of the text's color.
something like:
body {
--color-contrast: var(--color-section-lighten-10);
}
body[data-th-main="serpent"],
body[data-th-main="hotdog"] {
--color-contrast: var(--color-link);
}
.dtext-color {
text-shadow:
-1px 0 0 var(--color-contrast),
0 1px 0 var(--color-contrast),
1px 0 0 var(--color-contrast),
0 -1px 0 var(--color-contrast),
-.7px -.7px 0 var(--color-contrast),
-.7px .7px 0 var(--color-contrast),
.7px .7px 0 var(--color-contrast),
.7px -.7px 0 var(--color-contrast);
}thegreatwolfgang said:
Probably because colour is a Priv+ user-only privilege.
...I thought I was losing my damn mind trying this out in the past. Did we just forget to put this on the DText help page? For that matter, why isn't ltable on there?
aacafah said:
For that matter, why isn't ltable on there?
...
oh my god, is there really a way to do tables that dosn't require to do that crazy nesting of elements?
| header | header | header |
|---|---|---|
| body | body | body |
| body | body |
that is _so_ much easier.
the only problem is that its use of | to parse when cells start and end means that you can't do piped wiki/search links.
dba_afish said:
...
oh my god, is there really a way to do tables that dosn't require to do that crazy nesting of elements?
header header header body body body body bodybody that is _so_ much easier.
the only problem is that its use of | to parse when cells start and end means that you can't do piped wiki/search links.
That's probably a legacy syntax that I would not be surprised to not be ported if dtext ever gets rewritten (probably because it will be forgotten about)
In fact, it isnt even part of the ragel dtext, its completely outside of it, it's converted to the proper format before actually being passed to dtext
donovan_dmc said:
That's probably a legacy syntax that I would not be surprised to not be ported if dtext ever gets rewritten (probably because it will be forgotten about)
If someone does forget, the fact that this is how the search cheatsheet page makes its tables will probably serve as a reminder (unless someone rewrites it to remove them for whatever reason); that's how I figured out this exists.
I like how this thread went from talking about post description character limits, to coloured text privileges, and then to how ltable is becoming a lost art.
TBH, long descriptions in the DB Export are a mildly annoyiny. It would be nice if descriptions were not in the same CVS file.
Comments might actually be better for the stories, but putting parts of the story with each image in a set has also been done. So a 4-image comic turns into 4 separate 50K segments. If all you care about is preservation of the story, you can also put it into the image file itself before uploading. PNG has no theoretical limit, but JPEG Exif has a 64KB limit. Beware that PNG images may be trouble loading with such large comments. WebP of course allows both Exif and XMP and thus has no real limits, just like PNG.
Weirdly, there's a stupid hack where people appended ZIP files to image files, but that stuff will get stripped out on most any site now, and is trivial to block uploads of.
As far as stories go, might want to link to a source with the full story text that is less likely to go down. I tend to put sources of posts I upload on archive.org because of reasons like this.
Updated
alphamule said:
TBH, long descriptions in the DB Export are a mildly annoyiny. It would be nice if descriptions were not in the same CVS file.
They aren't really that bad
In my local copy of the exports the descriptions make up about 449MB
And for the actual text size, that seems to be around 523MB
iirc the total files of the export is over 4 GB, so that's really not that much
donovan_dmc said:
They aren't really that bad
In my local copy of the exports the descriptions make up about 449MBAnd for the actual text size, that seems to be around 523MB
iirc the total files of the export is over 4 GB, so that's really not that much
TBF, I figured it out when realizing why a tool that should work fine with a few thousand characters per line barfed on a 40K+ line. Also, TBF, that's actually a potential exploit that they bandaided. I moved to ring buffers for this in my own code.
Also, opening in a text editor (joke).
colors are allowed in descriptions now, btw.
edit: or, post descriptions, at least. pool descriptions still ignore them.
Updated