Vector,and,Raster,Technologies computer Vector and Raster Technologies for Joomla

----------------------------------------------------------Permission is granted for the below article to forward,reprint, distribute, use for ezine, newsletter, website,offer as free bonus or part of a product for sale as longas no changes a Gone are those times when the companies and the organisations didn't need a hi-tech system to handle them. Owing to the considerable increase in the business sector and thus, an enormous increase in the complexity of the organisational struc

In the old days, the 90's, raster technology - the use of a single layer as a solution for all visible publishing tasks - was king. Those days are long gone and vector technology rules now. Vector solutions comprise layers of data, and this is the way all modern graphics, web pages, CAD applications, marine charts, printing jobs and much else is done. Understanding the difference between vector and raster technologies is vital for both graphics and web page code. Raster graphics To explain: raster graphics are single-layer files that comprise a 2D description of the data. Two dimensional files - up / down and left / right - are a 'flat' technology that has no depth, and has x-axis and y-axis data only. Three-dimensional technology, or 3D, is a more complete solution that includes depth, ie a z-axis as well. This approach can be applied to more or less anything visible, and is of interest to us for graphics and web page code in particular. Starting with gfx (graphics): in the 90's it was only possible for mainstream applications to use two dimensions. 3D applications were expensive and unusual. Therefore at that time, and then into the early 2000's, it was accepted that 2D information was as good as it gets, for practical purposes. That all changed around 2002 and and these raster solutions became obsolete. Or more correctly, were overtaken by the availability of vector solutions in the mainstream markets. In gfx today for example, Photoshop files are seen as a basic solution and not acceptable for full commercial use. This is because they are just simple 2D raster files. They cannot be scaled, so they are no use for full commercial use such as variable size print jobs. Such files cannot be used except at the size they are supplied, as they cannot scale. As a practical example, if you want to use your logo in a large-scale print job, or on the side of an advertising blimp, you can't. If it were scaled up it would just look like a bad jpeg. You will need a vector graphics file, which can be scaled to any size. An example is an Abobe Illustrator .ai file, which is therefore a level above Photoshop. This may conflict with the popular opinion of Photoshop being the ultimate gfx app - but unfortunately the truth is it's just a basic tool now, professional work often demands a much better application. Raster-based web page code The same thing applies to web page code, whether on hand-coded sites or on database-driven CMS websites. The old, 90's method was, if you like, a 'raster' approach: everything was on a single layer. This is a crude and obsolete way to code pages now. Its use is typified by tables and cells for the layout framework. Around 2002 this method became outdated and layer-based page code took over. This vectorised approach uses layers (divs) and CSS to build the page structure. Having a third axis means that the page code is an order of magnitude better, and there are huge advantages. Just as you cannot use crude raster gfx for many print jobs, crude raster-based 2D pagecode is long outdated for the modern Internet. Vector-based web pages have big advantages in accessibility and SEO for example. Just in SEO, these layer-based pages are so far in advance of flat pages (those using tables) that a site using them has massive advantages. And as in the situation where Photoshop is erroneously seen by the popular media as the top gfx application, in web page authoring many see Dreamweaver as the ultimate tool. However, web authoring applications such as SiteSpinner were using layer-based pages exclusively, years before Dreamweaver had ever heard of such a thing. Joomla's handicap This is why Joomla CMS is now handicapped, as it is still struggling with old 90's technology here. By 2002 table-based layouts were obsolete. By 2004, div-and-table temporary compromises such as the one Joomla uses were finished. The page code layout it uses became obsolete ages ago, and so changes are long overdue. This is the single most vital change that needs to be made to Joomla, and beside this all other requirements seem much less relevant. It's true that skilled developers can mitigate this to some extent, by clever template coding. However, the effects of tables in the code can never be entirely eliminated and it's time they went. Even a remnant of this method left in a corner somewhere wrecks the project, as progress is effectively halted. Once tables have gone completely then the Joomla project will move forward faster and more efficiently. Joomla 1.5 has comprehensive overrides available to template coders. Using these mean that a tableless layout can be implemented via the template, and an example is the Beez template. However this approach tends to result in a very simple and lightweight template, as too much is having to be done by the template coder. It's not a bad thing for SEO, of course, if a template is lightweight - but what if you need a full-feature one with 30 collapsible module positions and 10 built-in colour variations? Almost anything can be plugged in or overridden in Joomla. This is part of the tradition, and one of the many reasons it is such a powerful machine. But there is a limit - at what point do you draw the line and say enough is enough? In theory, taking this to extremes, it wouldn't matter what the core did as long as you could plug something in. There are two areas where it is reasonable to state that core functionality cannot be successfully augmented or overridden, and those are ACL and code layout. ACL needs to be a core function because plugin solutions cannot be said to be 100% successful. Correct code layout needs to be a core function because, again, plugin solutions can only go partway toward fixing the problem. Imagine what would be possible if Joomla had a core tableless code layout scheme. You'd be able to get templates that had, in addition to the usual features, built-in source ordering controls. Now that's what I'd call progress. You might not see that as significant but in terms of SEO and accessibility (best seen as the same thing in any case), that's a massive leap forward. It's correct to say that a developer can do almost anything with Joomla - but that isn't really the point of the project in many peoples' view. What is the point is what the users can do with it - the webmasters who have to work with it. If functions are available to the average webmaster then the application succeeds; if they are not, and are only there for developers, then you have an entirely different beast. That wouldn't be Joomla and it wouldn't be as successful. Why the Joomla 1.5 series was introduced without fixing the code layout issue is hard to understand, since in many ways J1.5 is incompatible with the older version and therefore a major rewrite took place. How the basic foundation changes that are needed were excluded is a bit of a mystery - but that's open-source for you. Roll on Joomla 2.0! Luckily, Joomla is such an incredible multimedia publishing tool that it compares well with the best of them. However, the future looks ominous unless radical changes are made, as it's hard to support steam age technology in the modern world. Article Tags: Raster Technologies, Page Code, Code Layout