I suspect because it would get misused.
Unless you are the author / publisher of the ebook, it's pretty difficult to know absolutely that the person posting it has all the copyright and suchlike permissions required to distribute it, let alone give it away.
And let's face it: most of the ebooks available on the internet are pirate copies at best!
This is not a piracy site: just look at how hard we work to prevent plagiarism in the moderated areas. Adding a forum that is likely to be abused almost immediately, and the validation / moderation that would be required? I can't see the Hamsters going for it...
You looking for sympathy?
You'll find it in the dictionary, between sympathomimetic and sympatric
(Page 1788, if it helps)
I found the issue. It's kinda amusing. Except it's really not.
The links to images in the emails are of the form //domain.com/file.ext. Thie is a URL form that says "get the HTTP or HTTPS version of the file depending on the protocol of the current request". Outlook, in its infinite wisdom, has decided that what it really, truly means is "\\domain.com\file.ext". Meaning when it tries to load the email it is looking for a computer on your network called domain.com. And, given that loading an image from a network location is obviously best done in a manner that blocks the UI thread, the entire Outlook app locks up while it hunts around for \\domain.com.
There is a textbox in the Unsubscribe page between the "Update my subscription" and Orange footer (in the blank white space). It may not be visible, but if you select the whole page (ctrl+A) then the textbox can be seen.
The text box can be very confusing as, people might fill it but it does not do anything.
I have been writing all my new articles and blog posts in Markdown recently, and I have noticed an error in the way codeproject renders the HTML from markdown.
Any code block in markdown is rendered with a <code> element INSIDE a <pre> element, usually with attributes like <code lang="csharp"> or something. I have tried three different Markdown-to-HTML converters, each with slightly different output, but all of them do this. The problem is that CodeProject renders the <code> tag literally. The opening tag is shown on-screen but the closing tag is hidden. You can see this on my recent blog posts like this one:
Preformatted text between the start and end PRE tag is rendered using a fixed with font, in addition whitespace characters are treated literally. The spacing and line breaks are rendered directly, unlike other elements, for which repeated whitespace chararacters are collapsed to a single space character and line breaks introduced automatically.
There are two schools of thought on PRE tags
1. Text inside a PRE tag is pre-formatted. Keep it simple. There's no need to use superfluous decoration.
2. (The semantic argument) PRE says "maintain whitepace formatting" and CPDE says "this is code". The two should go together. Except (in my view) your mixing semantic HTML with formatting HTML which in some minds is a bad thing.
Really, what we should have is <div class="code">
What we're doing isn't "wrong". It's just how we do it in order to keep things simple. the issue we came across with code snippets in PRE tags was that authors often forgot to HTML encode tags in snippets (eg snippets of HTML) and so we instituted a policy of auto-encoding all HTML tags inside PRE blocks, with a few exceptions such as B,I,U and SPAN (to allow emphasis).
- Shouldn't the "Expert mode: Don't mess with my HTML formatting" option prevent this behavior (I just checked: it doesn't)?
- A technical blog has already been published in its final HTML form and presumably the author has reviewed the result. Reprocessing the HTML a second time doesn't make sense.
- OTOH, for article editing, the current behavior is confusing because the rich-text HTML editor hides the <code> element and any other elements inside a <pre> element, but the published version shows such elements.
- As I noted, the reprocessing performed by CodeProject evidently doesn't do what it was intended to do: the initial <code> tag is reencoded as <code> but the closing </code> tag is deleted instead.