On Tue, Aug 13, 2013 at 10:34 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> > On Aug 13, 2013, at 5:57 PM, Alexandro Colorado wrote: > > > On 8/13/13, Dave Fisher <dave2w...@comcast.net> wrote: > >> > >> On Aug 13, 2013, at 4:07 PM, Alexandro Colorado wrote: > >> > >>> On Tue, Aug 13, 2013 at 5:04 PM, Dave Fisher <dave2w...@comcast.net> > >>> wrote: > >>> > >>>> Speaking of a confusing email exchange. This is difficult for busy > >>>> people > >>>> in the last 24 hours how many messages have been posted? A lot. By how > >>>> many > >>>> people? Not many and most by one person. > >>>> > >>>> Did anyone create a CWiki page to outline an actual proposal and > >>>> possible > >>>> variations? > >>>> > >>> > >>> I created this page: > >>> > https://cwiki.apache.org/confluence/display/OOOUSERS/File+handling+proposal+for+logos+and+graphics > >> > >> I edited the root files and made it into a table where the disposition > of > >> each file and folder can be developed and approved. > > > > ok but I do believe this proposal was for images and logo, and adding > > all the other directories put some overhead to what the proposal is > > about. I did include the files to identify possible conventions. > > We can separate the two or we can expand this into an overall ooo-site > cleanup. Agree to the plan and then individuals can divide and conquer. > > I think that the tabular format is one qw should consider it will allow > for a clear description of the plan. Redirection of old names to new could > be helpful for name changes. > Can we sort the table so that al images are on the top, then the html/css and finally the directories? > > Also, decisions made could easily effect various NL sites. We really need > to be very deliberate here. > > Regards, > Dave > > > > > > >> > >> Please don't overwrite it. Allow others to contribute. I suggest a > similar > >> format for other directories. > >> > >> Regards, > >> Dave > >> > >>> > >>> > >>> > >>> > >>>> > >>>> I would like to know what the delta is from what we are doing now to > any > >>>> new state in order to see if I agree or have another choice. > >>>> > >>>> Regards, > >>>> Dave > >>>> > >>>> On Aug 13, 2013, at 2:04 PM, Alexandro Colorado wrote: > >>>> > >>>>> On 8/13/13, Ricardo Berlasso <rgb.m...@gmail.com> wrote: > >>>>>> 2013/8/13 Alexandro Colorado <j...@oooes.org> > >>>>>> > >>>>>>> On 8/13/13, Kay Schenk <kay.sch...@gmail.com> wrote: > >>>>>>>> On Tue, Aug 13, 2013 at 2:04 AM, Alexandro Colorado < > j...@oooes.org> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>>> On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir <robw...@apache.org> > >>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado > >>>>>>>>>> <j...@oooes.org> > >>>>>>>>> wrote: > >>>>>>>>>>> On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir <robw...@apache.org> > >>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado > >>>>>>>>>>>> <j...@oooes.org > >>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>>>> I think the image structure on the website is a bit messy, > >>>>>>>>>>>>> there > >>>>>>>>>>>>> has > >>>>>>>>>> been > >>>>>>>>>>>>> some cleanup done by kschenk but I think there is still a lot > >>>>>>>>>>>>> of > >>>>>>>>>> clean up > >>>>>>>>>>>>> work to be done. > >>>>>>>>>>>>> > >>>>>>>>>>>>> For example, the new logo, was simply draged and drop to the > >>>>>>>>> AOOLogos > >>>>>>>>>>>>> folder with a huge name. I understand the name was needed to > >>>>>>>>> identify > >>>>>>>>>> it > >>>>>>>>>>>>> between the rest of the competitive logos. But now that is > >>>>>>>>>>>>> selected, > >>>>>>>>>> the > >>>>>>>>>>>>> current name is unecessary long. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png< > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>> > http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Right. That work is incomplete. I checked it in originally, > >>>>>>>>>>>> after > >>>>>>>>>>>> the logo vote, so we could start working on the product > >>>>>>>>>>>> integration > >>>>>>>>>>>> immediately. But note that the above logo is not the one we > >>>>>>>>>>>> actually > >>>>>>>>>>>> used in AOO 4.0 !! > >>>>>>>>>>>> > >>>>>>>>>>>> The one we actually used is this one: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>> > https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg > >>>>>>>>>>>> > >>>>>>>>>>>> This was Chris R's contest logo with some minor technical > >>>>>>>>>>>> changes. > >>>>>>>>>>>> Kevin G. used this and generated the PNG/JPG files for AOO > 4.0, > >>>>>>>>>>>> which > >>>>>>>>>>>> I helped check in. > >>>>>>>>>>>> > >>>>>>>>>>>> My intent was to take that SVG and rename it to > >>>>>>> "master-logo-40.svg" > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Again I think we do need a convention for a "logo.svg" as > opposed > >>>>>>>>>>> to > >>>>>>>>>>> ending with a logo-30.svg logo-40.svg logo-50.svg. An just > >>>>>>>>> incrementally > >>>>>>>>>>> replace with the future logos as we update the SVG. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Here's the complication: The old logos are still relevant some > >>>>>>>>>> some > >>>>>>>>>> purposes. For example, the PMC receives ongoing requests to > >>>>>>>>>> approve > >>>>>>>>>> use of the old OpenOffice.org logo. Why would that happen? > Often > >>>>>>>>>> it > >>>>>>>>>> is a request by publishers who are making an e-book version of > an > >>>>>>>>>> older print book. If their original request did not include the > >>>>>>>>>> e-book rights then they come back to us (and owners of every > other > >>>>>>>>>> image they use) to request additional permissions. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I think that 'complication' is the lesser of two evils., compared > >>>>>>>>> to > >>>>>>>>> having to manage a ever growing ammount of images. And beside > that, > >>>> do > >>>>>>>>> you > >>>>>>>>> realize the difference in objectives between ooo-site/images/ > >>>>>>>>> ooo-site/marketing/art/images/ and ooo-site/branding/images. > >>>>>>>>> > >>>>>>>>> I dont see any reason why those issues should impact the web > works > >>>>>>>>> of > >>>>>>>>> ooo-site/images/. That folder is for website-design related work. > >>>>>>>>> It > >>>>>>> has, > >>>>>>>>> or shouldnt hold any porpouse to archieve past work, nor to hold > >>>>>>>>> description of any kind. I think website should be as lean and > easy > >>>> to > >>>>>>>>> follow since we expect these conventions be followed by a > rotating > >>>>>>>>> community. So again K.I.S.S. > >>>>>>>>> > >>>>>>>> > >>>>>>>> No, it shouldn't. The ooo-site/images areas got the logo added to > it > >>>>>>> simply > >>>>>>>> because to make it easier to locate it. The other images files > there > >>>>>>> belong > >>>>>>>> to the home page. The svg sub-directory here is really the > >>>>>>>> mis-placed > >>>>>>> one. > >>>>>>> > >>>>>>> Actually I would like to see getting rid of the rasterize images > >>>>>>> instead. Modern browsers already process SVG natively without > issues. > >>>>>>> > >>>>>> > >>>>>> > >>>>>> Well, that's not completely true: even if not "modern" any more > there > >>>> are > >>>>>> literally millions of people still using internet explorer 8 or even > >>>> older > >>>>>> versions, and SVG support was *partially* implemented only from IE9. > >>>>>> IE8 > >>>>>> needs a plug-in for SVG rendering. > >>>>>> > >>>>>> http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Compatibility > >>>>> > >>>>> That's why I recomend and reference javascript libraries that take > >>>>> care of legacy browsers additionally there are fallback techniques > >>>>> (http://dbushell.com/2012/04/03/svg-use-it-already/). Then again, > you > >>>>> can just test this easily using browsershots or something similar and > >>>>> evaluate. > >>>>> > >>>>>> > >>>>>> Regards > >>>>>> Ricardo > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Also there are js libraries that ensure browser compatibility like > >>>>>>> the > >>>>>>> svgweb.js library: > >>>>>>> http://code.google.com/p/svgweb/ > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> If those complications arises, send them to marketing or branding > >>>>>>>>> workspaces. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> So it may be possible, going forward, to store logos as SVN > >>>>>>>>>> revisions > >>>>>>>>>> under the same name. But we cannot retroactively do this with > >>>>>>>>>> pre-Apache logos. And even if we could, this is harder for > users > >>>>>>>>>> of > >>>>>>>>>> the logo to access. It is much easier to have something like > >>>>>>>>>> logo-330.svg available via HTTP. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> svg are just like HTML files, they are markup languages, we dont > >>>>>>>>> hold > >>>>>>> the > >>>>>>>>> index.html inmaculated and hold an apache-index.html and > >>>>>>>>> oracle-index.html, > >>>>>>>>> so I dont see why SVG should be any different. > >>>>>>>> > >>>>>>>> > >>>>>>>> I don't agree this assessment. The svg files contain branding, or > >>>>>>>> trademark sources. These are entities which should not be changed > >>>>>>>> -- > >>>>>>>> resulting in a trademark violation. If there is something wrong > with > >>>>>>>> the > >>>>>>>> SVG files for whatever reason, this needs to undergo a > justification > >>>>>>>> discussion. > >>>>>>>> > >>>>>>>> The only porpouse of having > >>>>>>>>> a source file, is for users to be able to modify it on the first > >>>>>>>>> place. > >>>>>>>>> Either by integrating to a bigger SVG design, or resizing it for > >>>> print > >>>>>>>>> work. > >>>>>>>>> > >>>>>>>> > >>>>>>>> This part I do agree with. The svg files can be used to produce > >>>> various > >>>>>>>> sizes of the "trademarked" entities. Changing the source of that > >>>> entity > >>>>>>> is > >>>>>>>> a different matter in my opinion. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Of course you can have a hybrid approach: > >>>>>>>>>> > >>>>>>>>>> 1) When a new logo is introduced, svn copy the old one into a > >>>>>>>>>> /old-logos directory with a new descriptive name. This > preserves > >>>>>>>>>> the > >>>>>>>>>> version history. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> This is not functional and just start acumulating part of the > same > >>>>>>>>> garbage > >>>>>>>>> that svn is supposed to clean up. Again, if this was code, this > >>>>>>>>> would > >>>>>>>>> be > >>>>>>>>> totally unacceptable approach. If new logos are introduced then > >>>>>>>>> they > >>>>>>>>> should > >>>>>>>>> replace the current logo, and the old will live in anals of the > svn > >>>>>>> logs. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2) New logo then is checked in as a new revision of > >>>>>>>>>> logo-master.svg. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> People are free to disagree with me, but I think this is a messy > >>>>>>>>> way > >>>>>>>>> to > >>>>>>>>> work, and for a webdev folder is completely useless, specially > when > >>>>>>> there > >>>>>>>>> is a whole different project specialized on archiving, > developing, > >>>> and > >>>>>>>>> multiplying artwork inside marketing, and a whole different > project > >>>>>>>>> devoted > >>>>>>>>> to specifying the guideliness of the brand (aka logo). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Regards, > >>>>>>>>>> > >>>>>>>>>> -Rob > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> or something clean like that. However, I have not had any > luck > >>>>>>>>>>>> getting this logo to load into Inkscape or Adobe Illustrator. > I > >>>>>>> get > >>>>>>>>>>>> errors. And I have not had any luck getting Kevin to send a > >>>>>>> version > >>>>>>>>>>>> that will load. > >>>>>>>>>>>> > >>>>>>>>>>>> So we're stuck right now with a logo that does load into > >>>>>>>>>>>> Inkscape, > >>>>>>>>>>>> but > >>>>>>>>>>>> is slightly different than the one we used in AOO 4.0. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> At the same time we have old logos which had been untouch. I > >>>>>>> think > >>>>>>>>> the > >>>>>>>>>>>>> webdevs have small understanding of a svn is builted so that > >>>>>>>>>>>>> the > >>>>>>>>> files > >>>>>>>>>>>> are > >>>>>>>>>>>>> updated without having different versions laying arround. > Over > >>>>>>>>>>>>> this > >>>>>>>>>>>>> example, ooo-logo.png and > >>>>>>>>>>>>> AOO4_website_logo.png< > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>> > http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/AOO4_website_logo.png?view=log > >>>>>>>>>>>>> exist. > >>>>>>>>>>>>> > >>>>>>>>>>>>> All these proliferation of logos, usually will built up to > >>>>>>>>>>>>> become > >>>>>>>>>>>>> incredibly messy to work. I suggest to put the information > such > >>>>>>> as > >>>>>>>>>>>> author, > >>>>>>>>>>>>> version, status, etc. on the comments of the commit and not > on > >>>>>>> the > >>>>>>>>>>>>> filename. Likewise to take the time to look for the source > of > >>>>>>> the > >>>>>>>>>> image, > >>>>>>>>>>>>> since there is an SVG/ folder to link the source of them, and > >>>>>>>>> finally > >>>>>>>>>> if > >>>>>>>>>>>>> there are different images (sizes) to have a common > convention. > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> A more logical naming scheme would be good, I agree. But this > >>>>>>>>>>>> has > >>>>>>>>>>>> been waiting for resolution of which SVG we should actually be > >>>>>>>>>>>> using. > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> -Rob > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> If you want to review the images please go here: > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>> > http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> Alexandro Colorado > >>>>>>>>>>>>> Apache OpenOffice Contributor > >>>>>>>>>>>>> http://www.openoffice.org > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>>>>>>>>>> For additional commands, e-mail: > dev-h...@openoffice.apache.org > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Alexandro Colorado > >>>>>>>>>>> Apache OpenOffice Contributor > >>>>>>>>>>> http://www.openoffice.org > >>>>>>>>>> > >>>>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Alexandro Colorado > >>>>>>>>> Apache OpenOffice Contributor > >>>>>>>>> http://www.openoffice.org > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> > >>>>>>> > >>>> > ------------------------------------------------------------------------------------------------- > >>>>>>>> MzK > >>>>>>>> > >>>>>>>> Success is falling nine times and getting up ten." > >>>>>>>> -- Jon Bon Jovi > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Alexandro Colorado > >>>>>>> Apache OpenOffice Contributor > >>>>>>> http://www.openoffice.org > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Alexandro Colorado > >>>>> Apache OpenOffice Contributor > >>>>> http://www.openoffice.org > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >>>> > >>>> > >>> > >>> > >>> -- > >>> Alexandro Colorado > >>> Apache OpenOffice Contributor > >>> http://www.openoffice.org > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > > > > > -- > > Alexandro Colorado > > Apache OpenOffice Contributor > > http://www.openoffice.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org
