Improve image handling using the figure.html include.

_docs/concepts/network-and-auth/auth.md

@@ -32,7 +32,11 @@ In future versions it will also provide:
 
 The figure below shows the Istio Auth architecture, which includes three components: identity, key management, and communication security. It describes how Istio Auth is used to secure service-to-service communication between service A, running as service account "foo", and service B, running as service account "bar".
 
-<img style="display:block;margin:auto" src="./img/auth/auth.svg" title="Istio Auth Architecture." />
+{% include figure.html
+    file="./img/auth/auth.svg"
+    title="Istio Auth Architecture"
+    alt="Components making up the Istio auth model."
+%}
 
 ## Components
 

_docs/concepts/policy-and-control/mixer-config.md

@@ -47,7 +47,10 @@ attributes determines which backend Mixer calls for a given request and what par
 each is given. In order to hide the details of individual backends, Mixer uses modules
 known as [*adapters*](./mixer.html#adapters).
 
-![Attribute Machine](./img/mixer-config/machine.svg)
+{% include figure.html
+   file="./img/mixer-config/machine.svg"
+   alt="Attribute Machine"
+%}
 
 Mixer's configuration has two central responsibilities:
 

_docs/concepts/policy-and-control/mixer.md

@@ -27,8 +27,12 @@ just define a universal logging API, universal metric API, universal billing API
 change the boundaries between layers in order to reduce systemic complexity, eliminating policy logic from service code and giving control
 to operators instead.
 
-<img style="display:block;width:60%;margin:auto;" src="./img/mixer/traffic.svg" title="Flow of traffic." />
-<p style="text-align:center;">Mixer Traffic Flow</p>
+{% include figure.html
+    file="./img/mixer/traffic.svg"
+    max-width="60%"
+    title="Mixer Traffic Flow"
+    alt="Showing the flow of traffic through Mixer."
+%}
 
 Mixer provides three core features:
 
@@ -52,7 +56,6 @@ Mixer is a highly modular and extensible component. One of it's key functions is
 away the details of different policy and telemetry backend systems, allowing Envoy and Istio-based
 services to be agnostic of those backends, which keeps them portable.
 
-
 Mixer's flexibility in dealing with different infrastructure backends is achieved by having a general-purpose
 plug-in model. Individual plug-ins are known as *adapters* and they allow
 Mixer to interface to different infrastructure backends that deliver core functionality, such as logging, monitoring, quotas, ACL
@@ -60,7 +63,13 @@ checking, and more. Adapters enable Mixer to expose a single consistent API, ind
 The exact set of adapters used at runtime is determined through configuration and can easily be extended
 to target new or custom infrastructure backends.
 
-<img style="width:35%;display:block;margin:auto;" src="./img/mixer/adapters.svg" title="Mixer and its adapters." />
+{% include figure.html
+    file="./img/mixer/adapters.svg"
+    max-width="35%"
+    title="Mixer and its Adapters"
+    alt="Showing Mixer with adapters."
+    caption=""
+%}
 
 ## Configuration state
 
@@ -104,8 +113,12 @@ configured through a simple declarative form as described [here](./mixer-config.
 Processing phase creates a set of adapter parameters. The Adapter Dispatching phase invokes the adapters
 associated with each aspect and passes them those parameters.
 
-<img style="display:block;width:50%;margin:auto;" src="./img/mixer/phases.svg" title="Phases of mixer request processing" />
-<p style="text-align:center;">Request Phases</p>
+{% include figure.html
+    file="./img/mixer/phases.svg"
+    max-width="50%"
+    title="Request Phases"
+    alt="Phases of Mixer request processing."
+%}
 
 ## Scripting
 
@@ -121,7 +134,3 @@ of accessing the request's incoming attributes and producing the requisite adapt
 
 For advanced uses, the operator can bypass the declarative format and author directly in the scripting
 language. This is more complex, but provides ultimate flexibility.
-
-
-
-

_docs/concepts/traffic-management/load-balancing.md

@@ -21,7 +21,10 @@ registry and provides a platform-agnostic service discovery
 interface. Envoy instances in the mesh perform service discovery and 
 dynamically update their load balancing pools accordingly.
 
-<img class="center-image-75" src="./img/manager/LoadBalancing.svg" title="Istio - Discovery & Load Balancing." />
+{% include figure.html
+    file="./img/manager/LoadBalancing.svg"
+    alt="Discovery and Load Balancing"
+%}
 
 As illustrated in the figure above, services in the mesh access each other
 using their DNS names. All HTTP traffic bound to a service is automatically

_docs/concepts/traffic-management/manager.md

@@ -15,7 +15,11 @@ APIs for [service discovery](https://lyft.github.io/envoy/docs/configuration/clu
 platform-specific nuances, simplifying the design and increasing
 portability across platforms.
 
-<img class="center-image-75" src="./img/manager/ManagerAdapters.svg" title="Istio-Manager - architecture." />
+{% include figure.html
+    file="./img/manager/ManagerAdapters.svg"
+    title="Istio-Manager Architecture"
+    alt="Istio-Manager's overall architecture."
+%}
 
 As illustrated in the figure above, Istio-Manager maintains a canonical representation of services in the
 mesh that is independent of the underlying platform. Platform-specific

_docs/concepts/traffic-management/overview.md

@@ -14,7 +14,11 @@ set of pods/VMs should receive traffic (e.g., by adding/removing specific
 labels). Unlike existing techniques, Istio decouples traffic flow and infrastructure
 scaling. 
 
-<img src="./img/manager/TrafficManagementOverview.svg" title="Traffic Management with Istio." />
+{% include figure.html
+    file="./img/manager/TrafficManagementOverview.svg"
+    max-width="85%"
+    alt="Traffic Management with Istio"
+%}
 
 As illustrated in the figure above, Istio allows operators to control what
 percentage of traffic should be routed to these pods or which requests

_docs/concepts/traffic-management/request-routing.md

@@ -27,7 +27,11 @@ additional control over traffic between services.
 
 ## Communication between services
 
-<img class="center-image-75" src="img/manager/ServiceModel_Versions.svg" title="Istio service model - service versions." />
+{% include figure.html
+    file="./img/manager/ServiceModel_Versions.svg"
+    title="Service Versions"
+    alt="Showing how service versions are handled."
+%}
 
 As illustrated in the figure above, clients of a service have no knowledge
 of different versions of the service. They can continue to access the
@@ -58,4 +62,8 @@ operators can add failure recovery features such as circuit breakers,
 impose rate limits via Mixer, and provide authentication using
 Istio-Auth service.
 
-<img src="img/manager/ServiceModel_RequestFlow.svg" title="Istio service model - ingress and egress Envoy." />
+{% include figure.html
+    file="./img/manager/ServiceModel_RequestFlow.svg"
+    title="Request Flow"
+    alt="Ingress and Egress Envoy"
+%}

_docs/concepts/what-is-istio/overview.md

@@ -54,12 +54,17 @@ An Istio service mesh is logically split into a **data plane** and a **control p
 
 - The **data plane** is composed of a set of intelligent
 proxies (Envoy) deployed as sidecars that mediate and control all network communication between microservices.
+
 - The **control plane** is responsible for managing and 
 configuring proxies to route traffic, as well as enforcing policies at runtime.
 
 The following diagram shows the different components that make up each plane:
 
-<img src="./img/architecture/arch.svg" title="The overall architecture of an Istio-based application." />
+{% include figure.html
+    file="./img/architecture/arch.svg"
+    title="Istio Architecture"
+    alt="The overall architecture of an Istio-based application."
+%}
 
 ### Envoy
 
@@ -94,13 +99,12 @@ on service identity rather than network controls. Future releases of Istio will
 and monitor who accesses your service, API, or resource, using a variety of access control mechanisms, including attribute and
 role-based access control as well as authorization hooks.
 
-
-
 ## What's next
 
 * Learn about Istio's [design goals](./goals.html).
+
 * Explore and try deploying our [sample application]({{home}}/docs/samples/bookinfo.html).
+
 * Read about Istio components in detail in our other [Concepts]({{home}}/docs/concepts/) guides.
+
 * Learn how to deploy Istio with your own services using our [Tasks]({{home}}/docs/tasks/) guides.
-
-

_docs/samples/bookinfo.md

@@ -40,7 +40,10 @@ There are 3 versions of the reviews microservice:
 
 The end-to-end architecture of the application is shown below.
 
-![BookInfo application without Istio](./img/bookinfo/noistio.svg)
+{% include figure.html
+   file="./img/bookinfo/noistio.svg"
+   alt="BookInfo Application without Istio"
+%}
 
 This application is polyglot, i.e., the microservices are written in different languages.
 
@@ -74,7 +77,10 @@ This application is polyglot, i.e., the microservices are written in different l
    that manages incoming and outgoing calls for the service. The updated diagram looks
    like this:
 
-   ![BookInfo application](./img/bookinfo/withistio.svg)
+   {% include figure.html
+      file="./img/bookinfo/withistio.svg"
+      alt="BookInfo Application"
+   %}
 
 1. Confirm all services and pods are correctly defined and running:
 

_docs/tasks/installing-istio.md

@@ -121,8 +121,12 @@ default namespace. They can be modified for deployment in a different namespace.
 
      The dashboard should look something like this:
 
-     ![Grafana Istio Dashboard](./img/grafana_dashboard.png)
-
+     {% include figure.html
+        file="./img/grafana_dashboard.png"
+        max-width="100%"
+        alt="Grafana Istio Dashboard"
+     %}
+     
      If your deployment environment provides external load balancers, you can simply access the dashboard directly
      (without the `kubectl port-forward` command) using the external IP address of the grafana service:
    
@@ -153,8 +157,11 @@ default namespace. They can be modified for deployment in a different namespace.
      sample application and executing the `curl` request to confirm it's working, the resulting service graph
      would look something like:
    
-     ![BookInfo service graph](./img/servicegraph.png)
-   
+     {% include figure.html
+        file="./img/servicegraph.png"
+        alt="BookInfo Service Graph"
+     %}
+     
      At that point the servicegraph would show very low (or zero) QPS values, as only a single request
      has been sent. The service uses a default time window of 5 minutes for calculating moving QPS averages.
      You can later send a more consistent flow of traffic through the example application and refresh the servicegraph

_docs/tasks/metrics-logs.md

@@ -141,7 +141,11 @@ as the example application throughout this task.
 
    The request from the previous step is reflected in the graphs. This looks similar to:
 
-   ![Istio Dashboard with Response Size data](./img/dashboard_response_size.png)
+   {% include figure.html
+       file="./img/dashboard_response_size.png"
+       max-width="100%"
+       alt="Istio Dashboard with Response Size Data"
+   %}
 
 1. Verify that the logs stream has been created and is being populated
    for requests.

_docs/tasks/zipkin-tracing.md

@@ -52,13 +52,21 @@ With the Bookinfo application up and running, generate trace information by acce
 
 If you now look at the Zipkin dashboard, you should see something similar to the following:
 
-![Zipkin Istio Dashboard](./img/zipkin_dashboard.png)
+{% include figure.html
+   file="./img/zipkin_dashboard.png"
+   max-width="100%"
+   alt="Zipkin Istio Dashboard"
+%}
 
 If you click on the top (most recent) trace, you should see the details corresponding to your
 latest refresh of the `/productpage`.
 The page should look something like this:
 
-![Zipkin Istio Dashboard](./img/zipkin_span.png)
+{% include figure.html
+   file="./img/zipkin_span.png"
+   max-width="100%"
+   alt="Zipkin Istio Dashboard"
+%}
 
 As you can see, there are 4 spans (only 3, if version v1 of the `reviews` service was used),
 where each span corresponds to a Bookinfo service invoked during the execution of a `/productpage` request.
@@ -72,7 +80,6 @@ the request took a total of roughly 290ms to complete. During its execution, the
 which took about 24ms, and then called the `reviews` service.
 The `reviews` service took about 243ms to execute, including a 15ms call to `ratings`.
 
-
 ## Understanding what happened
 
 Although Istio proxies are able to automatically send spans to Zipkin, they need some hints to tie together the entire trace.
@@ -139,7 +146,6 @@ The reviews application (Java) does something similar:
 
 When you make downstream calls in your applications, make sure to include these headers.
 
-
 ## What's next
 
 * Learn more about [Metrics and Logs]({{home}}/docs/tasks/metrics-logs.html)

_includes/figure.html

@@ -0,0 +1,22 @@
+{% if include.max-width %}
+{% assign max-width = include.max-width %}
+{% else %}
+{% assign max-width = "75%" %}
+{% endif %}
+
+{% if include.title %}
+{% assign title = include.title %}
+{% else %}
+{% assign title = include.alt %}
+{% endif %}
+
+{% if include.caption %}
+{% assign caption = include.caption %}
+{% else %}
+{% assign caption = title %}
+{% endif %}
+
+<figure style="text-align: center; margin-top:20px; margin-bottom:20px;">
+    <img src="{{include.file}}" style="max-width: {{max-width}};" title="{{title}}" alt="{{include.alt}}"/>
+    <figcaption style="margin-top:10px;">{{caption}}</figcaption>
+</figure>

_layouts/base.html

@@ -1,5 +1,5 @@
 ---
-layout: compress
+#layout: compress
 ---
 {% include home.html %}
 
@@ -74,7 +74,6 @@ layout: compress
     <script src="{{home}}/js/common.js" type="text/javascript" charset="utf-8"></script>
     <script src="{{home}}/js/buttons.js"></script>
     <script src="{{home}}/js/search.js"></script>
-    <script src="{{home}}/js/fixMarkdownImages.js"></script>
 
     {% if page.customjs %}
       <script async="" defer="" type="text/javascript" src="{{ page.customjs }}"></script>

_layouts/blog.html

@@ -9,7 +9,7 @@ layout: default
       {{ content }}
 
       <a href="{{home}}/feed.xml">
-        <img title="RSS" src="{{home}}/img/rss.gif" width="36" height="14">
+        <img title="RSS" alt="RSS" src="{{home}}/img/rss.gif" width="36" height="14">
       </a>
     </div>
   </div>

js/fixMarkdownImages.js

@@ -1,18 +0,0 @@
-
-// Jekyll's markdown processor attaches ALT attributes to <img> elements.
-// That's a bug, it really should be attaching TITLE attributes instead.
-// This script grovels the DOM and assigns a TITLE attribute if one is not
-// present by cloning the ALT attribute.
-(function(){
-    var images = document.getElementsByTagName('img');
-    for (var i = 0; i < images.length; i++) {
-        var img = images[i];
-        var title = img.getAttribute("title");
-        if (title == undefined) {
-            title = img.getAttribute("alt");
-            if (title != undefined) {
-                img.setAttribute("title", title);
-            }
-        }
-    }
-})();