December's Most Wanted list

[denise]

Sometimes people look at the list of bugs we have open and wonder which ones would most benefit Dreamwidth, or wonder which ones to start on, or wonder what's most-requested, etc etc etc. I decided that I'd start making a monthly list of the bugs I most want resolved from a business standpoint and posting it, for people to pick from if they find something they find suitable.

This is just my personal list -- Mark may have his own! -- and I've tried to keep it a mixture of little and big.



1. Bug 2203: Paid time gift promotion (claimed by mark)

2. Bug 2092: allow premium-paid users to buy regular paid time within window of expiration

3. Bug 216: Implement renames (claimed by afuna)

4. Bug 135: Gift certificate/credits system

5. Bug 225: Create a single-user backup tool

6. Bug 177: implement admin/sendmail.bml as dw-free

7. Bug 76: Main/alternate account system

8. Bug 32: Export journal as .pdf

9. Bug 1985: Update FCKeditor to version 2.6.5

10. Bug 1433: Sort alpha by keyword on allpics/editpics pages

11. Bug 1230: Replace custom mood theme editor (Claimed by wyntarvox!)

12. Bug 395: Increase syn feed max size (Claimed by me)

13. Bug 31: Expand all comments on page

14. Bug 1239: HTTPS browsing mode

15. Bug 1408: fix up custom domain aliasing on entry pages

16. Bug 34: Index/archive pages, for simple one-click website building

17. Bug 2020: snooze button for specific people on your reading list

18. Bug 478: IM-to-DW chat log formatter

19. Bug 477: Icon table generator (Gonna give this one a try myself.)

20. Bug 500: Importer should be aware of edits if run again

Comments

[vlion]

The primary advantage is that Latex -> PDF tools exist, freely and
reliably; it's also well-known and reams of documentation exist. A
subsidiary advantage is that Latex would be translatable into other
formats, if so needed 'down the road'. Another subsidiary advantage is
that typesetting is largely managed by Other People Whose Code We
Don't Have To Debug.

There *are* other tools to take text & images and convert to PDF. I
would be surprised, however, if they are are as well known, debugged
or as good in licensing for DW.

Let me toss some thoughts down in a more formal fashion about how this
would have to look.

I would expect the architecture to follow this model in some fashion.

Journal DB -> Reformatter -> PDF Generator

The reformatter will be putting the journal into a paperable form
suitable for the PDF generator to receive it. Possibly the
reformatter will manage some of the filtering options as well. A
filter block might be suitable further up the pipe.

The PDF generator will come in one of several flavors; roll-your-own,
use external library(e.g., CPAN's PDF exporters), use latexy tool that
adds a new step in the process, possibly allowing output in non-pdf
formats as well.

Suppose we have some kind of filter block and use latex:

DB -> Filter -> Reformatter -> Latex Generator-> Latex/PDF generator.

The filter will be managing queries and ensuring that only the 'right'
data comes through.

The reformatter will be doing such things as large comment thread
management, image management, etc.

The latex generator will be reading the "ready-to-go" data and
outputting a Latex text document that has the content.

Of course, latex itself can produce final output in pdf, html,
man(prob-ably not needed), and I expect it to continue being able to
output in whatever formats come onto the scene and are widely
accepted.

Yet, I see some basic challenges with my idea:

1. Latex. It's mind-blowingly annoying at times and requires Yet
Another set of highly specialized knowledge.

2. Latex. It's not the most general thing on the market without
modifications. What happens if we get a group of non-English users?
Document handling for them has to come into being then.

3. Latex. It's a sledgehammer. Is the problem a screw? It'll still Jam
The Widget Into The Thingie, but maybe it's not quite the right kind
of jamming that a screwdriver will provide.

[superluminal]

(La)TeX today has quite good support for non-Latin writing systems and other aspects of i18n, especially if you use the XeTeX engine for native Unicode and Opentype support.

[vlion]

Aaaah. I don't use non-Latin fonts, so I was ignorant. Thank you!