Blueprint changed by Christopher Adams:
Whiteboard changed:
+ ***THE FOLLOWING IS A NEW PROPOSAL FOR THE FONT UPLOAD PROCESS***
+
+ The current proces dictates a format for a zip file file that users
+ upload in one go. The user waits for the site to churn through the file.
+ If something goes spectacularly wrong or there is an error in any of the
+ files, the entire process will abort, forcing the user to start the
+ process from scratch. The other disadvantage is that it offloads more
+ work onto the end users by making them learn how to arrange the contents
+ of the zip file. The spec puts the whole font family in a single
+ payload!
+
+ Here is a newly proposed process that breaks the font-family creation
+ process into small, more manageable steps (for the user and the site
+ designer).
+
+ ===Members===
+ * a new Member signs up to the site
+ ** the Member has a profile page with contact information.
+ ** the Member can download fonts, favorite fonts, etc.
+
+ ===Creating a new font family===
+ * Profile page or font list pages will have a "Create Font Family" link
+ * Click this link to create a family
+ ** Enter the name of the font family, e.g. "PT Serif";
+ *** This will create a new unique entry in a font_families table
+ ** Enter other info: description, foundry, designer, license, category; these
can be left blank or filled in manually later or derived from the font file;
+ ** The Member can also designate "I am the designer of this font" or just "I
am uploading someone else's design." This distinction will be important for how
fonts are shown in the system and on user profile pages.
+ ** For now, the only piece of information that we need to create a font
family is the name. The name does not have to be unique, but the system can try
to warn the user if they are creating a font family that might already exist.
(Just like reporting bugs on Launchpad.)
+ *** Possible messages: Is this the font you are trying to upload?
+ *** Is this a newer version of XYZ font?
+ *** (For the rest of this discussion we will assume this is a new font)
+ * The Member now has a new, empty font family which is unpublished (invisible
to other users)
+ ** Fonts can only be made public when the user has gone through sufficient
steps (uploading real font files, etc.) and satisfied the system that the
license is correct.
+ * The empty font has a font family edit page where the Member can manage
information and uploads for that font.
+
+ ===Uploading fonts===
+ * From the font family mangagement page, the Member will see a button to
upload files that behaves something like adding an attachment to webmail.
(Click to upload, drag and drop, etc.)
+ * As each file is uploaded, the system will check the file type and file
headers and either accept or reject the file.
+ ** If the upload is a plain text file or image, etc., it will be added as an
attachment or supporting file to the font family that can be viewed or
downloaded.
+ ** If the upload is a font file, the system will read all the metadata and
see if it matches the information provided in the font family, or supply the
missing details. If there is any problem in individual font files or the data
don't match, the user has a chance to correct the errors on a case-by-base
basis.
+ ** Successfully uploaded font files will then appear as separate listings on
the font family page.
+ * Files on the font family page can be downloaded individually or all
packaged together.
+ * Once everything is ready the Member can publish the font
+
+ ===Updating fonts===
+ * There needs to be an additional process for updating fonts. "Upload a new
version" of this font. "Upload an additional format" of this font. This needs
to be spec'd out more.
+
+ ===Remixing a font===
+ * We need a clearer specification for other users to help improve and remix
fonts. Are they just fixing a problem in a single file? Are they uploading new
versions that have better spacing for their language? Etc. This will get pretty
complicated, but the step-by-step font family creation process will hopefully
have more entries into the process.
+
+ After your font family is published, other Members can leave a comment,
+ favorite it, etc.
+
+ Questions remain: How do we avoid collisions between different font
+ versions, uploaders, etc.?
+
+ When uploading a new version of a file, the system can ask:
+ Q1: Is this a new version of the file? Yes/No
+ Q2: Is this a new format of the file? Yes/No
+ Q3: Does this new file supersede the old file? Yes/No
+
+ Based on the answers to these questions, we can determine whether to
+ mark the upload as a new version, or only a different format. If the new
+ file supersedes the old one we can hide it in the history.
+
+ Do creators of a font family then "own" that font family in perpetuity
+ (if they are the designer, sure, but if not....). Maybe people can
+ subscribe to fonts, just like bug tracking.
+
+ Can we auto-generate a FONTLOG.txt from the current data if one doesn't
+ exist?
+
+
+
=================================================================================
+
+ ***OLD WHITEBOARD***
+
I think this sounds super super complicated!
== TODO ==
Figure out how to detect the ${fontFamilyName} from the font files
Figure out how to deal with families of fonts to generate the CSS
properly
Figure out how to deal with remixes properly - when you visit a parent
it should be very obvious that child versions are available, especially
if they have similar names - we want to provide version control
properly, eventually, but the simple thing to do in the mean time is to
just freeze uploads when they happen, and make it obvious that a new
version is available.
Allow the user to specify the preview text used to generate the PCFP
images, and the font preview CSS on the family page, during the upload
process, and make the text smarter based on fontaine's language support
of the font
Figure out how to deal with TTF (if OTF), SVG, EOT, WOFF web font
formats - generate if not already included? OFL renaming issue! "Your
ZIP file does not contain versions of your fonts suitable for all web
browsers. We can generate TTF, SVG, EOT and WOFF format fonts for you
now, if you'd like. We add "OFLB" to the fonts' names to make it clear
they are derivatives made by this site. Please tick this box to agree to
this use of your Reserved Font Names [x]"?
Update fontaine to detect ubuntu font license
###
more:
-
- It's very annoying to get an OFL font and not know where it's coming from or
even if it claims reserved names. Some authors just specify "OFL" as if that
was sufficient. The OFLB upload form should therefore have checkboxes for
uploaders to confirm they have done their homework applying the license in an
ideal way. Including a copy of the license in the font. TrueType and OpenType
allow for this easily and FontForge has made it very easy to add the OFL to
fonts. The upload form should prominently link to a page on [[Font metadata|how
to include a license inside font files]] that gives a step-by-step guide to
doing this; ideally this would be screenshot-illustrated.
+ It's very annoying to get an OFL font and not know where it's coming
+ from or even if it claims reserved names. Some authors just specify
+ "OFL" as if that was sufficient. The OFLB upload form should therefore
+ have checkboxes for uploaders to confirm they have done their homework
+ applying the license in an ideal way. Including a copy of the license in
+ the font. TrueType and OpenType allow for this easily and FontForge has
+ made it very easy to add the OFL to fonts. The upload form should
+ prominently link to a page on [[Font metadata|how to include a license
+ inside font files]] that gives a step-by-step guide to doing this;
+ ideally this would be screenshot-illustrated.
###
still more:
-
-
- We need to agree if files should be filtered on an include or exclude bases.
Exclude may be better than include. We need to decide a definitive list if it's
include-based. For an exclude list, we should exclude files with .exe .php and
so on, and include any files not matching this ban-list. But, one can always
change a file name extension to something else, so testing against the file
extension is probably not very useful.... PHP's $_FILES['userfile']['type']
will indicate the file's mime type if provided by the browser, but how do
browsers determine the mime type for uploaded files? The *nix "file" command
reads the file headers and determines file type based on the pattern of bytes
in the headers of files -- that is the most reliable way to do it. But browsers
may not use a similar method. Perhaps the "Report possible License violation"
feature could be duplicated/extended to "Report possible malicious file" so a
simple machine filter like file extensions would have a social safety net. In
the supposed "upload zip, uncompress zip, if other files added, compress all
the files into a new zip" process, running the "file" command on the files to
check their type matches their file extension at the "uncompress zip" and
"files added" stages would be great.
+ We need to agree if files should be filtered on an include or exclude
+ bases. Exclude may be better than include. We need to decide a
+ definitive list if it's include-based. For an exclude list, we should
+ exclude files with .exe .php and so on, and include any files not
+ matching this ban-list. But, one can always change a file name extension
+ to something else, so testing against the file extension is probably not
+ very useful.... PHP's $_FILES['userfile']['type'] will indicate the
+ file's mime type if provided by the browser, but how do browsers
+ determine the mime type for uploaded files? The *nix "file" command
+ reads the file headers and determines file type based on the pattern of
+ bytes in the headers of files -- that is the most reliable way to do it.
+ But browsers may not use a similar method. Perhaps the "Report possible
+ License violation" feature could be duplicated/extended to "Report
+ possible malicious file" so a simple machine filter like file extensions
+ would have a social safety net. In the supposed "upload zip, uncompress
+ zip, if other files added, compress all the files into a new zip"
+ process, running the "file" command on the files to check their type
+ matches their file extension at the "uncompress zip" and "files added"
+ stages would be great.
$fontlog field should complain if empty. Adding a FONTLOG.txt should
work - TXT to become an allowed file type. Uploading a FONTLOG.txt when
the $fontlog box is null should make the contents of the TXT be copied
to the field. Fontlog field should process markdown when rendered, and
when edited, should have a note saying that it has no rich text like the
Description field because its often distributed as plain text, but link
to Markdown and explain it briefly.
Extract reliable information about the Unicode coverage of typeface
families and use that metadata to add type-centric statistics to the
site, such as signposting which orthographies need better coverage by
free software fonts.
Allow a form of version control of the fonts, so that users have the
ability to see changes in the filesets of each typeface and retrieve
older versions of the typeface. It has been suggested that we adapt
existing ccHost features for this purpose.
Have the Upload forms upload a font file as soon as it is selected, and
parse its metadata and auto-complete other fields in the form. This is a
pretty speculative idea, but would make the upload forms easier.
It seems we want two upload forms: "One click/Easy upload form" -
provide a TTF, a name, read a notice confirming that its OFL, click
upload - and, "Detailed upload form" - all the stuff required for a
typeface family covering multiple scripts with multiple weights and
variants and some unusual but free license. A JS library can be used to
make the easy upload form transform like an Transformers Autobot into
the detailed one.
The upload form/docs should encourage '''authors themselves''' to upload
their own fonts. If others who are not authors post a font it should be
clearly marked as such ("on behalf of" or something like that -
[http://openfontlibrary.org/media/files/davelab6/325 OFLBv1 has
"featuring"]) to indicate who the upstream author is, and provide a link
to the upstream site when it is known. A tickbox "I have checked that
this font isn't violating any author rights" or similar could be useful.
Or fields for admins only on the upload form that allows admins to
denote a font is importing from an existing project on their behalf, eg
Liberation or DejaVu. The effect would be to remove the byline on the
typeface page (such as incorrectly shown in
http://openfontlibrary.fontly.org/files/crossland/4 )
Remix: auto-add the stuff from the original sources to the new FONTLOG?
--
Complete Upload Form
https://blueprints.launchpad.net/openfontlibrary/+spec/complete-upload-form
_______________________________________________
Mailing list: https://launchpad.net/~aikiframework.admins
Post to : [email protected]
Unsubscribe : https://launchpad.net/~aikiframework.admins
More help : https://help.launchpad.net/ListHelp
