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.
Then there is also no need for multiple versions of the logo either, like is currently loaded including the current long filename. > > >> 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. If we go by that scenario, every footer, about page also contain trademark information, that shouldnt be modified. > > 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
